Incubating Java Language Features

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Incubating Java Language Features

Mike Milinkovich-2

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". The conversation on the mailing list starts here. 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.

--
Mike Milinkovich
[hidden email]
(m) +1.613.220.3223


_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Incubating Java Language Features

Jayaprakash Arthanareeswaran
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 <[hidden email]>
To:        [hidden email]
Cc:        [hidden email], Wayne Beaton <[hidden email]>
Date:        01/30/2018 04:42 PM
Subject:        [jdt-dev] Incubating Java Language Features
Sent by:        [hidden email]




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". The conversation on the mailing list starts here. 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.

--
Mike Milinkovich

[hidden email]
(m) +1.613.220.3223
_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_jdt-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=LuMqcl3PU0i2olgTvkVvFthzqyc_3wGfGooplpAvFsc&m=otdJCIXdD0isszl9Nw7AI23ITDJ1H7iQIG4Itm-Yfbw&s=00Xfl2GDFAWNS2yoDEtVCTH_ufnc2-va4Pz-8EJmO30&e=



_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-dev

Reply | Threaded
Open this post in threaded view
|

Re: Incubating Java Language Features

Stephan Herrmann-2
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 <[hidden email]>
> To: [hidden email]
> Cc: [hidden email], Wayne Beaton <[hidden email]>
> Date: 01/30/2018 04:42 PM
> Subject: [jdt-dev] Incubating Java Language Features
> Sent by: [hidden email]
> ------------------------------------------------------------------------------------------------------------------------------------
>
>
>
> 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://bugs.openjdk.java.net/browse/JDK-8195734>". The conversation on the mailing list _starts here_
> <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000515.html>. 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.
>
> --
> Mike Milinkovich_
> __mike.milinkovich@eclipse-foundation.org_ <mailto:[hidden email]>
> (m) +1.613.220.3223
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_jdt-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=LuMqcl3PU0i2olgTvkVvFthzqyc_3wGfGooplpAvFsc&m=otdJCIXdD0isszl9Nw7AI23ITDJ1H7iQIG4Itm-Yfbw&s=00Xfl2GDFAWNS2yoDEtVCTH_ufnc2-va4Pz-8EJmO30&e= 
> <https://dev.eclipse.org/mailman/listinfo/jdt-dev>
>
>
>
>
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jdt-dev
>

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Incubating Java Language Features

Mike Milinkovich-2

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 <[hidden email]>
>> To: [hidden email]
>> Cc: [hidden email], Wayne Beaton
>> <[hidden email]>
>> Date: 01/30/2018 04:42 PM
>> Subject: [jdt-dev] Incubating Java Language Features
>> Sent by: [hidden email]
>> ------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>>
>>
>> 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://bugs.openjdk.java.net/browse/JDK-8195734>".
>> The conversation on the mailing list _starts here_
>> <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000515.html>.
>> 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.

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Incubating Java Language Features

Daniel Megert
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 <[hidden email]>
To:        [hidden email]
Date:        30.01.2018 14:21
Subject:        Re: [jdt-dev] Incubating Java Language Features
Sent by:        [hidden email]





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 <[hidden email]>
>> To: [hidden email]
>> Cc: [hidden email], Wayne Beaton
>> <[hidden email]>
>> Date: 01/30/2018 04:42 PM
>> Subject: [jdt-dev] Incubating Java Language Features
>> Sent by: [hidden email]
>> ------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>>
>>
>> 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.

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_jdt-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=PoHnsLGDwD9AiJodjpFFDGD5QqcvTG97DFFZeJVZSZ4&s=Hryxq9p_5WD0NNVWtGJVDycz6JHJu3EXpge-ysZERk4&e=




_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Incubating Java Language Features

Stephan Herrmann-2
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 <[hidden email]>
> To: [hidden email]
> Date: 30.01.2018 14:21
> Subject: Re: [jdt-dev] Incubating Java Language Features
> Sent by: [hidden email]
> ------------------------------------------------------------------------------------------------------------------------------------
>
>
>
>
> 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 <[hidden email]>
>>> To: [hidden email]
>>> Cc: [hidden email], Wayne Beaton
>>> <[hidden email]>
>>> Date: 01/30/2018 04:42 PM
>>> Subject: [jdt-dev] Incubating Java Language Features
>>> Sent by: [hidden email]
>>> ------------------------------------------------------------------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>> 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.
>
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_jdt-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=PoHnsLGDwD9AiJodjpFFDGD5QqcvTG97DFFZeJVZSZ4&s=Hryxq9p_5WD0NNVWtGJVDycz6JHJu3EXpge-ysZERk4&e=
>
>
>
>
>
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jdt-dev
>

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Incubating Java Language Features

Mike Milinkovich-2

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 <[hidden email]>
>> To: [hidden email]
>> Date: 30.01.2018 14:21
>> Subject: Re: [jdt-dev] Incubating Java Language Features
>> Sent by: [hidden email]
>> ------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>>
>>
>>
>> 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 <[hidden email]>
>>>> To: [hidden email]
>>>> Cc: [hidden email], Wayne Beaton
>>>> <[hidden email]>
>>>> Date: 01/30/2018 04:42 PM
>>>> Subject: [jdt-dev] Incubating Java Language Features
>>>> Sent by: [hidden email]
>>>> ------------------------------------------------------------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 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.

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-dev