Since this was written lang/jamvm and lang/classpath have become prebuilt packages in OpenBSD -current, and jikes has been upgraded to 1.22p0.
The script exodus.setup will do these steps. You will of course want to read the code before you decide to run it -- there is no warranty.
The full version follows.
Note: throughout this article relative paths are with respect to the root of OpenBSD ports tree: /usr/ports.
There are two ports needed for a free Java stack based on JamVM and GNU Classpath on OpenBSD -current (3.9-beta) [and which may work on 3.8 as well]:
Put these in your ports tree and build jamvm:
cd /usr/ports/lang/jamvm sudo make install
There is an explicit dependency in jamvm on classpath so it will be automatically installed.
There are two implementations for JamVM and GNU Classpath on this site; they are matched sets:
JamVM | Classpath |
---|---|
1.4.1 | 0.19 |
1.4.2 | 0.20 |
I created exodus.tar.gz as a meta port to make it easier to build and use existing Java ports on OpenBSD. It is an experiment to maintain updward compatible with the existing build structure and to leverage the existing ports on alternative JVMs. The Exodus package does three things:
To use it put the port in /usr/ports/devel/exodus and then install the Exodus package using:
cd /usr/ports/devel/exodus sudo make install
The install will create the JAVA_HOME directory structure in /usr/local/exodus and populate it; it will also install a revised version of infrastructure/mk/java.port.mk; If you delete the package it will remove JAVA_HOME directory and restore java.port.mk to the original.
OpenBSD's Eclipse port currently requires Sun's JDK to be installed. The only real requirement is for a Sun Java 1.4 JRE which we happen to have in the combined JamVM and GNU Classpath under Exodus. If you have Eclipse and Sun's JDK already installed skip to the section. If you don't have a Sun JDK installed you'll can still use the OpenBSD Eclipse port under Exodus with a little bit of hacking. In the end, the runtime settings will be as simple as this:
export JAVA_HOME=/usr/local/exodus export ECLIPSE_HOME=/usr/local/eclipse export PATH="$JAVA_HOME/bin:$PATH"
Here's how to fake out OpenBSD's pkg_add.
#eclipse launcher expects this: ln -s $HOME/e/eclipse /usr/local #define eclipse command ln -s $HOME/e/bin/eclipse /usr/local/bin #link to some .so's w/o versions LIBS=$HOME/e/lib cd $LIBS ln -s ${LIBS}/libcore_3_1_0.so.2.0 ${LIBS}/libcore_3_1_0.so ln -s ${LIBS}/libswt-atk-gtk-3138.so.2.0 ${LIBS}/libswt-atk-gtk-3138.so ln -s ${LIBS}/libswt-awt-gtk-3138.so.2.0 ${LIBS}/libswt-awt-gtk-3138.so ln -s ${LIBS}/libswt-gtk-3138.so.2.0 ${LIBS}/libswt-gtk-3138.so ln -s ${LIBS}/libswt-pi-gtk-3138.so.2.0 ${LIBS}/libswt-pi-gtk-3138.so
Note: the unversioned lib names are required even if the pkg_add installs Eclipse. Set LIBS=/usr/local/lib if Eclipse was installed using pkg_add.
Once you've got Eclipse here's what you need to do to run it:
#set the environment export LD_LIBRARY_PATH=$HOME/e/lib #do this if you faked out pkg_add export JAVA_HOME=/usr/local/exodus export ECLIPSE_HOME=$HOME/e/eclipse export PATH="$JAVA_HOME/bin:$PATH" #classpath likes file descriptors: ulimit -n 200 ulimit -d 500000 #run it eclipse
Eclipse takes about 14 sec. to start up on my 1.3GHz Celeron M notebook. Make sure you have lots of memory. You can adjust the -Xmx parameter in eclipse.ini. The GUI is quite usable even with this realtively modest processor. However on an 800MHz P-III the GUI feels too slow.
Now here's a surprise: if you don't adjust your ulimit's large enough Eclipse may fail silently! These are the resource exhaustion failures I've encountered while trying this out over the last couple of months:
The reason for the hang behavior appears to have to do with the way certain IOExceptions are caught and masked in the source code. Appearantly some Java developers don't think of resource exhaustion as being a source of IOExceptions. But set the resource limits high enough and Eclipse will run on OpenBSD without fault under Exodus. I've found that memory limits may have to be a little higher than with the Sun's JDK -- probably because of different memeory allocation policies and resulting fragmentation in the JVMs.
I use the "staff" login class in /etc/login.conf adjusted upwards to keep from forgetting.
The following packages have been built, installed and tested using Exodus:
Exodus mimics the environment needed to install these packages. It does this by overriding the standard version of infrastructure/mk/java.ports.mk which sets build environment based on the (new) environment variable MODJAVA_PROVIDER. To build these packages using Exodus you must use the MODJAVA_PROVIDER environment variable on the make command line when building the package. For example,
cd devel/apache-ant sudo make MODJAVA_PROVIDER=exodus installwill build the apache-ant package using the Exodus stack instead of the default Sun JDK. If MODJAVA_PROVIDER is undefined or set to "sunjdk" the Sun JDK will be used.
Note: compiling Eclipse using Ant under Exodus will require you to increase resource limits. Failure to do so will lead to multiple, spurious error messages about an "incorrect classpath". Use something like:
ulimit -n 128 ulimit -d 300000
You will need the port jikes-1.22p0 for Tomcat and Eclipse builds.
It implements the -encoding switch by bringing in libiconv.
(Earlier OpenBSD jikes port didn't provide libiconv, so -encoding was disabled.)
To get Tomcat to use Jikes for JSP compiles you will need to modify /etc/tomcat/web.xml
per the comments on setting the
ulimit -n 128
CATALINA_OPTS=-Dbuild.compiler.emacs=true
JAVA_OPTS="-Xms30m -Xmx120m -Djava.net.preferIPV4Stack=true"
This is work in progress. As you can see from the above description, it's not really necessasry to compile Eclipse under Exodus. It's just a kind of super Mauve test. An Eclipse build is a three stage process; stage 1 bootstraps ecj using javac or jikes; stage 2 compiles ecj with itself; stage 3 builds the plugins using ecj. Stage three also builds platform dependent binaries using gcc and friends. The entire process requires Ant to work and patches to the build script that are not ready for public consumption.
At the moment I'm fussing with a linker error in stage 3 after 45 minutes of ecj Java compile. Stay tuned.
The Exodus meta package creates the kind of shim that many Java packages expect. This makes it easier to use the existing Java ports in OpenBSD. A related question is how to package the existing Java ports to permit the use of alternative JVMs. Perhaps some kind of convention for dependent libraries could be defined. Then any package that provides those libs would be judged as fulfilling the requirements for a JVM package. Although flavors might be useful we can see that the Eclipse port really does not need a different flavor to be run under JamVM and Classpath on OpenBSD.
Frederick C. Druseikis
fdruseikis at sc dot edu
http://www.cse.sc.edu/~fredd/
March 6, 2006