Hi all, we plan to remove com.sun.jdi.* packages from org.eclipse.jdt.debug in 4.17 M3, see bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=565417 for reasoning.
In short, with the move of Eclipse 4.17 to Java 11, to compile a bundle depending on org.eclipse.jdt.debug, com.sun.jdi.* *and* Java 11 will be impossible because the compiler will see same package contributed by different modules (jdt.debug and JDK itself) and will flag an error. The com.sun.jdi.* packages in JDK 8 are not on classpath, they are inside the tools.jar (or classes.jar on Mac), in JDK 11 they are inside the JDK itself. So the removal of those packages from 4.17 will only affect use cases where a bundle uses org.eclipse.jdt.debug, com.sun.jdi.* but compiles against Java 8. Let assume there are product builders that want consume Eclipse 4.17 (running on Java 11 only), but still compile their own code against Java 8. Technically this is what the most people probably do right now. Now let assume their code has jdt.debug (and com.sun.jdi.* packages) in classpath, because it uses com.sun.jdi.* somehow. With the removal of com.sun.jdi.* packages from jdt.debug such code can't be compiled against Java 8 JRE anymore, because it will not find com.sun.jdi.* packages on classpath. There are few possibilities how to solve that, and question is: which one should we go and recommend? 1) Compile against Java 11. This could take a while to get done, especially because of many 3rd party jars could be not Java 11 aware and need to be either updated or made Java 11 compatible. 2) Consult stack overflow and choose the first match: https://stackoverflow.com/questions/11099352/how-to-import-and-use-com-sun-jdi-virtualmachine. The com.sun.jdi.* classes are inside SDK/lib/tools.jar, so this jar would need to be added to the classpath somehow. This is a no-op task with ant, but I have no idea if maven/tycho allows you to add tools.jar to the classpath. Another stack overflow suggests that this could work: https://stackoverflow.com/questions/3080437/jdk-tools-jar-as-maven-dependency, especially this one seem to be elegant enough: <dependency> <groupId>com.github.olivergondza</groupId> <artifactId>maven-jdk-tools-wrapper</artifactId> <version>0.1</version> </dependency> 3) Add some new bundle to Orbit, that ships com.sun.jdi.* packages we've shipped before with jdt.debug. 4) Eclipse.org provides those com.sun.jdi.* classes in some kind of "legacy JDI" bundle. This bundle need to be created and shipped with 4.17 SDK, and it could then be used for such product builders as long as their build is based on Java 8. 5) Whatever else, like adding an (optional, used for compile time only) custom bundle that compiles against Java 8, has tools.jar on classpath and exports com.sun.jdi.* packages to others. So what would be our answer here to such product builders that use both jdi and Java 8 but want to compile against 4.17 SDK? Which way is the preferred one for 4.17 migration? For me looks like 2) could be enough, if 1) is not acceptable. If you are still on java 8, just add tools.jar to the classpath *for compilation only*. Also 3) could be "OK", but I'm not sure what are the rules for adding a new bundle to Orbit. The worst case for me we would do 4) and build & ship a plugin with code that SDK doesn't need at all. I'm asking here for comments: 1) Are there known uses of com.sin.jdi.* in Eclipse projects *outside* of Eclipse SDK itself? 2) Would the removal be acceptable given known workarounds? 3) Which workaround / solution would be better? Kind regards, Andrey Loskutov Спасение утопающих - дело рук самих утопающих https://www.eclipse.org/user/aloskutov _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
