The Files
These are the files to which I refer in the article plus where to get them and where to install them.
Where to get them
JDK. This can be taken directly from the Macintosh OS 8 version of the MRJ-SDK. The file you’ll need is JDKClasses.zip. If you already have the MRJ-SDK installed, the file is found is System Folder:Extensions:MRJ Libraries:MRJClasses. See below for where to install on MOSXS. This Zip file contains most of the Java classes you will need for development, including the SQL interfaces. If you don’t have the MRJ-SDK, you should be able to borrow the equivalent files (I believe it’s rt.jar or tools.jar) from any other Unix platform, or even Windows.
Javax. Optional. You only need this if you intend to build Servlets, which are essentially Java applications that run on web servers similar to Perl scripts. The advantage is that Java is compiled into bytecode and doesn’t have a lot of the startup overhead that Perl does (or so they say). You need a Servlet engine running on your server in order to run Servlets. Fortunately there are several for free, including Apache JServ found at http://java.apache.org. The Javax classes themselves can be downloaded from Sun (Java Servlet Development Kit 2.0).
HTTPS Protocol Handler: HTTPClient. To prevent MalformedURLExceptions, you must tell Java how to handle the https protocol. Unfortunately, it is not a protocol that is automatically recognized. Ronald Tschalär’s free HTTPClient is one way to take care of the problem, although it requires a patch to use whichever HTTPS method you select (below). In this tutorial, we use HTTPClient as a protocol handler, but handle the HTTPS connections ourselves, so that we can deal with proxy servers. HTTPClient comes with the classes precompiled, so all you have to do is put it in your path and recompile the HTTPConnection.java file so that it understands one of the HTTPS options, below.
HTTPS Option 1: OpenSSL. OpenSSL is an open source library that provides what we need to access HTTPS web servers. When combined with a Java wrapper written by Jonathan Tew and ported to MOSXS by me, this solution allows MOSXS to get to HTTPS web servers, even through proxy servers. This option requires that you compile two C libraries (OpenSSL and part of the wrapper), install them, and then install the Java classes. It’s not as hard as it sounds, but it is a daunting task nonetheless. I’ve devoted a separate page to the setup of OpenSSL and the wrapper under MOSXS.
HTTPS Option 2: JCSI. JCSI is a 100% pure Java SSL implementation, is free for non-commercial use, but requires JDK1.2. Being 100% pure Java means that portability isn’t an issue, as it might be with OpenSSL. The work to make this package compliant with the JSSE APIs is complete, but it doesn’t work with JDK 1.1.x.
HTTPS Option 3: JSSE. Required only if you want to read pages from HTTPS (secure) servers AND you have JDK 1.2 or later installed AND you are not outside the US or Canada. Unfortunately, as of this writing, the JDK version on MOSXS is 1.1.x, and JSSE fails silently (no warnings or errors). If you want to do HTTPS, look into OpenSSL or JCSI, above. As with anything of this nature, there are severe restrictions on the availability of this part outside of the US and Canada, although there may be other Java classes by third parties outside the US that can accomplish the same thing. This can be downloaded from Sun’s site (free signup required).
HTTPS Other Free Options. I mention these options in the hope that they will soon be finished. EspreSSL is still in development as I write this (there's not even a beta to download), but aims to be a free Java SSL. Who knows? By the time you read this, it could be ready. If you know of other free Java SSL options, write and let me know so I can add them to this page.
XML4J. Optional. IBM’s free XML parser. You will need this if you wish to retrieve preferences stored in an XML file http://www.alphaworks.ibm.com.
Xeena. Optional. A Java application with a GUI for editing XML files http://www.alphaworks.ibm.com.
SUDO. Highly recommended, found at http://www.courtesan.com/sudo/. Some notes on compiling it are here. Many users make the mistake of doing all their work logged in as root. This presents a significant security risk on any Unix platform, since any application you run will run with root privileges. Did you know that you can wipe out your entire hard drive with a one-line command in a terminal window? Another reason to avoid logging in as root is that you are less likely to do damage to the system; when you are root, Unix assumes you know what you are doing and will not ask you twice about destroying entire directories or volumes. When you are logged in as a normal user, your powers are much more limited. Sudo allows you to execute specific commands in a terminal window that require root power and logging the event. Unfortunately, SUDO doesn’t work with the nice GUI Apple has provided, which means that to get the job done you either log in as root, or you execute SUDO commands in a terminal window. Neither, in my humble opinion, is an acceptable option.
DBMS. Database management system. If you have no SQL database, you have a couple of choices. You might try the mySQL database (http://www.mysql.com); it’s free for non commercial use, and very reasonably priced otherwise. FrontLine Software (http://www.frontline-software.dk/) also offers a “free” zero-security version of their FrontBase database, and you wouldn’t have to compile it, as you do with mySQL. In fact, setting up the mySQL server for MOSXS is beyond the scope of this article, although you can read these tips on compiling it: http://www.prnet.de/RegEx/mysql.html. Note that this site also has an EOF Adaptor for mySQL. I chose to forego FrontBase because the free version doesn’t include the ability to import data and it is missing even basic security. FrontBase also provides an EOF Adaptor for WebObjects.
JDBC. The JDBC drive you need will depend on the SQL database with which you are interfacing. If you have access to Oracle running on another machine (like a Sun server), you can get the Oracle JDBC drivers from their website (free signup required). The JDBC classes I will use in this article are called MM.Mysql for the mySQL server (http://www.worldserver.com/mm.mysql).
Where to install
JDK, JSSE, and XML4J. These JAR files are probably best installed in /System/Library/Frameworks/JavaVM.framework/classes. In order for Java to find these file, you will also have to modify the file in /System/Library/Java/JavaConfig.plist. Add to the long, wrapping line (the class path) so that it includes the path to the JDK files themselves, including the .zip on the end. Here’s an example of what it should look like. (Example).
Javax, JDBC, and HTTPClient. Can be installed in /System/Library/Java if you want all users on that machine to have access. Otherwise, you can install them in ~/Library/Java, where ~ represents a shortcut to the home directory of the username under which you are logged in. If you are logged in as root, ~ is /Local/Users/Administrator. With HTTPClient, place the entire directory in the path; do NOT copy individual files from inside.
All other packages. Everything else should be installed in its default location. MySQL is installed in /usr/local/mysql, for example.
These are the files to which I refer in the article plus where to get them and where to install them.
Where to get them
JDK. This can be taken directly from the Macintosh OS 8 version of the MRJ-SDK. The file you’ll need is JDKClasses.zip. If you already have the MRJ-SDK installed, the file is found is System Folder:Extensions:MRJ Libraries:MRJClasses. See below for where to install on MOSXS. This Zip file contains most of the Java classes you will need for development, including the SQL interfaces. If you don’t have the MRJ-SDK, you should be able to borrow the equivalent files (I believe it’s rt.jar or tools.jar) from any other Unix platform, or even Windows.
Javax. Optional. You only need this if you intend to build Servlets, which are essentially Java applications that run on web servers similar to Perl scripts. The advantage is that Java is compiled into bytecode and doesn’t have a lot of the startup overhead that Perl does (or so they say). You need a Servlet engine running on your server in order to run Servlets. Fortunately there are several for free, including Apache JServ found at http://java.apache.org. The Javax classes themselves can be downloaded from Sun (Java Servlet Development Kit 2.0).
HTTPS Protocol Handler: HTTPClient. To prevent MalformedURLExceptions, you must tell Java how to handle the https protocol. Unfortunately, it is not a protocol that is automatically recognized. Ronald Tschalär’s free HTTPClient is one way to take care of the problem, although it requires a patch to use whichever HTTPS method you select (below). In this tutorial, we use HTTPClient as a protocol handler, but handle the HTTPS connections ourselves, so that we can deal with proxy servers. HTTPClient comes with the classes precompiled, so all you have to do is put it in your path and recompile the HTTPConnection.java file so that it understands one of the HTTPS options, below.
HTTPS Option 1: OpenSSL. OpenSSL is an open source library that provides what we need to access HTTPS web servers. When combined with a Java wrapper written by Jonathan Tew and ported to MOSXS by me, this solution allows MOSXS to get to HTTPS web servers, even through proxy servers. This option requires that you compile two C libraries (OpenSSL and part of the wrapper), install them, and then install the Java classes. It’s not as hard as it sounds, but it is a daunting task nonetheless. I’ve devoted a separate page to the setup of OpenSSL and the wrapper under MOSXS.
HTTPS Option 2: JCSI. JCSI is a 100% pure Java SSL implementation, is free for non-commercial use, but requires JDK1.2. Being 100% pure Java means that portability isn’t an issue, as it might be with OpenSSL. The work to make this package compliant with the JSSE APIs is complete, but it doesn’t work with JDK 1.1.x.
HTTPS Option 3: JSSE. Required only if you want to read pages from HTTPS (secure) servers AND you have JDK 1.2 or later installed AND you are not outside the US or Canada. Unfortunately, as of this writing, the JDK version on MOSXS is 1.1.x, and JSSE fails silently (no warnings or errors). If you want to do HTTPS, look into OpenSSL or JCSI, above. As with anything of this nature, there are severe restrictions on the availability of this part outside of the US and Canada, although there may be other Java classes by third parties outside the US that can accomplish the same thing. This can be downloaded from Sun’s site (free signup required).
HTTPS Other Free Options. I mention these options in the hope that they will soon be finished. EspreSSL is still in development as I write this (there's not even a beta to download), but aims to be a free Java SSL. Who knows? By the time you read this, it could be ready. If you know of other free Java SSL options, write and let me know so I can add them to this page.
XML4J. Optional. IBM’s free XML parser. You will need this if you wish to retrieve preferences stored in an XML file http://www.alphaworks.ibm.com.
Xeena. Optional. A Java application with a GUI for editing XML files http://www.alphaworks.ibm.com.
SUDO. Highly recommended, found at http://www.courtesan.com/sudo/. Some notes on compiling it are here. Many users make the mistake of doing all their work logged in as root. This presents a significant security risk on any Unix platform, since any application you run will run with root privileges. Did you know that you can wipe out your entire hard drive with a one-line command in a terminal window? Another reason to avoid logging in as root is that you are less likely to do damage to the system; when you are root, Unix assumes you know what you are doing and will not ask you twice about destroying entire directories or volumes. When you are logged in as a normal user, your powers are much more limited. Sudo allows you to execute specific commands in a terminal window that require root power and logging the event. Unfortunately, SUDO doesn’t work with the nice GUI Apple has provided, which means that to get the job done you either log in as root, or you execute SUDO commands in a terminal window. Neither, in my humble opinion, is an acceptable option.
DBMS. Database management system. If you have no SQL database, you have a couple of choices. You might try the mySQL database (http://www.mysql.com); it’s free for non commercial use, and very reasonably priced otherwise. FrontLine Software (http://www.frontline-software.dk/) also offers a “free” zero-security version of their FrontBase database, and you wouldn’t have to compile it, as you do with mySQL. In fact, setting up the mySQL server for MOSXS is beyond the scope of this article, although you can read these tips on compiling it: http://www.prnet.de/RegEx/mysql.html. Note that this site also has an EOF Adaptor for mySQL. I chose to forego FrontBase because the free version doesn’t include the ability to import data and it is missing even basic security. FrontBase also provides an EOF Adaptor for WebObjects.
JDBC. The JDBC drive you need will depend on the SQL database with which you are interfacing. If you have access to Oracle running on another machine (like a Sun server), you can get the Oracle JDBC drivers from their website (free signup required). The JDBC classes I will use in this article are called MM.Mysql for the mySQL server (http://www.worldserver.com/mm.mysql).
Where to install
JDK, JSSE, and XML4J. These JAR files are probably best installed in /System/Library/Frameworks/JavaVM.framework/classes. In order for Java to find these file, you will also have to modify the file in /System/Library/Java/JavaConfig.plist. Add to the long, wrapping line (the class path) so that it includes the path to the JDK files themselves, including the .zip on the end. Here’s an example of what it should look like. (Example).
Javax, JDBC, and HTTPClient. Can be installed in /System/Library/Java if you want all users on that machine to have access. Otherwise, you can install them in ~/Library/Java, where ~ represents a shortcut to the home directory of the username under which you are logged in. If you are logged in as root, ~ is /Local/Users/Administrator. With HTTPClient, place the entire directory in the path; do NOT copy individual files from inside.
All other packages. Everything else should be installed in its default location. MySQL is installed in /usr/local/mysql, for example.
