I think I’ve got DrJava working with the Java 7 compiler the way it should, even when started with the JRE (as long as the JDK is installed as well). That was the situation that both Corky and I got into when we double-clicked on DrJava.
Please give the weekly build drjava-weekly-20110822-r5448.jar a shot.
In the original JDK7 compiler adapter, I followed the instructions and
used the [cci lang=”java”]javax.tools.ToolProvider.getSystemJavaCompiler()[/cci] method to get the Java compiler. Unfortunately, when a user starts DrJava with
the JRE, the tools.jar file is not on the boot classpath, and the [cci lang=”java”]getSystemJavaCompiler()[/cci] method will not find the
[cci lang=”java”]com.sun.tools.javac.api.JavacTool[/cci] class, even when we later provide the tools.jar file to the class loader. The [cci lang=”java”]javax.tools[/cci] package cannot be shadowed, so we can’t load one version of it for one compiler and a different version for another compiler.
Instead of using [cci lang=”java”]ToolProvider[/cci], I now do a
[cci lang=”java”]Class.forName(“com.sun.tools.javac.api.JavacTool”).newInstance()[/cci] directly. That’s exactly what [cci lang=”java”]ToolProvider[/cci] is doing too, but we can shadow the [cci lang=”java”]com.sun.tools.javac.*[/cci] packages and have control over the classloader.
I’m sorry that it took this long. I had a long day on Friday and I’m on call this coming week; I wanted to make sure I have time to goof off and enjoy the beautiful weather this weekend.
If other issues come up, please let me know.
