JEPs proposed to target JDK 9

[Ben Evans]

Hi Mark,

I'm extremely glad to hear you say this, for the following reason:

The modularity changes that are being proposed as part of the current
batch of JEPs are, to my mind, some of the largest ever. They
represent a completely different state of affairs even from lambdas.

Lambdas were / are by comparison a relatively modest enhancement -
some new language syntax, type auto-conversion and an implementation
mechanism prototyped as inner classes but widely understood to be
ultimately likely to use MH / invokedynamic as implementation.

Therefore, for tool providers, supporting Java 8 was just a matter of
enhancing to add in the new syntax, and support for default methods,
streams, etc where necessary.

Modularity, on the other hand, as currently envisaged, is going to
break vast numbers (if not virtually every) tool in the ecosystem, and
require fundamental changes to a lot of tools. This is a completely
different ball game to 8, and I feel it is very important that:

a) Sufficient testing is done, not just by end users, but by JVM
vendors, IDE and other tool makers - and as early as possible.

b) That the implementing group within OpenJDK have close contact with
those parts of the ecosystem and

c) The implementors are receptive to problems, and open to changing
course and/or providing remediation to make the transition less
painful for tool makers (& end users). This is of course easier to do
the earlier that pain points are identified, hence a).

>From the other thread with Martijn, I'm assuming that the intention is
to achieve this via a combination of community outreach & formal
effort from Oracle's Quality group - is that correct, or do you
foresee other channels?

I've broadened this thread out to include the JCP EC as I feel that
the changes that have been proposed as part of JEP 220
(http://openjdk.java.net/jeps/220) need to be on their radar at this
early stage.

Finally, having said all this, I'd like to say that I've seen a lot of
encouraging news around the JDK 9 JEPs - especially in things like JEP
223 (http://openjdk.java.net/jeps/223 - dealing with how to handle
version strings).

Thanks,

Ben


On Wed, Nov 5, 2014 at 6:53 PM,  <mark.reinhold at oracle.com> wrote:
> 2014/10/31 2:35 -0700, neugens.limasoftware at gmail.com:
>> I just felt I should clarify my view here of that what I see as a point of
>> failure in the process. You may (and probably will) disagree with me, but I
>> hope there's some feedback here that will improve things for the future.
>
> Thanks for clarifying your view.
>
>> The issue for me is that one JSR that targets a specific area introduces an
>> incompatible change that affect everybody. This change is proposed as a Jep
>> for inclusion in the next JDK, which doesn't yet have a JSR, but we still
>> have to accept this just under the explanation that "it's too late and
>> there's too much in motion to pull the emergency brake".
>>
>> In my naive world a Jep needs to be discussed, and is not law until it's
>> accepted or promoted to a JSR in its own right. The EG may decide for
>> lamdas to be the way they are out of simple personal preference, but it
>> can't decide for an incompatible language change since this belong to the
>> JDK 9 JSR which doesn't even exist yet!
>
> Yes, that's exactly right.  The final decision of whether to disallow
> underscore as an identifier -- along with all other decisions about
> changes to the language, VM, and API specifications in Java SE 9 --
> belongs to the SE 9 Platform JSR EG, which has not yet been formed.
>
> Here in the JDK 9 Project we're working on what will eventually become
> the Reference Implementation of the Java SE 9 Specification.  In the
> interim it's meant to be a good approximation of what will eventually be
> proposed for that Specification so that developers can do early testing
> with it and give feedback.
>
> A JEP that proposes to change the language, VM, or API Specifications
> need not wait until those changes are approved by the Java SE 9 EG.
> That would be an incredibly inefficient process.  It makes more sense
> for such JEPs to be proposed, discussed, and implemented in JDK 9 so
> that developers can use them and provide feedback, which can then inform
> both the refinement of the proposal and the ultimate decision of the SE
> 9 EG as to whether to accept the change.
>
> On the particular issue of disallowing underscore as an identifier in a
> post-8 release my take, as I wrote earlier, is that the intent to do so
> was discussed on the public lambda-dev list, discussed and approved by
> the Lambda EG, and then approved by the SE 8 EG and thence the JCP EC.
> The javac compiler has issued warnings about such uses since over a year
> before JDK 8 GA and few have noticed it, much less complained about it.
>
> The proposal in JEP 213 actually to implement that intent, therefore,
> did not come out of nowhere.  You and David Lloyd objected to it but
> neither of you brought any new information to the discussion.  Absent
> such information I think the best course of action is to proceed with
> the change in JDK 9.  If developer testing of JDK 9 early-access builds
> reveals this change to be a huge problem then we can revert it; if not,
> then it will likely not be a huge problem in the final release.  In any
> case, the SE 9 EG will own the final decision.
>
>> So yes, the ship has sailed and our opinion has been kindly noted but won't
>> change anything, but in fact the ship sailed without waiting for the right
>> review process to begin with.
>
> The discussion started long ago and the review process will ultimately,
> as you observed, end with the SE 9 EG.  Until then the ship is well on
> its way but it's not yet out of the harbor, so if we do learn something
> new then we can still call it back.
>
> - Mark