I have been able to merge Vincent’s and Jarred’s changes into the DrJava trunk to create a version of DrJava/HJ that can compile and run Habanero Java (HJ) programs. Most importantly, there is a version where both HJ and DrJava are in one 20 MB file. Please try it out: drjava-hj.jar
I have identified a change that needs to be made to the HJ Runtime in order to integrate it with DrJava. It is small and does not affect the performance or execution of HJ when it is run independently from DrJava.
The class loader that HJ uses to find classes it is running has to be changed. DrJava has a dynamic class path, depending on the files that are open, the configuration of the project, and the global preferences. If HJ is to find the classes that DrJava has compiled, HJ needs to use the class loader DrJava provides. DrJava passes this class loader to its runtimes as “thread context class loader”, which “provides a way to pass an ‘intended classloader parent’ into a framework without explicitly needing to pass it.” [source]
The thread context class loader can be queried using [cci lang=”java”]Thread.currentThread().getContextClassLoader()[/cci] and needs to be passed wherever a user class is loaded using [cci lang=”java”]Class.forName[/cci]. I found four such calls to [cci lang=”java”]Class.forName[/cci] in the HJ runtime. The nice thing about the thread context class loaders is that, unless they are set, they default to the system class loader. As a result, unless DrJava (or some other application using the HJ runtime) set the thread context class loader to tell HJ “use this class loader to find my classes”, everything is just as before.