Hi Mark/All, I've just had a read through JEP 220 and it made for a good read! I do have a couple of questions though. I apologise in advance if my archive searching skills failed with regards to any duplicated questions.
1. The endorsed-standards override mechanism & The extension mechanism >... "To help identify any existing uses of this mechanism we will modify the compiler and the >launcher to fail if this system property is set or if the lib/endorsed directory exists"... Are these tools intended to be released before Java 9/10 (e.g. Like jdeps) to help developers prepare, or will it be a deprecation warning in 9 (10) with view to removal in 10 (11)? Most endorsed libraries I've run across in the wild do tend to be of the legacy kind and sometimes these projects don't have their original source code / authors / projects associated. Several App servers which serve the Java EE space still use the ext mechanism. Getting them shifted may take some time... I note in the testing section there was reference to early access builds. Great and we'll work with Rory et al in QA to get that to the wider community as soon as possible, but I'm still uncertain whether the time frames will long enough to get projects to be ready for the change. > 2. Removed: rt.jar and tools.jar Stating/Repeating the obvious but the major IDE manufacturers will need to get enlisted in an early access program to use the rt.jar and tools.jar replacements. They'll likely? have to build a parallel mechanism as they'll have to support developers working on Java (dare I say it) 6 through to 9. I also understand that this is effectively a breaking change for <= Java 7 developers (jrt-fs.jar support for Java 8). That's OK by me, it helps encourage the world to be on a modern/safe Java and it should be less of an issue by 2016 anyhow given Java 8's adoption rates. 3. Some of our products certainly do poke and prod at various JDK/JRE/JVM internals/rarer APIs, as do that of other performance tool vendors. I'm really not sure how all of these changes will impact us until we get the early access builds, if we start seeing those in Q1/2 2015 then I'm pretty confident we'll be able to figure out the new paths required in time. I can put together a list of players in the market that try to do 'interesting' things here as well and get them testing early also. ===== Overall it looks like a major challenge will be to have the community test their projects, IDEs, App Servers early enough. I can think of a few surveys & research on Maven Central, BlackDuck etc that could go out to identify the most important projects to reach out to first. The hardest part will be getting to the private organisations (The iceberg under the water that you don't see) that aren't always tied in to the channels which the typical outreach goes to. Will do some thinking on this as this mail is now firmly trailing off into non-jigsaw technical matters :-). Thanks for the hard work on this, nice to see it coming together, ran across an annoying logging lib classpath clash today which had me thinking that "a module system would be really nice around now". Cheers, Martijn
