JEPs proposed to target JDK 9

Mario Torre neugens.limasoftware at gmail.com
Fri Oct 31 21:35:13 UTC 2014


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.

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!

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.

This is why I think there should be an open communication channel in the
future, especially regarding changes in behaviour and compatibility.

After all, this channel has more or less been open with Jigsaw, not sure
why lamdas are special here.

Cheers,
Mario
Il 31/ott/2014 16:43 "Mario Torre" <neugens.limasoftware at gmail.com> ha
scritto:

> 2014-10-31 0:02 GMT+01:00  <mark.reinhold at oracle.com>:
> > 2014/10/23 3:15 -0700, mark.reinhold at oracle.com:
> >> For your consideration: The following JEPs have been placed into the
> >> "Proposed to Target" state by their respective owners after discussion
> >> and review.
> >>
> >>   158: Unified JVM Logging
> http://openjdk.java.net/jeps/158
> >>   211: Elide Deprecation Warnings on Import Statements
> http://openjdk.java.net/jeps/211
> >>   212: Resolve Lint and Doclint Warnings
> http://openjdk.java.net/jeps/212
> >>   213: Milling Project Coin
> http://openjdk.java.net/jeps/213
> >>   214: Remove GC Combinations Deprecated in JDK 8
> http://openjdk.java.net/jeps/214
> >>   216: Process Import Statements Correctly
> http://openjdk.java.net/jeps/216
> >>
> >> Feedback is more than welcome, as are reasoned objections.  If no such
> >> objections are raised in one week's time (i.e., by 2014/10/30 23:00
> UTC),
> >> or if they're raised and then satisfactorily answered, then per the JEP
> >> 2.0 process proposal [1] I'll target these JEPs to JDK 9.
> >
> > Thanks to all who commented on this round.  One objection was raised,
> > and satisfactorily answered.
>
> More like just answered :) but this ship has sailed I don't think
> there's much we can do about it anymore.
>
> I understand that the JCP *is* the ultimate authority and the place
> where those discussion should take place. I understand it, appreciate
> it and fully endorse it of course. I would have expected though that
> changes that may be relevant to everybody like breaking backward
> compatibility (like the change we questioned) should have wider
> exposure than just a summary mail at the end of the cycle, where
> there's no discussion that can be done anymore.
>
> The main problem is that even if there are objection, they just won't
> count, decision had been made, the train is gone, the consensus in the
> group has been reached, so anything we may say it's just not "adding
> any new information".
>
> Of course, as said the JCP is the place to go, if we want our voice
> heard this is where it should be. But maybe we should have some digest
> of what's going on in the JCP that affect what's going on here, so
> that people don't loose track, the way it works now is totally
> confusing to be honest.
>
> > Hearing no further objections, I've targeted all these JEPs to JDK 9.
>
> Sure, don't misunderstand me and my criticism please, there's lot of
> good stuff going on here, so cheers!
>
> Mario
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/
>


More information about the jdk9-dev mailing list