Use tools provider #15
Conversation
|
ScriptEditor compilation behavior: Java 7
Java 8
|
|
Note that the failure comes because the java6 javac is picked up as the tools java compiler, even in Java8. So we need to kill our javac fork |
hinerm
force-pushed
the
use-tools-provider
branch
from
a3d6598
to
9cc0c92
Compare
When compiling, check the javax.tools.ToolsProvider compiler first. Failing that we can look for com.sun.tools and then fall back to the system javac. This should allow - for example - Fiji to move away from shipping a com.sun.tools jar as long as it's launched with a JDK. Closes #9
hinerm
force-pushed
the
use-tools-provider
branch
from
9cc0c92
to
2363a6d
Compare
|
I was hoping that we could arrange things so the javac fork's compiler is picked up after any system java. I was hoping this would be possible with service or tool priorities, but it looks like the compiler tool is the exact same class in each case. So whichever is loaded first will win, and it seems like preference is given to the So to preserve javac and avoid breaking existing Java 6 installations we would have to load system classes first. |
Or shade the old java6 javac to a different package prefix. But let's not. 😝 |
Add a call(String[], boolean, boolean) signature that can accept both verbose and debug parameters. These parameters are now used to determine if semi-error messages (e.g. exception, but continuing execution) or debugging (e.g. location of javac) information is printed.
hinerm
force-pushed
the
use-tools-provider
branch
from
2b2a9c0
to
a449c46
Compare
@ctrueden thanks for pointing this out. I added a signature and logic to use these variables more liberally. |
|
Thanks @hinerm! 🐻 |
Update the JavaCompiler to first try the compiler returned by ToolsProvider - which avoids a hard dependency on javac.