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 polyglot.util.InternalCompilerError, "Cannot find class "hj.lang.Runtime".
After looking through the Polyglot, Soot and Habanero Java sources, I inserted a System.out.println call in Polyglot’s LoadedClassesResolver, and my suspicion was confirmed: The Polyglot classpath doesn’t have the dynamically loaded jar files on it. When I hardcoded the classpath in LoadedClassesResolver 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 soot.Main.mainEntry, however, we pass the entire classpath using the -cp option
(testCommand[4] and testCommand[4] 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 initExtInfo() method in HjToJimple.java would be the
right place to set options.classpath.
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