JEPs proposed to target JDK 9

[mark.reinhold at oracle.com]

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