[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-compiler-dev
Subject: Re: JEP 182: Policy for Retiring javac -source and -target Options
From: Gunnar Morling <gunnar () hibernate ! org>
Date: 2020-01-11 21:38:35
Message-ID: CADGJaX_zbvvXh=fbPPYQqCvFw7zh0oaE5B9VVofnUkA_nQ9hYg () mail ! gmail ! com
[Download RAW message or body]
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@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@oracle.com>
> > À: "Gunnar Morling" <gunnar@hibernate.org>, "compiler-dev" <
> compiler-dev@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
>
[Attachment #3 (text/html)]
<div dir="ltr">Thanks for your replies, Joe and Remi!<div><br></div><div>> \
possibly taking into account LTS...</div><div>> should not change until after a \
LTS...</div><div><br></div><div>I think something like that would \
help.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>--Gunnar</div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Sa., 11. Jan. 2020 um 19:46 \
Uhr schrieb Remi Forax <<a \
href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>>:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">I think the set of supported source/target should \
not change until after a LTS.<br> 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.<br> <br>
So i propose that for each release just after a LTS, we may decide to revisit the \
supported versions of --source/--target/--release.<br> <br>
cheers,<br>
Rémi<br>
<br>
----- Mail original -----<br>
> De: "joe darcy" <<a href="mailto:joe.darcy@oracle.com" \
target="_blank">joe.darcy@oracle.com</a>><br> > À: "Gunnar Morling" \
<<a href="mailto:gunnar@hibernate.org" \
target="_blank">gunnar@hibernate.org</a>>, "compiler-dev" <<a \
href="mailto:compiler-dev@openjdk.java.net" \
target="_blank">compiler-dev@openjdk.java.net</a>><br> > Envoyé: Samedi 11 \
Janvier 2020 19:07:42<br> > Objet: Re: JEP 182: Policy for Retiring javac -source \
and -target Options<br> <br>
> Hello,<br>
> <br>
> In the corresponding JBS issue,<br>
> <br>
> <a href="https://bugs.openjdk.java.net/browse/JDK-8046172" \
rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8046172</a><br>
> <br>
> a comment states<br>
> <br>
>> Note that with the six month release cadence<br>
>> (<a href="http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html" \
rel="noreferrer" target="_blank">http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html</a>)<br>
>> being used starting with JDK 10, the chronogical range covered by \
"one<br> >> plus three back" would be much shortened. In due course, \
this policy<br> >> will be updated accordingly, possibly taking into account \
LTS (long<br> >> term support) releases and possibly offering a sparse set of \
values.<br> >> For example, one possible policy would be to support the last \
two LTS<br> >> release and each release after the most recent LTS, but not \
the<br> >> releases between those two LTS releases.<br>
> <br>
> <a href="https://bugs.openjdk.java.net/browse/JDK-8046172?focusedCommentId=141457 \
83&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14145783" \
rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8046172?focu \
sedCommentId=14145783&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14145783</a><br>
> <br>
> There are no plans to remove support for --release 7 in JDK 15.<br>
> <br>
> HTH,<br>
> <br>
> -Joe<br>
> <br>
> On 1/11/2020 3:35 AM, Gunnar Morling wrote:<br>
>> Hi,<br>
>><br>
>> In JEP 182 (currently in draft state, [1]) it says: "In JDK 9 and<br>
>> going forward, javac will use a "one + three back" policy of \
supported<br> >> source and target options."<br>
>><br>
>> Are there any plans to update this one in the light of the increased<br>
>> release cadence? In particular, what's the next planned upgrade of \
the<br> >> minimum supported version (javac 14 still supports source/target \
level<br> >> 7 at this point)?<br>
>><br>
>> Thanks,<br>
>><br>
>> --Gunnar<br>
>><br>
>> [1] <a href="https://openjdk.java.net/jeps/182" rel="noreferrer" \
target="_blank">https://openjdk.java.net/jeps/182</a><br> </blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic