0

I can see that Ubuntu 16.04 (Xenial Xerus) did not get Java 11 packages through official updates. However Ubunu 18.04 LTS (Bionic Beaver) got Java 11 even though 18.04 release date is earlier than Java 11 release date?

I was wondering if Ubunu 18.04 LTS (Bionic Beaver) will get Java 17? or if it does not exist in release, it is not included ever?

Is there an official document describing this for Java LTS releases? I found the SRU but it seems to have somewhat conflicting information.

For example the https://wiki.ubuntu.com/StableReleaseUpdates (SRU) clearly explains in 2.2. Other safe cases

In the following cases a stable release update is also applicable as they have a low potential for regressing existing installations but a high potential for improving the user experience, particularly for Long Term Support releases.

in the same heading, it also says:

For Long Term Support releases we sometimes want to introduce new features. They must not change the behaviour on existing installations (e. g. entirely new packages are usually fine).

Now Java 17 would be a discrete update, as it would not effect existing Java 8/11 installations. Because for example providing openjdk-11-jdk package does not do any changes to systems where openjdk-8-jdk package is installed. Therefore, logically thinking the Ubuntu documentation says that newer LTS Java updates should gladly be included in 18.04 when Java 17 is available.

However this was not the case for 16.04 so why isn't Java 11 included with 16.04? I don't quite understand this.

In addition, for example 14.04 was released with kernel 3.x but afterwards updates to 4.x was introduced. This is much more disruptive update compared to adding a new Java XX version package to repository.

Thanks!

yurtesen
  • 460
  • @karel not really because a major update of Java is given as a separate package so it would not interfere with any existing installation. I added link to SRU where it says that entirely new packages are usually fine. So I am trying to find out why Java was treated this way... – yurtesen Feb 10 '20 at 11:49
  • The kernel update from the 3.x series to 4.x was necessary because some new hardware would not run without it. – karel Feb 10 '20 at 12:07
  • @karel Some software won't run without Java 11 LTS being available for Ubuntu 16.04... isn't it even more important that existing installations stay compatible with widest possible range of software? – yurtesen Feb 10 '20 at 12:17
  • If Java isn't the latest version the user can download it, but if Ubuntu isn't compatible with the user's new laptop, then the user is stuck. – karel Feb 10 '20 at 12:20
  • @karel A user can also download any kernel and install, it does not have to be from official repository. But you are missing the point. We are talking about LTS releases which are used for long time. It is not target of LTS to support latest hardware. User in your example can always install a newer ubuntu version to his brand new laptop as well. But people who has long running servers do not have this option. These are releases installed and used for a long time without upgrading. When the 4.x kernel came to 14.04, the 16.04 was only 1 month away from release. 4.x kernel was available on 15.10 – yurtesen Feb 10 '20 at 12:58
  • @yurtesen your question seems to effectively boil down to "Why isn't Java backported?" which is indeed addressed in the suggested duplicate question. If you want to discuss with developers a real change in policy ("I think Java should be backported regularly") this is the wrong venue - take that to the dev mailing list. You must persuade the Foundations Team to agree to the change of policy. – user535733 Feb 19 '20 at 14:41
  • @user535733 The link you provided deals with software where you replace existing package with another newer package. I am not saying if Java17 should or should not be available. I am asking somebody to answer if it will be available or not and if not, why not? Because the policy is to add important software if it does not interfere with existing installations, as explained in SRU. There is no need to change policy whatsoever. eh? – yurtesen Feb 20 '20 at 11:36
  • 1
    @yurtesen the SRU process has to also verify all the reverse dependencies - anything depending on the Java packages - works in that way. This isn't an SRU-able issue anyways, as this would be a straight backport, and nobody currently wants to 'support' that backport automatically. You're also talking about something that would be MONTHS in the future, so nobody can say at the moment. If you feel strongly about this, email to ubuntu-devel-discuss[@]lists.ubuntu.com and ask for someone to look into the sanity of a backport or such of Java to the older releases. Don't expect a fast reply, tho – Thomas Ward Feb 20 '20 at 15:12
  • @ThomasWard I don't understand what you mean about reverse dependencies. You can happily keep Java11 installed and on the side install Java17 and your existing programs can keep on using Java11. Same as today, you can have Java8 and Java11 installed at the same time...

    But I guess the answer to my question is that there is no real reason but it won't happen... anyway thanks for the responses.

     – yurtesen Feb 21 '20 at 09:01
  • 1
    @yurtesen the other problem is they don't like keeping multiple versions in backports. We're also still two months out before we get to the point backports would be a factor. – Thomas Ward Feb 21 '20 at 17:13
  • @ThomasWard thanks for the responses. I guess the final point that it won't be included, and that is what is important. 3rd party java repository should be used in LTS. I still would say this is not exactly the same question as linked, because Java fulfills the SRU wiki requirements. But anyway, it does not really matter... Thanks again... – yurtesen Feb 22 '20 at 14:37

0 Answers0