JEP 220 questions
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Thu Oct 30 20:16:55 UTC 2014
2014/10/30 11:58 -0700, martijnverburg at gmail.com:
> 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.
No worries -- they're all good 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,
The tools are the compiler (javac) and the launcher (java), not some
> or will it be a deprecation warning in 9 (10)
> with view to removal in 10 (11)?
Removal in 9.
> 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...
Yes. We're already aware of a couple of app servers that use the
extension mechanism. In many of the cases we've seen, people use that
mechanism primarily out of laziness -- the "extension" JAR files can
(nearly) as easily be placed on the regular class path.
> 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,
Great! The EA builds should be available shortly.
> but I'm still uncertain whether the time
> frames will long enough to get projects to be ready for the change.
That's part of what we're trying to discover with this exercise, as
noted at the end of the "Risks" section.
>> 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.
Yes. Rory already has a list of application and library maintainers to
whom he'll be reaching out, and the IDEs are at the top of that list.
> 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.
Agreed, but in principle it wouldn't be difficult to make jrt-fs.jar
also work on JDK 7 if there's demand for that. (Any earlier would be
infeasible, since the NIO file-system API was introduced in 7.)
> 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.
That'd be very helpful.
> 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.
Yes, and any help you can provide along these lines will be greatly
More information about the jigsaw-dev