>Currently in eclipse, if you are working with a language that leverages the Java Runtime Environment to execute the code, you have to pull in the full JDT as well. However, what if you have a use case for an IDE or an RCP application that doesn’t need the full JDT? What if you only need a piece of the JDT, like the Installed JRE page and the launching support? Currently you have to get everything, as org.eclipse.jdt.debug.ui depends on org.eclipse.jdt.ui.
It appears though that with a little bit of refactoring, the org.eclipse.jdt.debug.ui can be made not to depend on the jdt.ui for some classes. With even more refactoring the Installed JRE’s component and some of the launching tabs could be refactored further. However, in most cases, there is a need to be able to launch an applet, or java program, as that is what the program may be depending on the language being used.
So a simple refactoring that could occur to begin with is something like this:
The proposal is to move the Installed JREs to it’s own Preference Page under a new Java Runtimes preference page. This actually has a low impact to existing code, and only the existing plugin.xml entries need to be updated.
The next stage would be to create a org.eclipse.jdt.common.ui or org.eclipse.java.runtime. My preference is for the former, but it really doesn’t matter to me what it is called. This refactoring would house some of the common elements used between the debug.ui and the jdt.ui and both plugins would depend on the new plugin. This would then allow those adopters that still need JDT launching support to bring in the debug and launching plugins as well as jdt core, but not have to bring in the JDT UI which contains the editor and some other Java specific features.
XSL Tools requires the ability to specify classpaths, and JREs to be used when launching and debugging Java XSLT processors like Xalan and Saxon during XSL Tranfromations. However, if you are building an XML IDE, you don’t necessarily want to have to have the Java Editor included as well. The proposed refactoring would help with this use case. An adopter can then create a new Java Runtime feature with only the necessary items to be included.
I have some work to do on the refactoring, but once it’s done I’ll contribute a patch that demonstrates it.