I’m trying to integrate the Habanero Java compiler into DrJava in a way that doesn’t require all the compiler classes to be present in the DrJava jar file. I want it to behave the same as javac, Mint, or NextGen.
In doing so, I noticed that Polyglot wasn’t finding some of the Habanero Java runtime classes, and I suspected that the Polyglot classpath wasn’t set up correctly. I was always getting a [cci lang=”java”]polyglot.util.InternalCompilerError[/cci], [cci lang=”java”]”Cannot find class “hj.lang.Runtime”[/cci].
After looking through the Polyglot, Soot and Habanero Java sources, I inserted a [cci lang=”java”]System.out.println[/cci] call in Polyglot’s [cci lang=”java”]LoadedClassesResolver[/cci], and my suspicion was confirmed: The Polyglot classpath doesn’t have the dynamically loaded jar files on it. When I hardcoded the classpath in [cci lang=”java”]LoadedClassesResolver[/cci] to be the required path, I was able to compile Habanero Java files within DrJava.
When we invoke the Habanero Java compiler from DrJava using [cci lang=”java”]soot.Main.mainEntry[/cci], however, we pass the entire classpath using the -cp option
([cci lang=”java”]testCommand[4][/cci] and [cci lang=”java”]testCommand[4][/cci] in HjCompiler.java, lines 263 and
following).
I think the Habanero Java developers should just be able to pass that classpath to Polyglot as well. It
looks like the [cci lang=”java”]initExtInfo()[/cci] method in HjToJimple.java would be the
right place to set [cci lang=”java”]options.classpath[/cci].
I haven’t confirmed this yet, because building Habanero Java is probably more involved than just compiling Polyglot.
Pingback: Same Classpath in Front-End and Rest of Habanero Java Compiler | A Concurrent Affair