Interesting direction. Reading carefully, the goal is actually very limited in scope, by preventing any public API changes. It doesn't help adoption of JSR-310 for example, but will be useful for Unsafe, which is clearly a motivating factor.
I would expect IDEs to have some considerable work to do. My biggest concern will be ensuring tools like Reflections (or other classpath scanning tools) carry on working. Really, classpath scanning should no longer be necessary with a module system, but since we've heard nothing to indicate that issue is being tackled, those tools will continue to be vital (such as to find all classes implementing an annotation, or all implementations of an interface) Stephen On 12 February 2015 at 20:52, Paul Sandoz <paul.san...@oracle.com> wrote: > Hi > > In connection with the JEP there is also a design document to help the > discussion: > > http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md > > We are especially interesting in hearing feedback from library developers, > tool/IDE developers, and anyone doing funky stuff with class loading and JAR > files. > > Paul. > > On Feb 12, 2015, at 9:41 PM, mark.reinh...@oracle.com wrote: > >> New JEP Candidate: http://openjdk.java.net/jeps/238 >> >> - Mark >
