JEP 182: Policy for Retiring javac -source and -target Options

[Gunnar Morling]

Thanks for your replies, Joe and Remi!

> possibly taking into account LTS...
> should not change until after a LTS...

I think something like that would help.

Here's the situation which made me bring this up: I'm considering to use
text blocks (preview feature in 13) in *tests*. Whereas my main code needs
to remain at Java 8 compatibility, so to not exclude any of my users (sorry
for those still on older versions ;). So I considered building with JDK 13,
using release 8 for main code and 13 for test code. Now as I'd be on
non-LTS with 13, I'd have to go to 14, 15, etc. as soon as they are out, in
order to get bug fixes, security fixes etc. This means I'd have a problem
if any of those were to drop support for Java 8 compatibility, as I'd
either have to stay on an unmaintained JDK or would be forced to increase
the release level of my main code. For a user in my situation, the
earliest safe option to drop Java 8 compatibility would be in 18, because
then I could stay on 17 LTS for the foreseeable future.

That said, it's my understanding that LTS is *not* a notion of OpenJDK, but
rather one of build providers such as Oracle, Adopt and many others. While
it seems there's consensus on 11, 17, ... being LTS, vendors could decide
to offer long-term support for other releases, too. So which LTS would then
be the basis for that decision in OpenJDK? Perhaps it'd be a good idea to
formalize in OpenJDK itself the nature of specific releases being
recommended for LTS by build providers?

--Gunnar

Am Sa., 11. Jan. 2020 um 19:46 Uhr schrieb Remi Forax <forax at univ-mlv.fr>:

> I think the set of supported source/target should not change until after a
> LTS.
> Because we should minimize the change in the tooling to upgrade from a
> release to another one, otherwise, we are defeating the purpose of a 6
> month release cadence.
>
> So i propose that for each release just after a LTS, we may decide to
> revisit the supported versions of --source/--target/--release.
>
> cheers,
> Rémi
>
> ----- Mail original -----
> > De: "joe darcy" <joe.darcy at oracle.com>
> > À: "Gunnar Morling" <gunnar at hibernate.org>, "compiler-dev" <
> compiler-dev at openjdk.java.net>
> > Envoyé: Samedi 11 Janvier 2020 19:07:42
> > Objet: Re: JEP 182: Policy for Retiring javac -source and -target Options
>
> > Hello,
> >
> > In the corresponding JBS issue,
> >
> >     https://bugs.openjdk.java.net/browse/JDK-8046172
> >
> > a comment states
> >
> >> Note that with the six month release cadence
> >> (
> http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html)
> >> being used starting with JDK 10, the chronogical range covered by "one
> >> plus three back" would be much shortened. In due course, this policy
> >> will be updated accordingly, possibly taking into account LTS (long
> >> term support) releases and possibly offering a sparse set of values.
> >> For example, one possible policy would be to support the last two LTS
> >> release and each release after the most recent LTS, but not the
> >> releases between those two LTS releases.
> >
> >
> https://bugs.openjdk.java.net/browse/JDK-8046172?focusedCommentId=14145783&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14145783
> >
> > There are no plans to remove support for --release 7 in JDK 15.
> >
> > HTH,
> >
> > -Joe
> >
> > On 1/11/2020 3:35 AM, Gunnar Morling wrote:
> >> Hi,
> >>
> >> In JEP 182 (currently in draft state, [1]) it says: "In JDK 9 and
> >> going forward, javac will use a "one + three back" policy of supported
> >> source and target options."
> >>
> >> Are there any plans to update this one in the light of the increased
> >> release cadence? In particular, what's the next planned upgrade of the
> >> minimum supported version (javac 14 still supports source/target level
> >> 7 at this point)?
> >>
> >> Thanks,
> >>
> >> --Gunnar
> >>
> >> [1] https://openjdk.java.net/jeps/182
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200111/e19d7555/attachment.htm>