[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-dev] Incubating Java Language Features
|
To be clear, I am not acting as an intermediary here. These are all
excellent questions that I suggest you ask directly on the openjdk list.
Thanks.
On 2018-01-30 12:40 PM, Stephan Herrmann wrote:
It says:
"The formal step to incubation occurs when the JEP reaches Proposed To
Target status.
At that time, the JEP owner must state if they wish the feature to
incubate in the proposed release."
Do we have information whether deadlines differ when a JEP is proposed
to a target,
such that incubation features can sneak in later than permanent features?
I don't see this in the proposal, but if that were the case, yes, then
we'd have
a problem.
I don't think Alex would say "brought forward to incubation", he'd say:
"brought forward for inclusion in a release", basically following all the
rules for that step, just with a secondary flag: oh, by the way,
please attach an "incubation" label.
Perhaps subtleties of wording, but the question of deadlines could make
the difference.
Stephan
On 30.01.2018 15:18, Daniel Megert wrote:
As per https://bugs.openjdk.java.net/browse/JDK-8195734the umbrella
JSR for a release will enumerate which incubation JEPs have to be
implemented. There's nothing optional where JDT could decide what
incubating features to implement for a specific release.
The known problem for JDT will probably be the usual restriction in
the license (I just assuming here) where Eclipse (and all others) are
not allowed to ship the ongoing implementation with an Eclipse release.
However, a much bigger problem I envision is that there are already
many JEPs at the door that might soon be brought forward for
incubation and which JDT did not look at at all because we could
always only focus on what was marked for a release. Given that
incubation features must also be implemented to comply with the JSR
specification, JDT might no longer be able to deliver Eclipse Java X
support at the same time as the GA of a Java X.
Dani
From: Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
To: jdt-dev@xxxxxxxxxxx
Date: 30.01.2018 14:21
Subject: Re: [jdt-dev] Incubating Java Language Features
Sent by: jdt-dev-bounces@xxxxxxxxxxx
------------------------------------------------------------------------------------------------------------------------------------
Perhaps I was wrong, but I thought that you relied upon the JSRs to
drive what gets implemented in ecj. I thought that one of the big
changes here was that you will now have to closely follow the OpenJDK
discussions. Is there an IP issue here that needs to be discussed?
On 2018-01-30 7:45 AM, Stephan Herrmann wrote:
Jay,
not sure this answers your concerns, but the email thread on jdk-dev
makes a strong point in saying that incubating features are not
experimental. I read this as: the process for an incubating feature
is essentially the same as for a permanent feature. The main changes
for us would thus be:
- we need to implement the switch that can turn of a certain feature
- we must be prepared to pull the plug and completely remove a
feature when it is withdrawn later.
(the former is common practice, that latter may well be tricky)
IOW, "evolving simultaneously" doesn't seem to imply that we should
implement weekly updates of a feature. When it's included in a release
it's supposed to have production quality. Only when a feature
re-incubates, there's a window of opportunity for changing its spec
within the next 6 months time frame.
Do you interpret the information differently?
Stephan
On 30.01.2018 12:55, Jayaprakash Arthanareeswaran wrote:
Thanks Mike.
I believe, some of these were already happening already as part of
the openjdk development process. But just as in the past, the
"impermanent" nature of these feature is definitely a concern for us,
the JDT team. What makes it a bigger concern is this, (based on my
understanding, of course):
The compilers and runtimes should support these incubating features,
although they are turned off by default. This basically means every
compiler implementation should evolve simultaneously with respect to
the incubating features. But at the same time, not all of them are
certain to be a permanent feature.
Even if the above is not true, it is going to be a challenge to
decide our own plan based on the direction the incubating feature is
going to take. Are we to build these features even as the discussions
happen or are we to wait for these to become permanent and start on
our implementation.
Either way, it's going to be quite a challenge!
Regards,
Jay
From: Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
To: jdt-dev@xxxxxxxxxxx
Cc: eclipse-pmc@xxxxxxxxxxx, Wayne Beaton
<wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
Date: 01/30/2018 04:42 PM
Subject: [jdt-dev] Incubating Java Language Features
Sent by: jdt-dev-bounces@xxxxxxxxxxx
------------------------------------------------------------------------------------------------------------------------------------
All,
Just in case you've missed it, I would like to draw your attention to
a recent proposal on the jdk-dev list entitled "_Incubating Language
and VM Features_
<https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8195734&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=PoHnsLGDwD9AiJodjpFFDGD5QqcvTG97DFFZeJVZSZ4&s=TE0zGOYvXay7RDLkv7izRAAG8BC2bMx0oe2QYj294og&e=>".
The conversation on the mailing list _starts here_
<https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_jdk-2Ddev_2018-2DJanuary_000515.html&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=PoHnsLGDwD9AiJodjpFFDGD5QqcvTG97DFFZeJVZSZ4&s=NpAjz9n2pjG9QhCbhMYkPRP30N36YKtzeLQPWUe12mY&e=>.
At its core, I *think* this means that staying abreast of new
language features will require engaging with OpenJDK rather than JSRs
hosted at the JCP.
Important quote:
The Umbrella JSR for the Java SE $N Platform enumerates the
incubating language and VM features in the platform. The desire for
feedback and the expectation of quality means that these features are
not "optional"; they must all be supported in full by every
implementation of the Umbrella JSR. They are specified in appendices
of the Java SE $N Editions of the Java Language Specification (JLS)
and the Java Virtual Machine Specification (JVMS). The Java
Compatibility Kit for Java SE $N checks conformance of an
implementation's incubating features to the appropriate appendix.
If you have any thoughts or concerns about how this may impact ecj or
JDT in general, please comment on the jdk-dev mailing list. If there
is anything I or the EMO can assist with, please let me know.
Thanks.
