Java Certification and downport of features to older releases
Brian Goetz
brian.goetz at oracle.com
Wed Nov 15 00:10:45 UTC 2017
I would suggest you ask JLE.
Sent from my iPad
> On Nov 14, 2017, at 6:29 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
>
> Hi,
>
> I want to ask for you opinion regarding the following scenario:
>
> 1. A vendor X decides to provide LTS support for a specific Java release N
> 2. 6 month later, the new N+1 short term-release of Java introduces a
> nice new language feature F (let's say something like local variable
> type inference).
> 3. Vendor X doesn't want to support release N+1 because it is only a
> short term release. But feature F is quite appealing and there's a
> high demand for it, so he decides to downport it to his Java release
> N. The new feature F is protected by a command line switch.
>
> Questions:
>
> a. Can vendor X certify his new N release as being Java N compatible?
>
> I would say yes, because even if feature F wouldn't be protected by a
> command line switch, the TCK for version N can not contain any tests
> which check the absence of support for feature F.
>
> b. Can vendor X claim that his JDK is Java N compatible but
> additionally supports feature F from Java N+1?
>
> So this is the more interesting question for which I don't know the
> answer. Even if he wouldn't be allowed to claim it, as a matter of
> fact he could still support it and his clients could use it.
>
>
> I think with the previous release model, we didn't had such kind of
> problems because of the long time frame between two releases. But with
> the new, frequent release cadence and the fact that non-LTS releases
> will be only supported for 6 months, the scenario sketched above could
> be quite attractive.
>
> On the one hand, such an approach could be beneficial for Java,
> because it would give features which are introduced in non-LTS
> releases a much broader adoption and visibility (few people will
> probably use non-LTS releases in production). That's good to have,
> before we bake such a feature into an LTS release.
>
> On the other hand, it could lead to a certain amount of fragmentation,
> if different implementations of Java N support different (if any)
> additional features from Java N+1, N+2, etc.
>
> What do you think?
>
> Thank you and best regards,
> Volker
>
> PS: I know that the question of LTS vs. non-LTS releases is not
> relevant for the EG. But the question of certification and claiming
> compatibility is?
More information about the java-se-spec-experts
mailing list