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