JEP 220 questions

[Martijn Verburg]

Hi Mark,

Thanks for the clarifications - we'll start with the message at Devoxx in a
few weeks time and progress from there. I'll co-ordinate with Rory and come
back with some further questions for this list (I assume this is the right
place?) with regards to early access builds and "concrete things the Jigsaw
team like to see get exercised/tested".

Cheers,
Martijn

On 30 October 2014 20:16, <mark.reinhold at oracle.com> wrote:

> 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
> other tools.
>
> >                             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
> appreciated!
>
> - Mark
>