Incubation Feature Clarifications
Brian Goetz
brian.goetz at oracle.com
Mon Feb 5 14:52:25 UTC 2018
Part of the goal of the Incubating JEP is to make the
incubation-vs-permanent difference as small as possible. For almost
anything not explicitly spelled out in the JEP, the answer is usually
"no different than any other feature." In that light:
> Hi,
> I am Manoj from the Eclipse Java Development Tools (JDT) and from Eclipse
> JDT Dev, we have a couple of clarifications regarding the incubation
> features:
>
> Mandatory or Optional: We understand that when an incubation feature is
> included in a release, it should be of production quality. However, do
> we, as spec/compiler implementers have the freedom to omit an incubation
> feature? In Other words, would we be termed non-compliant if we do not
> implement a particular incubation feature?
This one is spelled out in the JEP, but the answer is: no different than
any other feature. It's part of the spec, so its part of what the
ecosystem should support. (This further underscores the fact that
incubating features are not for experimental or risky features.)
> Timeline: How much minimum time (in weeks/months) before the release
> can we expect a feature to be categorized as incubation? If it depends
> on the feature, what could be a ballpark estimate?
>
No different than any other feature. For any feature, incubating or
not, the key milestone is Propose To Target; at this point, a JEP owner
should consider whether including such a feature at this point in the
cycle is the best choice. (Incubating or not, integrating a risky
feature near the close of the development cycle is not a good idea;
there's another train coming soon.)
JEPs that affect the platform specification are tagged as Scope: SE.
Language features are tracked in component specification:language; VM
features in specification:vm. It is easy to create queries that track
JEPs by filtering on these fields; this dashboard, used by the SE 10 EG
(https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17511),
is one such example -- you can customize as you like. So it is easy to
track the lifecycle of JEPs that will affect the language and which will
ultimately need IDE support.
More information about the jdk-dev
mailing list