9:04 a.m.
https://fedoraproject.org/wiki/Changes/Java11 .
== Summary ==
Update the system JDK in Fedora from java-1.8.0-openjdk to java-11-openjdk.
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: <jvanek(a)redhat.com>
* Product: java and java stack
* Responsible WG: java-sig (java and java-maint)
== Detailed Description ==
Fedora currently ships:
* java-1.8.0-openjdk (LTS)
* java-11-openjdk (LTS)
* an java-latest-openjdk (on jdk14, STS).
where the version-less '''java''' and
'''javac''' (and friends) are
provided by java-1.8.0-openjdk.
So every package honoring the packaging rules and requiring java ,
java-headless or java-devel is built in brew by
java-1.8.0-openjdk-devel and pulls java-1.8.0-openjdk(-headless) in
runtime (See [https://fedoraproject.org/wiki/Java java] ). Also
javapackaging-tools are using java-1.8.0-openjdk as hardcoded runtime
(see
[https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_...
changes])
Debian already moved to JDK11 as system JDK, and in Fedora community
we can hear for last two years increasing voices for jdk11 to become
the system one. And apparently the java stack is really quite ready
for JDK11. Fedora is considered to be bleeding edge distribution, so
we should move forward, however JDK11 is not 100% compatible with
JDK8, so there may rise nasty issues and very unhappy users.
Major incompatibility is in encapsulation. What was private, is now
really private and if one was using it (and it was common) then the
code will stop working. Unluckily, most of those issues are not only
build time issues, but runtime issues, so hard to spot without proper
test coverage.
=== A bit of history to recall: ===
version (upstream support) - fedora state
* Java SE 6 (LTS 2006-cca2014) - added as techpreview in F8 replaced
GCJ around F13. See https://fedoraproject.org/wiki/Releases
* Java SE 7 (LTS 2011-2020(?)) - entered Fedora as tech preview
around F16/17 replaced JDK 6 as System JDK in F17
* Java SE 8 (LTS 2014-2026(???)) - entered Fedora as tech preview in
F19 replaced JDK 7 as System JDK in F21. JDK6 and JDK7 later returned
as community driven java-1-{6,7}-0-openjdk-legacy packages for a while
* Java SE 9 (2017-2018) - entered Fedora around F26 as secondary,
java-1.9.0-openjdk alongside java-1.8.0-openjdk
* Java SE 10 (2018-2019) - entered F28 as secondary,
java-latest-openjdk alongside java-1.8.0-openjdk
* Java SE 11 (LTS 2018-??) - entered Fedora as tech preview in F29
together with java-latest-openjdk and java-1.8.0-openjdk
* Java SE 12 (2019) - updated java-latest-openjdk transparently and
keept going alongside java-1.8.0-openjdk and alongside
java-11-openjdk
* Java SE 13 (2019-2020) - updated java-latest-openjdk transparently
and keept going alongside java-1.8.0-openjdk and alongside
java-11-openjdk
* Java SE 14 (March 2020-2021(?)) - is updating java-latest-openjdk
transparently and will continue to live next to any system JDK(s)
* Java SE 15 (2020(?)-2021(?)) - will update java-latest-openjdk
transparently and will continue to live next to any system JDK(s)
* Java SE 16 () - will update java-latest-openjdk transparently and
will continue to live next to any system JDK(s)
* Java SE 17 (LTS) - will very likely update java-latest-openjdk
transparently and will become future system JDK java-17-openjdk some
year later
* Java SE 18 () - will update java-latest-openjdk transparently and
will continue to live next to any system JDK(s)
* ....
=== "Political disclaimer" ===
In previous bumps, we, Red Hat's openjdk team, were a driving force to
bump the system JDK. In this case, we are a bit reluctant, but the
desire from users to bump the JDK seems strong. We are quite happy to
skip JDK11 as system JDK at all, and jump directly from 8 to 17 in
some three years.
== Benefit to Fedora ==
JDK11 is out for some time, and most of the bleeding edge
distributions already make it default. Most of the projects already
adapted new features and make necessary forward-compatible chnages.
Although we can can expect some family of packages to remain on jdk8
for ever, [https://en.wikiquote.org/wiki/Dune_(film) the spice should
flow]
== Scope ==
=== keep java-1.8-0-openjdk but remove its java/javac versionless
provides, make java-11-openjdk providing java, javac and other
versionless provides ===
* will guarantee fedora to be pure JDK11 distro.
* will allow maintainers of JDK9 or up incompatible packages to keep
using JDK8, however this is just false hope.
** if such an package depends on package build by JDK11, JDK8 will not
be able to pick up that dependency.
** this may lead to quite a lot of bundling or compat. packages, but
may be acceptable
** people developing JDK8 applications will very likely stay with fedora:)
While quite a lot of users will rejoice, there may be cases where
application is very hard to migrate to JDK11, so the contingency plan
should be taken very serious.
=== Other possible approaches already discarded by various discussions ===
(see wiki page)
=== Other ===
* Proposal owners:
** based on above, adapt jdk8 and jdk11 package provides
** If necessary tune the build environment
* Other developers:
** based on selected approach to tune the main build tools
*** at least jpackage-tools and maven will be very likely affected
** based on selected approach to tune the rpmbuild/macros
** many java package maintainers will maybe need to adapt theirs packages
*** After the approach is agreed, mass rebuild must be performed
*** FTBFS bugs connected with this proposal, maybe with jira ticket to
allow discussion.
*** Solutions to most common errors should be gathered and published
* Release engineering: [https://pagure.io/releng/issue/9347 9347]
** mass rebuild will be required for this change
* Policies and guidelines: how to deal with build failures, eventually
how to use some jdk11 specific build features will be provided
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Once the change is implemented properly, the update should be flawless
and seamless
== How To Test ==
* Depends on selected approach, only JRE11 should remain the only
system JDK after installing base javastack on clean system
* Both jdk8 and jdk11 can live togehter on system
* jdk11 will be selected by default and will run most of the base java stack
* todo, add few java-package to isntall examples, hopefully for jdk11 only
== User Experience ==
* Standard user should be still be able to use java stack without even
noticing the chnage.
* Standard developer should be still be able developer any java
application comfortably
* Standard packager will not suffer to much, and should be able to
pack any java application for fedora
== Dependencies ==
Around 2600 packages will need attendance
$ repoquery -q --whatrequires java-headless |wc -l
2481
$ repoquery -q --whatrequires java | wc -l
78
$ repoquery -q --whatrequires java-devel | wc -l
21
Packages needing major work will be
* java-1.8.0-openjdk
* java-11-openjdk
* icedtea-web
== Contingency Plan ==
* If the mass rebuild, after the change application, breaks to much
packages, or some important will be unfixable, jdk8 must be restored
back to the position of system jdk.
* Contingency mechanism: Return jdk8 as system jdk and mass rebuild
again. Note, that this may be very hard, because during build of
packages by jdk8, by jdk11 built dependencies will be picekd up, so
build will fail. Maybe several iterations of mass rebuild will be
needed.
* Contingency deadline: beta freeze
* Blocks release? Yes
* Blocks product? N/A
* Generally going back will be imho impossible. Once the decision is
taken, javastack should be fixed, and where it can not be fixed, it
had to migrate to compact packages, or bundled-dependencies pacages or
be orphaned.
== Documentation ==
* oracle11 release notes:
https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449....
* openjdk11 jeps: https://openjdk.java.net/projects/jdk/11/
* As we are moving from java8 to 11, and jdk9 is what brought in
breaking changes, providing also 9 and 10:
** openjd10 https://openjdk.java.net/projects/jdk/10/
** openjd9 https://openjdk.java.net/projects/jdk9/
** oracle10 https://www.oracle.com/technetwork/java/javase/10-relnotes-4108314.html
** oracle9 https://www.oracle.com/technetwork/java/javase/9-relnotes-3622618.html
*** where jdk9 migration
https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899...
is quite useful for this proposal
* todo, gather most common issues packagers can face and provide solutions
** :
** :
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
10:04 a.m.
New subject: Fedora 33 System-Wide Change proposal: java-11-openjdk as system
JDK in F33
On 30. 03. 20 16:04, Ben Cotton wrote:
* Contingency mechanism: Return jdk8 as system jdk and mass rebuild
again. Note, that this may be very hard, because during build of
packages by jdk8, by jdk11 built dependencies will be picekd up, so
build will fail. Maybe several iterations of mass rebuild will be
needed.
Can we lease do this in a side tag instead and verify basic functionality before
we merge it to rawhide? Than the contingency might just be: Don't merge the side
tag.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:47 a.m.
New subject: Fedora 33 System-Wide Change proposal: java-11-openjdk as system
JDK in F33
On 3/30/20 5:04 PM, Miro Hrončok wrote:
On 30. 03. 20 16:04, Ben Cotton wrote:
> * Contingency mechanism: Return jdk8 as system jdk and mass rebuild
> again. Note, that this may be very hard, because during build of
> packages by jdk8, by jdk11 built dependencies will be picekd up, so
> build will fail. Maybe several iterations of mass rebuild will be
> needed.
Can we lease do this in a side tag instead and verify basic functionality before we merge
it to
rawhide? Than the contingency might just be: Don't merge the side tag.
Sounds like good idea..the way how to go. Only I'm not familiar with how it
works.
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com M: +420775390109
11:52 a.m.
New subject: Fedora 33 System-Wide Change proposal: java-11-openjdk as system
JDK in F33
On 30. 03. 20 17:47, Jiri Vanek wrote:
On 3/30/20 5:04 PM, Miro Hrončok wrote:
> On 30. 03. 20 16:04, Ben Cotton wrote:
>> * Contingency mechanism: Return jdk8 as system jdk and mass rebuild
>> again. Note, that this may be very hard, because during build of
>> packages by jdk8, by jdk11 built dependencies will be picekd up, so
>> build will fail. Maybe several iterations of mass rebuild will be
>> needed.
>
> Can we lease do this in a side tag instead and verify basic functionality before we
merge it to
> rawhide? Than the contingency might just be: Don't merge the side tag.
>
Sounds like good idea..the way how to go. Only I'm not familiar with how it works.
Note that it implies that the change owners coordinate the rebuilds.
See this documentation for how we do Python upgrades of this sort (except in
Python, we need to rebuild "everything" and in a correct order, while the Java
thing seem to generally run fine when built with an older version, so tings get
easier for you):
https://fedoraproject.org/wiki/SIGs/Python/UpgradingPython#Once_ready.2C_...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:45 a.m.
New subject: Fedora 33 System-Wide Change proposal: java-11-openjdk as system
JDK in F33
On 30. 03. 20 18:52, Miro Hrončok wrote:
On 30. 03. 20 17:47, Jiri Vanek wrote:
> On 3/30/20 5:04 PM, Miro Hrončok wrote:
>> On 30. 03. 20 16:04, Ben Cotton wrote:
>>> * Contingency mechanism: Return jdk8 as system jdk and mass rebuild
>>> again. Note, that this may be very hard, because during build of
>>> packages by jdk8, by jdk11 built dependencies will be picekd up, so
>>> build will fail. Maybe several iterations of mass rebuild will be
>>> needed.
>>
>> Can we lease do this in a side tag instead and verify basic functionality
>> before we merge it to
>> rawhide? Than the contingency might just be: Don't merge the side tag.
>>
> Sounds like good idea..the way how to go. Only I'm not familiar with how it
> works.
Note that it implies that the change owners coordinate the rebuilds.
See this documentation for how we do Python upgrades of this sort (except in
Python, we need to rebuild "everything" and in a correct order, while the Java
thing seem to generally run fine when built with an older version, so tings get
easier for you):
https://fedoraproject.org/wiki/SIGs/Python/UpgradingPython#Once_ready.2C_...
Feel free to reach out to me in case you'd like to talk about this more. The
linked document is not very user friendly.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:11 a.m.
New subject: Fedora 33 System-Wide Change proposal: java-11-openjdk as system
JDK in F33
On 30. 03. 20 16:04, Ben Cotton wrote:
=== Other ===
* Proposal owners:
** based on above, adapt jdk8 and jdk11 package provides
** If necessary tune the build environment
* Other developers:
** based on selected approach to tune the main build tools
*** at least jpackage-tools and maven will be very likely affected
** based on selected approach to tune the rpmbuild/macros
** many java package maintainers will maybe need to adapt theirs packages
*** After the approach is agreed, mass rebuild must be performed
*** FTBFS bugs connected with this proposal, maybe with jira ticket to
allow discussion.
I don't understand who does all the hard work. Will the change owners just
change the default and go away, or will the change owners handle the rebuilds?
As a side not, please don't mix in Jira tickets, that sounds RH internal to me.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:38 a.m.
New subject: Fedora 33 System-Wide Change proposal: java-11-openjdk as system
JDK in F33
On 3/30/20 5:11 PM, Miro Hrončok wrote:
Thanx!
thanx a lot,
J.
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com M: +420775390109
On 30. 03. 20 16:04, Ben Cotton wrote:
> === Other ===
> * Proposal owners:
> ** based on above, adapt jdk8 and jdk11 package provides
> ** If necessary tune the build environment
>
> * Other developers:
> ** based on selected approach to tune the main build tools
> *** at least jpackage-tools and maven will be very likely affected
> ** based on selected approach to tune the rpmbuild/macros
> ** many java package maintainers will maybe need to adapt theirs packages
> *** After the approach is agreed, mass rebuild must be performed
> *** FTBFS bugs connected with this proposal, maybe with jira ticket to
> allow discussion.
Thank you for bringing it up!
I don't understand who does all the hard work. Will the change owners just change the
default and go
away, or will the change owners handle the rebuilds?
We will handle the tuning of jdk8 and jdk11 rpms. Also we will do an initial testing if it
does what
it should.
Once it is done, mass rebuild is launched. we will then see. But it will be in on
individual package
owners to fix theirs packages.
We will definitely help where necessary or where needed, and will most likely gather the
most common
cases, but to push to not-owned repos... only in critical cases.
Of course we can reconsider, but it is not on powers of few (5?) individuals to fix 2500
packages,
even if it will be only two or three most common cases.
As for the runtime part, it is another story. There again we will do everything necessary
to fix the
problems both usptream and downstream, but the runtime casaes will flow up only in later
stages of
lifecycle of f33. Possibly even after f33 release. Note, that if there is serious
runtime issues,
then it would be really poorly written usptream application or very outdated downstream,
not broken
migration. Still the help will be attempted to be provided.
As a side not, please don't mix in Jira tickets, that sounds RH internal to me.
Sure. If I did, then not intentionally. By jira ticket in the above I had in mind general
ticket on
pagure or similarly. The word jira did not belonged here. fixed the doc.
10:47 a.m.
New subject: Fedora 33 System-Wide Change proposal: java-11-openjdk as
system JDK in F33
----- Original Message -----
From: "Jiri Vanek" <jvanek(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>, "Miro Hrončok"
<mhroncok(a)redhat.com>, "Deepak Bhole" <dbhole(a)redhat.com>,
"Severin Gehwolf" <sgehwolf(a)redhat.com>, "Omair Majid"
<omajid(a)redhat.com>
Sent: Monday, March 30, 2020 11:38:34 AM
Subject: Re: Fedora 33 System-Wide Change proposal: java-11-openjdk as system JDK in F33
On 3/30/20 5:11 PM, Miro Hrončok wrote:
> On 30. 03. 20 16:04, Ben Cotton wrote:
>> === Other ===
>> * Proposal owners:
>> ** based on above, adapt jdk8 and jdk11 package provides
>> ** If necessary tune the build environment
>>
>> * Other developers:
>> ** based on selected approach to tune the main build tools
>> *** at least jpackage-tools and maven will be very likely affected
>> ** based on selected approach to tune the rpmbuild/macros
>> ** many java package maintainers will maybe need to adapt theirs packages
>> *** After the approach is agreed, mass rebuild must be performed
>> *** FTBFS bugs connected with this proposal, maybe with jira ticket to
>> allow discussion.
Thank you for bringing it up!
>
> I don't understand who does all the hard work. Will the change owners just
> change the default and go
> away, or will the change owners handle the rebuilds?
We will handle the tuning of jdk8 and jdk11 rpms. Also we will do an initial
testing if it does what
it should.
Once it is done, mass rebuild is launched. we will then see. But it will be
in on individual package
owners to fix theirs packages.
We will definitely help where necessary or where needed, and will most likely
gather the most common
cases, but to push to not-owned repos... only in critical cases.
Of course we can reconsider, but it is not on powers of few (5?) individuals
to fix 2500 packages,
even if it will be only two or three most common cases.
As for the runtime part, it is another story. There again we will do
everything necessary to fix the
problems both usptream and downstream, but the runtime casaes will flow up
only in later stages of
lifecycle of f33. Possibly even after f33 release. Note, that if there is
serious runtime issues,
then it would be really poorly written usptream application or very outdated
downstream, not broken
migration. Still the help will be attempted to be provided.
For one example here, take the long-standing Debian ticket against Dogtag:
https://www.pagure.io/dogtagpki/issue/3088
OpenJDK 11 moved to TLS v1.3, but didn't fully implement the spec: PHA isn't
available. This is a requirement for our particular application.
It isn't clear why forcing TLS v1.2 didn't fix this issue. TLS v1.2 works fine
on OpenJDK 8. IMO, this makes it a JDK11 bug. And not the type we have time to
debug and figure out what broke in OpenJDK.
With the introduction of JSS's SSLEngine, we can work around this problem, but
that isn't yet merged.
https://github.com/dogtagpki/jss/pull/150
My 2c., but I hope help is given, especially in testing the new packages to
make sure nothing subtle broke.
- Alex
>
> As a side not, please don't mix in Jira tickets, that sounds RH internal to
> me.
Sure. If I did, then not intentionally. By jira ticket in the above I had in
mind general ticket on
pagure or similarly. The word jira did not belonged here. fixed the doc.
>
Thanx!
thanx a lot,
J.
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com M: +420775390109
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
11:36 a.m.
New subject: Fedora 33 System-Wide Change proposal: java-11-openjdk as system
JDK in F33
On 3/30/20 4:47 PM, Alex Scheel wrote:
For one example here, take the long-standing Debian ticket against
Dogtag:
https://www.pagure.io/dogtagpki/issue/3088
OpenJDK 11 moved to TLS v1.3, but didn't fully implement the spec: PHA isn't
available. This is a requirement for our particular application.
It isn't clear why forcing TLS v1.2 didn't fix this issue. TLS v1.2 works fine
on OpenJDK 8. IMO, this makes it a JDK11 bug. And not the type we have time to
debug and figure out what broke in OpenJDK.
With the introduction of JSS's SSLEngine, we can work around this problem, but
that isn't yet merged.
https://github.com/dogtagpki/jss/pull/150
Tricky. It's kinda inevitable that some things will break at some time. We
have to decide whether Dogtag is a blocker for JDK 11 as system JDK.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
12:05 p.m.
New subject: Fedora 33 System-Wide Change proposal: java-11-openjdk as
system JDK in F33
----- Original Message -----
From: "Andrew Haley" <aph(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>, "Alex Scheel" <ascheel(a)redhat.com>
Cc: "Omair Majid" <omajid(a)redhat.com>
Sent: Monday, March 30, 2020 12:36:23 PM
Subject: Re: Fedora 33 System-Wide Change proposal: java-11-openjdk as system JDK in F33
On 3/30/20 4:47 PM, Alex Scheel wrote:
> For one example here, take the long-standing Debian ticket against Dogtag:
>
> https://www.pagure.io/dogtagpki/issue/3088
>
> OpenJDK 11 moved to TLS v1.3, but didn't fully implement the spec: PHA
> isn't
> available. This is a requirement for our particular application.
>
> It isn't clear why forcing TLS v1.2 didn't fix this issue. TLS v1.2 works
> fine
> on OpenJDK 8. IMO, this makes it a JDK11 bug. And not the type we have time
> to
> debug and figure out what broke in OpenJDK.
>
>
> With the introduction of JSS's SSLEngine, we can work around this problem,
> but
> that isn't yet merged.
>
> https://github.com/dogtagpki/jss/pull/150
Tricky. It's kinda inevitable that some things will break at some time. We
have to decide whether Dogtag is a blocker for JDK 11 as system JDK.
FWIW, Dogtag is part of IPA, which is already a blocker for GA releases. But,
we're concurrently working on an alternative SSLEngine implementation that will
fix our problems by not using the JDK TLS stack.
- Alex
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
10:26 a.m.
New subject: Fedora 33 System-Wide Change proposal: java-11-openjdk as system
JDK in F33
On Mon, Mar 30, 2020 at 4:05 PM Ben Cotton <bcotton(a)redhat.com> wrote:
https://fedoraproject.org/wiki/Changes/Java11 .
== Summary ==
Update the system JDK in Fedora from java-1.8.0-openjdk to java-11-openjdk.
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: <jvanek(a)redhat.com>
* Product: java and java stack
* Responsible WG: java-sig (java and java-maint)
== Detailed Description ==
Fedora currently ships:
* java-1.8.0-openjdk (LTS)
* java-11-openjdk (LTS)
* an java-latest-openjdk (on jdk14, STS).
where the version-less '''java''' and
'''javac''' (and friends) are
provided by java-1.8.0-openjdk.
So every package honoring the packaging rules and requiring java ,
java-headless or java-devel is built in brew by
What is brew?
java-1.8.0-openjdk-devel and pulls java-1.8.0-openjdk(-headless) in
runtime (See [https://fedoraproject.org/wiki/Java java] ). Also
javapackaging-tools are using java-1.8.0-openjdk as hardcoded runtime
(see
[https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_...
changes])
Debian already moved to JDK11 as system JDK, and in Fedora community
we can hear for last two years increasing voices for jdk11 to become
the system one. And apparently the java stack is really quite ready
for JDK11. Fedora is considered to be bleeding edge distribution, so
we should move forward, however JDK11 is not 100% compatible with
JDK8, so there may rise nasty issues and very unhappy users.
Major incompatibility is in encapsulation. What was private, is now
really private and if one was using it (and it was common) then the
code will stop working. Unluckily, most of those issues are not only
build time issues, but runtime issues, so hard to spot without proper
test coverage.
=== A bit of history to recall: ===
version (upstream support) - fedora state
* Java SE 6 (LTS 2006-cca2014) - added as techpreview in F8 replaced
GCJ around F13. See https://fedoraproject.org/wiki/Releases
* Java SE 7 (LTS 2011-2020(?)) - entered Fedora as tech preview
around F16/17 replaced JDK 6 as System JDK in F17
* Java SE 8 (LTS 2014-2026(???)) - entered Fedora as tech preview in
F19 replaced JDK 7 as System JDK in F21. JDK6 and JDK7 later returned
as community driven java-1-{6,7}-0-openjdk-legacy packages for a while
* Java SE 9 (2017-2018) - entered Fedora around F26 as secondary,
java-1.9.0-openjdk alongside java-1.8.0-openjdk
* Java SE 10 (2018-2019) - entered F28 as secondary,
java-latest-openjdk alongside java-1.8.0-openjdk
* Java SE 11 (LTS 2018-??) - entered Fedora as tech preview in F29
together with java-latest-openjdk and java-1.8.0-openjdk
* Java SE 12 (2019) - updated java-latest-openjdk transparently and
keept going alongside java-1.8.0-openjdk and alongside
java-11-openjdk
* Java SE 13 (2019-2020) - updated java-latest-openjdk transparently
and keept going alongside java-1.8.0-openjdk and alongside
java-11-openjdk
* Java SE 14 (March 2020-2021(?)) - is updating java-latest-openjdk
transparently and will continue to live next to any system JDK(s)
* Java SE 15 (2020(?)-2021(?)) - will update java-latest-openjdk
transparently and will continue to live next to any system JDK(s)
* Java SE 16 () - will update java-latest-openjdk transparently and
will continue to live next to any system JDK(s)
* Java SE 17 (LTS) - will very likely update java-latest-openjdk
transparently and will become future system JDK java-17-openjdk some
year later
* Java SE 18 () - will update java-latest-openjdk transparently and
will continue to live next to any system JDK(s)
* ....
=== "Political disclaimer" ===
In previous bumps, we, Red Hat's openjdk team, were a driving force to
bump the system JDK. In this case, we are a bit reluctant, but the
desire from users to bump the JDK seems strong. We are quite happy to
skip JDK11 as system JDK at all, and jump directly from 8 to 17 in
some three years.
Skipping all the way from 8 → 17 sounds like there would be even more
potential for breaking things, so switching to 11 as an intermediary
step seems like a good idea to me.
== Benefit to Fedora ==
JDK11 is out for some time, and most of the bleeding edge
distributions already make it default. Most of the projects already
adapted new features and make necessary forward-compatible chnages.
Although we can can expect some family of packages to remain on jdk8
for ever, [https://en.wikiquote.org/wiki/Dune_(film) the spice should
flow]
== Scope ==
=== keep java-1.8-0-openjdk but remove its java/javac versionless
provides, make java-11-openjdk providing java, javac and other
versionless provides ===
* will guarantee fedora to be pure JDK11 distro.
* will allow maintainers of JDK9 or up incompatible packages to keep
using JDK8, however this is just false hope.
** if such an package depends on package build by JDK11, JDK8 will not
be able to pick up that dependency.
** this may lead to quite a lot of bundling or compat. packages, but
may be acceptable
** people developing JDK8 applications will very likely stay with fedora:)
While quite a lot of users will rejoice, there may be cases where
application is very hard to migrate to JDK11, so the contingency plan
should be taken very serious.
=== Other possible approaches already discarded by various discussions ===
(see wiki page)
=== Other ===
* Proposal owners:
** based on above, adapt jdk8 and jdk11 package provides
** If necessary tune the build environment
* Other developers:
** based on selected approach to tune the main build tools
*** at least jpackage-tools and maven will be very likely affected
** based on selected approach to tune the rpmbuild/macros
** many java package maintainers will maybe need to adapt theirs packages
*** After the approach is agreed, mass rebuild must be performed
*** FTBFS bugs connected with this proposal, maybe with jira ticket to
allow discussion.
*** Solutions to most common errors should be gathered and published
* Release engineering: [https://pagure.io/releng/issue/9347 9347]
** mass rebuild will be required for this change
* Policies and guidelines: how to deal with build failures, eventually
how to use some jdk11 specific build features will be provided
* Trademark approval: N/A (not needed for this Change)
I agree with Miro. These changes should be done in a side tag, or even
better, also tested in COPR before that. Kind of like how the python
3.9 bringup is happening right now. This way, potential issues can be
caught early.
Additionally, just switching 1.8.0 → 11 and walking away will probably
break rawhide packages for years to come, given the state the Java
stack is in. Some Java packagers / packages will definitely need some
help there. The Stewardship SIG can help with some issues (a few
members are provenpackagers), but our resources are limited, and we
"only" maintain ~200 Java packages directly.
Fabio
PS: I hope my post doesn't sound too negative. I'm happy this switch
is finally happening :)
> == Upgrade/compatibility impact ==
> Once the change is implemented properly, the update should be flawless
> and seamless
>
>
> == How To Test ==
> * Depends on selected approach, only JRE11 should remain the only
> system JDK after installing base javastack on clean system
> * Both jdk8 and jdk11 can live togehter on system
> * jdk11 will be selected by default and will run most of the base java stack
> * todo, add few java-package to isntall examples, hopefully for jdk11 only
>
>
> == User Experience ==
> * Standard user should be still be able to use java stack without even
> noticing the chnage.
> * Standard developer should be still be able developer any java
> application comfortably
> * Standard packager will not suffer to much, and should be able to
> pack any java application for fedora
>
>
> == Dependencies ==
> Around 2600 packages will need attendance
> $ repoquery -q --whatrequires java-headless |wc -l
> 2481
> $ repoquery -q --whatrequires java | wc -l
> 78
> $ repoquery -q --whatrequires java-devel | wc -l
> 21
> Packages needing major work will be
> * java-1.8.0-openjdk
> * java-11-openjdk
> * icedtea-web
>
>
> == Contingency Plan ==
> * If the mass rebuild, after the change application, breaks to much
> packages, or some important will be unfixable, jdk8 must be restored
> back to the position of system jdk.
> * Contingency mechanism: Return jdk8 as system jdk and mass rebuild
> again. Note, that this may be very hard, because during build of
> packages by jdk8, by jdk11 built dependencies will be picekd up, so
> build will fail. Maybe several iterations of mass rebuild will be
> needed.
> * Contingency deadline: beta freeze
> * Blocks release? Yes
> * Blocks product? N/A
> * Generally going back will be imho impossible. Once the decision is
> taken, javastack should be fixed, and where it can not be fixed, it
> had to migrate to compact packages, or bundled-dependencies pacages or
> be orphaned.
>
> == Documentation ==
> * oracle11 release notes:
> https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449....
> * openjdk11 jeps: https://openjdk.java.net/projects/jdk/11/
> * As we are moving from java8 to 11, and jdk9 is what brought in
> breaking changes, providing also 9 and 10:
> ** openjd10 https://openjdk.java.net/projects/jdk/10/
> ** openjd9 https://openjdk.java.net/projects/jdk9/
> ** oracle10 https://www.oracle.com/technetwork/java/javase/10-relnotes-4108314.html
> ** oracle9 https://www.oracle.com/technetwork/java/javase/9-relnotes-3622618.html
> *** where jdk9 migration
>
https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899...
> is quite useful for this proposal
> * todo, gather most common issues packagers can face and provide solutions
> ** :
> ** :
>
> --
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
10:43 a.m.
New subject: Fedora 33 System-Wide Change proposal: java-11-openjdk as system
JDK in F33
On 3/30/20 5:26 PM, Fabio Valentini wrote:
On Mon, Mar 30, 2020 at 4:05 PM Ben Cotton <bcotton(a)redhat.com>
wrote:
>
> https://fedoraproject.org/wiki/Changes/Java11 .
>
> == Summary ==
> Update the system JDK in Fedora from java-1.8.0-openjdk to java-11-openjdk.
>
> == Owner ==
> * Name: [[User:jvanek| Jiri Vanek]]
> * Email: <jvanek(a)redhat.com>
> * Product: java and java stack
> * Responsible WG: java-sig (java and java-maint)
>
> == Detailed Description ==
> Fedora currently ships:
> * java-1.8.0-openjdk (LTS)
> * java-11-openjdk (LTS)
> * an java-latest-openjdk (on jdk14, STS).
> where the version-less '''java''' and
'''javac''' (and friends) are
> provided by java-1.8.0-openjdk.
>
> So every package honoring the packaging rules and requiring java ,
> java-headless or java-devel is built in brew by
What is brew?
Sorry, that was supposed to be koji. Fixed in the document.
> java-1.8.0-openjdk-devel and pulls java-1.8.0-openjdk(-headless) in
> runtime (See [https://fedoraproject.org/wiki/Java java] ). Also
> javapackaging-tools are using java-1.8.0-openjdk as hardcoded runtime
> (see
[https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_...
> changes])
...
>
> === "Political disclaimer" ===
> In previous bumps, we, Red Hat's openjdk team, were a driving force to
> bump the system JDK. In this case, we are a bit reluctant, but the
> desire from users to bump the JDK seems strong. We are quite happy to
> skip JDK11 as system JDK at all, and jump directly from 8 to 17 in
> some three years.
Skipping all the way from 8 → 17 sounds like there would be even more
potential for breaking things, so switching to 11 as an intermediary
step seems like a good idea to me.
Right you are. thank you.
> == Benefit to Fedora ==
> JDK11 is out for some time, and most of the bleeding edge
> distributions already make it default. Most of the projects already
> adapted new features and make necessary forward-compatible chnages.
> Although we can can expect some family of packages to remain on jdk8
> for ever, [https://en.wikiquote.org/wiki/Dune_(film) the spice should
> flow]
...
> * Other developers:
> ** based on selected approach to tune the main build tools
> *** at least jpackage-tools and maven will be very likely affected
> ** based on selected approach to tune the rpmbuild/macros
> ** many java package maintainers will maybe need to adapt theirs packages
> *** After the approach is agreed, mass rebuild must be performed
> *** FTBFS bugs connected with this proposal, maybe with jira ticket to
> allow discussion.
> *** Solutions to most common errors should be gathered and published
> * Release engineering: [https://pagure.io/releng/issue/9347 9347]
> ** mass rebuild will be required for this change
> * Policies and guidelines: how to deal with build failures, eventually
> how to use some jdk11 specific build features will be provided
> * Trademark approval: N/A (not needed for this Change)
I agree with Miro. These changes should be done in a side tag, or even
better, also tested in COPR before that. Kind of like how the python
3.9 bringup is happening right now. This way, potential issues can be
caught early.
Not sure how the coper cna be managed. As side tag, yes, woudl be awesome.
Additionally, just switching 1.8.0 → 11 and walking away will probably
break rawhide packages for years to come, given the state the Java
stack is in. Some Java packagers / packages will definitely need some
help there. The Stewardship SIG can help with some issues (a few
members are provenpackagers), but our resources are limited, and we
"only" maintain ~200 Java packages directly.
As replied to Miro. Help will definitely be provided. But direct touch to packages(two
provenpackagers on board here), only in great need. Otherwise the few of us, incluing
fwhat
remained from java-sig, would get swamped.
Hope that sounds reasonable.
J.
Fabio
PS: I hope my post doesn't sound too negative. I'm happy this switch
is finally happening :)
Not at all. Those must be clarified. Tahnx, cross fingers :)
1486
days inactive
1487
days old
11 comments
6 participants
participants (6)
-
Alex Scheel -
Andrew Haley -
Ben Cotton -
Fabio Valentini -
Jiri Vanek -
Miro Hrončok