Discussion:
How to have multiple JDKs parallel?
Add Reply
Peter Nabbefeld
2018-09-15 08:56:40 UTC
Reply
Permalink
Hello,

up to JDK 9 I didn't have problems upgrading, but since JDK 10 it always
wants to replace JDK 9, and I guess it will become worse with JDK 11 etc.

I've set "IgnorePkg = jdk9-openjdk jre9-openjdk jre9-openjdk-headless
openjdk9-doc openjdk9-src" in pacman.conf, so now I'm getting warnings
all the time, but I'm not sure what will happen with future updates.

As a Java developer, I need to be able to have multiple JDKs for
compatibility checkings.

Kind regards

Peter
Guus Snijders via arch-general
2018-09-15 09:54:42 UTC
Reply
Permalink
Op 15 sep. 2018 10:56 schreef "Peter Nabbefeld" <***@gmx.de>:


Hello,

up to JDK 9 I didn't have problems upgrading, but since JDK 10 it always
wants to replace JDK 9, and I guess it will become worse with JDK 11 etc.

[...] "IgnorePkg = jdk9-openjdk [...]
As a Java developer, I need to be able to have multiple JDKs for
compatibility checkings.


I honestly don't know much about java, but I guess you don't have real
dependancies on the lower versions (As in: no other packages require them)?

Then perhaps it's an option to edit the PKGBUILD of these lower versions
and modify the name. Something like jdk9-custom etc.
Then the higher versions won't conflict.


Mvg, Guus Snijders
Carsten Mattner via arch-general
2018-09-15 10:05:38 UTC
Reply
Permalink
I have a related question. I tried arch's openjdk packages and those
were successful in displaying Swing UIs.

Then, to check out newer JDKs and IBM's OpenJ9, I grabbed a
build from https://adoptopenjdk.net, and I just couldn't get
any Swing UI to display. It reported many exceptions and that
was it. Tried with different window managers and compositors.

Any idea what's different on Arch or where the adoptopenjdk builds
work?
Olli
2018-09-15 13:22:15 UTC
Reply
Permalink
Post by Peter Nabbefeld
up to JDK 9 I didn't have problems upgrading, but since JDK 10 it always
wants to replace JDK 9, and I guess it will become worse with JDK 11 etc.
starting with Java 9, the OpenJDK changed its release cycle to publish a
new version every six month. Each new version is replacing the previous
one so that there is always only one (the latest) supported version.
Check out e. g. this article for more details:
https://medium.com/codefx-weekly/no-free-java-lts-version-b850192745fb

Since Arch Linux closely follows upstream I think the OpenJDK packages
will follow this policy—and that this is the reason why the package
“jdk10-openjdk” replaced “jdk9-openjdk” entirely. In ten days,
“jdk11-openjdk” will replace “jdk10-openjdk” and so on …
Post by Peter Nabbefeld
As a Java developer, I need to be able to have multiple JDKs for
compatibility checkings.
Since there will be no official OpenJDK builds (no maintenance) for the
older versions anymore, you have to install them manually—or use
Oracle’s builds with longtime support (not for free though). I guess it
would be best to closely follow the latest version and always make sure
your applications are running fine. I heard that new versions should be
backwards compatible (to a certain degree) but cannot find any source
for this.

Regards,
Olli
Jonathon Fernyhough
2018-09-15 17:15:00 UTC
Reply
Permalink
Post by Olli
Each new version is replacing the previous
one so that there is always only one (the latest) supported version.
I think there are technically two supported releases, a long-term- and
short-term-supported release. The current LTS is OpenJDK 8, the next LTS
will be (IIRC) OpenJDK 11, with intervening versions being STS.

J
Olli
2018-09-15 17:54:59 UTC
Reply
Permalink
Post by Jonathon Fernyhough
Each new version is replacing the previous one so that there is
always only one (the latest) supported version.
I think there are technically two supported releases, a long-term- and
short-term-supported release. The current LTS is OpenJDK 8, the next
LTS will be (IIRC) OpenJDK 11, with intervening versions being STS.
LTS versions are only provided by Oracle for their JDK, not for the
OpenJDK. This graphic explains it quite well:
https://medium.com/codefx-weekly/no-free-java-lts-version-b850192745fb
ProgAndy
2018-09-15 18:06:36 UTC
Reply
Permalink
Post by Olli
LTS versions are only provided by Oracle for their JDK, not for the
https://medium.com/codefx-weekly/no-free-java-lts-version-b850192745fb
There won't be any free LTS releases from Oracle, but the AdoptOpenJDK
project wants
to create public LTS releases every three versions beginning with Java 11.
They also want to support Java 8 until 2022
Post by Olli
In addition, every three years one feature release will be designated
as the
Post by Olli
Long Term Supported (LTS) release. We will support LTS releases for at
least
Post by Olli
four years. This assurance will allow you to stay on a well-defined
code stream,
Post by Olli
and give you time to migrate to the next, new, stable, LTS release when it
becomes available.
https://adoptopenjdk.net/support.html
Olli
2018-09-17 10:04:21 UTC
Reply
Permalink
There has ever been an EOL for older JDKs. But sometimes You're bound
to a specific JDK version in Your working environment, so IMO always
replacing is a bad strategy. The problem is, in larger companies it
sometimes takes some weeks or even months until some software is
allowed to be upgraded. And I'd at least want to check which features
are available in which JDK - or which bugs are present.
Well, tell the OpenJDK/Oracle people, they are the ones who came up with
this release cycle. It has nothing to do with Arch Linux.
Guus Snijders via arch-general
2018-09-17 10:34:54 UTC
Reply
Permalink
Post by Olli
There has ever been an EOL for older JDKs. But sometimes You're bound
to a specific JDK version in Your working environment, so IMO always
replacing is a bad strategy. The problem is, in larger companies it
sometimes takes some weeks or even months until some software is
allowed to be upgraded. And I'd at least want to check which features
are available in which JDK - or which bugs are present.
Well, tell the OpenJDK/Oracle people, they are the ones who came up with
this release cycle. It has nothing to do with Arch Linux.
Actually, it's just a user question on how to handle multiple pkg versions.
And that is Arch(user) specific ;).

One option would be to use custom pkg's, another (somewhat easy) method
would be to create a virtual machine for every java version.

In the VM case, add some shared storage and have fun. Just remember to
freeze at least the java pkg in those vm's...


Mvg, Guus Snijders
Luke English
2018-09-17 10:42:37 UTC
Reply
Permalink
Post by Guus Snijders via arch-general
Post by Olli
There has ever been an EOL for older JDKs. But sometimes You're bound
to a specific JDK version in Your working environment, so IMO always
replacing is a bad strategy. The problem is, in larger companies it
sometimes takes some weeks or even months until some software is
allowed to be upgraded. And I'd at least want to check which features
are available in which JDK - or which bugs are present.
Well, tell the OpenJDK/Oracle people, they are the ones who came up with
this release cycle. It has nothing to do with Arch Linux.
Actually, it's just a user question on how to handle multiple pkg versions.
And that is Arch(user) specific ;).
One option would be to use custom pkg's, another (somewhat easy) method
would be to create a virtual machine for every java version.
Isn't that exactly what archlinux-java is for? The way I see it the
original question was related to Arch's replacement of openjdk-9 with
openjdk-10.
Post by Guus Snijders via arch-general
In the VM case, add some shared storage and have fun. Just remember to
freeze at least the java pkg in those vm's...
Mvg, Guus Snijders
Peter Nabbefeld
2018-09-17 11:50:12 UTC
Reply
Permalink
Post by Luke English
Post by Guus Snijders via arch-general
Post by Olli
There has ever been an EOL for older JDKs. But sometimes You're bound
to a specific JDK version in Your working environment, so IMO always
replacing is a bad strategy. The problem is, in larger companies it
sometimes takes some weeks or even months until some software is
allowed to be upgraded. And I'd at least want to check which features
are available in which JDK - or which bugs are present.
Well, tell the OpenJDK/Oracle people, they are the ones who came up with
this release cycle. It has nothing to do with Arch Linux.
Actually, it's just a user question on how to handle multiple pkg versions.
And that is Arch(user) specific ;).
One option would be to use custom pkg's, another (somewhat easy) method
would be to create a virtual machine for every java version.
Isn't that exactly what archlinux-java is for? The way I see it the
original question was related to Arch's replacement of openjdk-9 with
openjdk-10.
Post by Guus Snijders via arch-general
In the VM case, add some shared storage and have fun. Just remember to
freeze at least the java pkg in those vm's...
Mvg, Guus Snijders
Sorry, I accidently sent my earlier response to Olli privately. So one
question has been lost:

Probably, pacman could be extended with an option to change the update
strategy from replace to add?

This would make it a lot easier than building my own packages or even
setup a dedicated VM, as I'm changing JDKs in my IDE on a per-project
base. This just ensures I'm not using newer features for environments
where I cannot use those. BTW, I'm feeling comfortable to use the latest
JDK, but I just want to be able to try out solutions for older ones with
possibly missing features (or just older class file version numbers).
E.g. in some cases some environments cannot work with newer class file
versions, one prominent piece being Maven, as far as I read on some
mailing lists (some plugins seemed to reject work with projects using
JDK 9, but as I still use JDK 8, currently, it's not been my problem).

Kind regards

Peter
Eli Schwartz via arch-general
2018-09-17 13:58:02 UTC
Reply
Permalink
Post by Peter Nabbefeld
Sorry, I accidently sent my earlier response to Olli privately. So one
Probably, pacman could be extended with an option to change the update
strategy from replace to add?
This would make it a lot easier than building my own packages or even
setup a dedicated VM, as I'm changing JDKs in my IDE on a per-project
base. This just ensures I'm not using newer features for environments
where I cannot use those. BTW, I'm feeling comfortable to use the latest
JDK, but I just want to be able to try out solutions for older ones with
possibly missing features (or just older class file version numbers).
E.g. in some cases some environments cannot work with newer class file
versions, one prominent piece being Maven, as far as I read on some
mailing lists (some plugins seemed to reject work with projects using
JDK 9, but as I still use JDK 8, currently, it's not been my problem).
This option already exists. pacman asks you if you want to replace the
one with the other. Just say "no".

The packages neither provide nor conflict each other, so there's
absolutely nothing wrong with doing so. Admittedly, it's no longer a
repo package so it's unsupported, but that was the case whether it was
moved to the AUR or deleted with a replaces.

...

You will get prompted again and again on every pacman -Su "to see if
you're finally ready to do the replacement".
--
Eli Schwartz
Bug Wrangler and Trusted User
Peter Nabbefeld
2018-09-17 14:06:04 UTC
Reply
Permalink
Post by Eli Schwartz via arch-general
Post by Peter Nabbefeld
Sorry, I accidently sent my earlier response to Olli privately. So one
Probably, pacman could be extended with an option to change the update
strategy from replace to add?
This would make it a lot easier than building my own packages or even
setup a dedicated VM, as I'm changing JDKs in my IDE on a per-project
base. This just ensures I'm not using newer features for environments
where I cannot use those. BTW, I'm feeling comfortable to use the latest
JDK, but I just want to be able to try out solutions for older ones with
possibly missing features (or just older class file version numbers).
E.g. in some cases some environments cannot work with newer class file
versions, one prominent piece being Maven, as far as I read on some
mailing lists (some plugins seemed to reject work with projects using
JDK 9, but as I still use JDK 8, currently, it's not been my problem).
This option already exists. pacman asks you if you want to replace the
one with the other. Just say "no".
The packages neither provide nor conflict each other, so there's
absolutely nothing wrong with doing so. Admittedly, it's no longer a
repo package so it's unsupported, but that was the case whether it was
moved to the AUR or deleted with a replaces.
...
You will get prompted again and again on every pacman -Su "to see if
you're finally ready to do the replacement".
That's what I don't want - if I accidently don't type the "n" for some
reason, the JDK will be raplaced. While I could re-install it from the
repo's cache, this is a bit inconvinient. Just adding and moving to the
new one would be great.

Kind regards
Peter
Eli Schwartz via arch-general
2018-09-17 14:21:10 UTC
Reply
Permalink
Post by Peter Nabbefeld
Post by Eli Schwartz via arch-general
You will get prompted again and again on every pacman -Su "to see if
you're finally ready to do the replacement".
That's what I don't want - if I accidently don't type the "n" for some
reason, the JDK will be raplaced. While I could re-install it from the
repo's cache, this is a bit inconvinient. Just adding and moving to the
new one would be great.
So essentially what you really want is a way for pacman to remember your choice. That would require pacman modify its configuration which is something that goes against the current architecture... What would happen instead is pacman.conf could be used to configure this.

I'm not sure if IgnorePkg or HoldPkg would have an effect here...
--
Eli Schwartz
Bug Wrangler and Trusted User
Carsten Mattner via arch-general
2018-09-17 15:48:15 UTC
Reply
Permalink
Post by Eli Schwartz via arch-general
So essentially what you really want is a way for pacman to remember your
choice. That would require pacman modify its configuration which is
something that goes against the current architecture... What would happen
instead is pacman.conf could be used to configure this.
I'm not sure if IgnorePkg or HoldPkg would have an effect here...
The way I read it, what's being suggested is something like Debian's
update-alternatives. https://wiki.debian.org/DebianAlternatives

Or a JVM version manager ala pyenv etc. Not sure.
Guillaume ALAUX via arch-general
2018-09-17 16:20:49 UTC
Reply
Permalink
On Mon, Sep 17, 2018 at 5:48 PM Carsten Mattner via arch-general
Post by Carsten Mattner via arch-general
Post by Eli Schwartz via arch-general
So essentially what you really want is a way for pacman to remember your
choice. That would require pacman modify its configuration which is
something that goes against the current architecture... What would happen
instead is pacman.conf could be used to configure this.
I'm not sure if IgnorePkg or HoldPkg would have an effect here...
The way I read it, what's being suggested is something like Debian's
update-alternatives. https://wiki.debian.org/DebianAlternatives
Or a JVM version manager ala pyenv etc. Not sure.
Just to give some backing: here is the official explanation of what
has already been stated before about JDK versions:

"[…] non‑LTS releases are considered a cumulative set of
implementation enhancements of the most recent LTS release. Once a new
feature release is made available, any previous non‑LTS release will
be considered superseded. For example, Java SE 9 was a non‑LTS release
and immediately superseded by Java SE 10 (also non‑LTS), Java SE 10 in
turn is immediately superseded by Java SE 11." [0]

So keeping OpenJDK 9 in our repo while OpenJDK 10 is out would be the
same as keeping say OpenJDK 8.u181 while OpenJDK 8.u182 is out! Even
though I can understand the (developer) use case, this is clearly out
of Arch Linux' scope.

[0] http://www.oracle.com/technetwork/java/javase/eol-135779.html

Guillaume
ProgAndy
2018-09-17 16:26:04 UTC
Reply
Permalink
Post by Guillaume ALAUX via arch-general
On Mon, Sep 17, 2018 at 5:48 PM Carsten Mattner via arch-general
Post by Carsten Mattner via arch-general
Post by Eli Schwartz via arch-general
So essentially what you really want is a way for pacman to remember your
choice. That would require pacman modify its configuration which is
something that goes against the current architecture... What would happen
instead is pacman.conf could be used to configure this.
I'm not sure if IgnorePkg or HoldPkg would have an effect here...
The way I read it, what's being suggested is something like Debian's
update-alternatives. https://wiki.debian.org/DebianAlternatives
Or a JVM version manager ala pyenv etc. Not sure.
Just to give some backing: here is the official explanation of what
"[…] non‑LTS releases are considered a cumulative set of
implementation enhancements of the most recent LTS release. Once a new
feature release is made available, any previous non‑LTS release will
be considered superseded. For example, Java SE 9 was a non‑LTS release
and immediately superseded by Java SE 10 (also non‑LTS), Java SE 10 in
turn is immediately superseded by Java SE 11." [0]
So keeping OpenJDK 9 in our repo while OpenJDK 10 is out would be the
same as keeping say OpenJDK 8.u181 while OpenJDK 8.u182 is out! Even
though I can understand the (developer) use case, this is clearly out
of Arch Linux' scope.
[0] http://www.oracle.com/technetwork/java/javase/eol-135779.html
Guillaume
This might be a use case for remakepkg to remove the replaces-entry in
the java10 packages.

https://bbs.archlinux.org/viewtopic.php?pid=1771005

---
Andreas
Tinu Weber
2018-09-18 15:25:00 UTC
Reply
Permalink
Post by ProgAndy
This might be a use case for remakepkg to remove the replaces-entry in
the java10 packages.
https://bbs.archlinux.org/viewtopic.php?pid=1771005
*sees people mentioning that tool in serious discussions*
*slightly panicks*

I see that jre10-openjdk does indeed only replace, but not conflict with
jre9-openjdk, so I guess there should be no harm in installing both (but
I have not tested it, so expect things to break):

1. Build and install remakepkg from the AUR
2. Write the following REPKGBUILD file:

repkg extra/jre10-openjdk
remove-replace jre9-openjdk

3. Run `remakepkg`

Then again, this is just an alternative to just fetching Arch's
PKGBUILD file for jre10-openjdk, editing it, and building the full
package yourself.

--Tinu
Eli Schwartz via arch-general
2018-09-18 15:37:12 UTC
Reply
Permalink
Post by ProgAndy
This might be a use case for remakepkg to remove the replaces-entry in
the java10 packages.
https://bbs.archlinux.org/viewtopic.php?pid=1771005
The package in the sync database, which is a different database record
than the package in the local (installed) database, will still contain
the replaces entry and will therefore act as a replacement.

Meanwhile, replaces don't even do what a lot of people seem to think.
They're only ever read from sync databases, they're only ever accounted
for in an -Su operation, and the field is completely inert in either an
installed package or a *.pkg.tar.xz file.
--
Eli Schwartz
Bug Wrangler and Trusted User
Leandro Papi via arch-general
2018-09-19 08:41:54 UTC
Reply
Permalink
If I may pitch in with my 2 cents,

The fact that Java 10 replaces Java 9 is a call made by Oracle, as
described in their roadmap
(https://www.oracle.com/technetwork/java/javase/eol-135779.html)
[...]Java SE 9 was a non‑LTS release and immediately superseded by
Java SE 10 (also non‑LTS), Java SE 10 in turn is immediately
superseded by Java SE 11[...]

So it may not be an error having the successive packages removing the
previous ones, this behaviour will stop at Java 11, which will be a
LTS release, and Java 12 will not need to replace Java 11.

It's their release schedule, and I don't know if it would be better to
adhere to their guidelines or not, but I'm sure I'd like to leave this
choice to the user.

(Sorry for any unsightly formatting, it's my first reply to the
mailing list, and I'm using gmail, if there is something wrong please
take the time to guide me through my errors in a separate thread.)
--
L'ignoranza è un male curabile, è sufficiente la volontà.

Please don't print this e-mail if you don't need to!
Olli
2018-09-19 11:41:50 UTC
Reply
Permalink
Post by Leandro Papi via arch-general
The fact that Java 10 replaces Java 9 is a call made by Oracle, as
described in their roadmap
(https://www.oracle.com/technetwork/java/javase/eol-135779.html)
[...]Java SE 9 was a non‑LTS release and immediately superseded by
Java SE 10 (also non‑LTS), Java SE 10 in turn is immediately
superseded by Java SE 11[...]
What you describe here is not “Java” (which is a specification) and also
not OpenJDK but only Oracle JDK. It is a policy of the Oracle JDK
implementation but has nothing to do with Java itself. The OpenJDK
implementation of Java does not use anything like LTS, there will only
be the latest version which is a new one every six month (since
OpenJDK 9).

Since the Oracle JDK is not in the official Arch Linux repos but only
the OpenJDK there is no need to talk about LTS on this mailing list at
all.

Regards,
Olli
ProgAndy
2018-09-19 12:41:21 UTC
Reply
Permalink
Post by Olli
Post by Leandro Papi via arch-general
The fact that Java 10 replaces Java 9 is a call made by Oracle, as
described in their roadmap
(https://www.oracle.com/technetwork/java/javase/eol-135779.html)
[...]Java SE 9 was a non‑LTS release and immediately superseded by
Java SE 10 (also non‑LTS), Java SE 10 in turn is immediately
superseded by Java SE 11[...]
What you describe here is not “Java” (which is a specification) and also
not OpenJDK but only Oracle JDK. It is a policy of the Oracle JDK
implementation but has nothing to do with Java itself. The OpenJDK
implementation of Java does not use anything like LTS, there will only
be the latest version which is a new one every six month (since
OpenJDK 9).
Since the Oracle JDK is not in the official Arch Linux repos but only
the OpenJDK there is no need to talk about LTS on this mailing list at
all.
Regards,
Olli
There are LTS releases planned by AdoptOpenJDK, though. For now, Java 8
and Java 11 are declared as supported until at least 2022 [1]. These
versions may be of interest for Arch Linux.


Regards,
Andreas

[1]: https://adoptopenjdk.net/support.html
Carsten Mattner via arch-general
2018-09-19 15:00:25 UTC
Reply
Permalink
Post by ProgAndy
There are LTS releases planned by AdoptOpenJDK, though. For now, Java 8
and Java 11 are declared as supported until at least 2022 [1]. These
versions may be of interest for Arch Linux.
I'm not a Java developer anymore and probably unaware of new stuff,
and what you say makes sense. Though, isn't LTS packaging a niche
feature in Arch and wouldn't Arch follow the current latest JDK.
So JDK-LTS would be an extra package while a hypothetical meta
package like openjdk would track latest stable branch. Make sense?

I don't have a horse in this race, just thinking out loud.

I'm excited OpenJDK is turning into the mainstream source of JDKs,
when it was Oracle and IBM in the past. No more stupid JVM usage
tracking done by Oracle, for one. And no more licensing surprises.
Bardur Arantsson
2018-09-19 15:50:40 UTC
Reply
Permalink
Post by Carsten Mattner via arch-general
Post by ProgAndy
There are LTS releases planned by AdoptOpenJDK, though. For now, Java 8
and Java 11 are declared as supported until at least 2022 [1]. These
versions may be of interest for Arch Linux.
I'm not a Java developer anymore and probably unaware of new stuff,
and what you say makes sense. Though, isn't LTS packaging a niche
feature in Arch and wouldn't Arch follow the current latest JDK.
So JDK-LTS would be an extra package while a hypothetical meta
package like openjdk would track latest stable branch. Make sense?
In the specific case of Java 8 (LTS by AdoptOpenJDK) -> Java 11 (LTS by
AdoptOpenJDK), I suspect that there will be a hard requirement for most
Java developers to have support for both simultaneously on their
development machines because of the whole "module" thing; see below.

Of course that support would ideally come via the distribution and
there's a similar precedent for e.g. the node.js LTS releases, I imagine
for similar reasons to do with large incompatible changes. Anyway, if
such support is not offered, I'm pretty I certainly will be forced off
Arch Linux for practical reasons.

Btw, even though the Java language and the byte code are very stable
"formats", there Java 8 -> Java 9 module transition has been everything
but trivial and has required a lot of tooling/build changes which would
be really hard to do across all of the ecosystem at once and any similar
change in the future could hold up a a Java N -> Java N+1 migration for
a pretty long time since everybody moves at their own pace.

(One *hopes* that the trend will become that only the LTS-labeled
versions will be used for actually releasing stuff to the world, but
that the intermediate versions will be more seen as experimental. That
would mean that Arch would only have to care about LTS releases.)

Regards,
Eli Schwartz via arch-general
2018-09-20 07:13:29 UTC
Reply
Permalink
Post by Bardur Arantsson
In the specific case of Java 8 (LTS by AdoptOpenJDK) -> Java 11 (LTS by
AdoptOpenJDK), I suspect that there will be a hard requirement for most
Java developers to have support for both simultaneously on their
development machines because of the whole "module" thing; see below.
Of course that support would ideally come via the distribution and
there's a similar precedent for e.g. the node.js LTS releases, I imagine
for similar reasons to do with large incompatible changes. Anyway, if
such support is not offered, I'm pretty I certainly will be forced off
Arch Linux for practical reasons.
We provide nodejs lts releases, because a different Trusted User (not
the packager for nodejs itself) was interested in packaging it.
Post by Bardur Arantsson
Btw, even though the Java language and the byte code are very stable
"formats", there Java 8 -> Java 9 module transition has been everything
but trivial and has required a lot of tooling/build changes which would
be really hard to do across all of the ecosystem at once and any similar
change in the future could hold up a a Java N -> Java N+1 migration for
a pretty long time since everybody moves at their own pace.
(One *hopes* that the trend will become that only the LTS-labeled
versions will be used for actually releasing stuff to the world, but
that the intermediate versions will be more seen as experimental. That
would mean that Arch would only have to care about LTS releases.)
Gosh, I'd hope the trend was instead to have modern, up-to-date releases
that actually work properly.

But I'm sure the habits of the people developing java runtimes, will
force us to package LTS releases.

(Anyway I'm delighted to see the number of java versions decrease by at
least one.)
--
Eli Schwartz
Bug Wrangler and Trusted User
Bardur Arantsson
2018-09-20 14:50:05 UTC
Reply
Permalink
Post by Eli Schwartz via arch-general
Post by Bardur Arantsson
(One *hopes* that the trend will become that only the LTS-labeled
versions will be used for actually releasing stuff to the world, but
that the intermediate versions will be more seen as experimental. That
would mean that Arch would only have to care about LTS releases.)
Gosh, I'd hope the trend was instead to have modern, up-to-date releases
that actually work properly.
There's no need for snark. Java/JDK upstream take compatibility and
quality *extremely* seriously. Java releases are usually incredibly
backward-compatible, but

a) generally the JVM world is (understandably IMO) very careful in
moving from one version to next because JVM applications are usually
*huge* with many many corner cases. The JVM itself + the standard class
library is also quite big and it's basically impossible to do any change
without *something* *somewhere* relying on the existing (possibly buggy)
behavior. Most responsible developers at least try out version N+1,
report any bugs upstream and wait for those to be fixed and try out
version N+1 when the first 'wave' of bugs is fixed. While doing that,
having access to both version N and N+1 is kind of critical.

b) sometimes a new feature simply changes how something fundamentally
works and the feature is (by design) incompatible with the previous
state of things. This is the case for the 'modules' feature, for
example: It simply not possible to both have the module classpath
isolation and not have it at the same time. (It's actually possible to
disable this globally, but that's kind of a moot point.)

Regards,

Doug Newgard via arch-general
2018-09-17 16:27:58 UTC
Reply
Permalink
On Mon, 17 Sep 2018 18:20:49 +0200
Post by Guillaume ALAUX via arch-general
On Mon, Sep 17, 2018 at 5:48 PM Carsten Mattner via arch-general
Post by Carsten Mattner via arch-general
Post by Eli Schwartz via arch-general
So essentially what you really want is a way for pacman to remember your
choice. That would require pacman modify its configuration which is
something that goes against the current architecture... What would happen
instead is pacman.conf could be used to configure this.
I'm not sure if IgnorePkg or HoldPkg would have an effect here...
The way I read it, what's being suggested is something like Debian's
update-alternatives. https://wiki.debian.org/DebianAlternatives
Or a JVM version manager ala pyenv etc. Not sure.
Just to give some backing: here is the official explanation of what
"[…] non‑LTS releases are considered a cumulative set of
implementation enhancements of the most recent LTS release. Once a new
feature release is made available, any previous non‑LTS release will
be considered superseded. For example, Java SE 9 was a non‑LTS release
and immediately superseded by Java SE 10 (also non‑LTS), Java SE 10 in
turn is immediately superseded by Java SE 11." [0]
So keeping OpenJDK 9 in our repo while OpenJDK 10 is out would be the
same as keeping say OpenJDK 8.u181 while OpenJDK 8.u182 is out! Even
though I can understand the (developer) use case, this is clearly out
of Arch Linux' scope.
[0] http://www.oracle.com/technetwork/java/javase/eol-135779.html
Guillaume
Going forward with the new release policies, would it be better to just have an
openjdk/openjre package that's always the latest version, then versioned
packages for the lts releases, such as they are?
Levente Polyak via arch-general
2018-09-17 17:07:01 UTC
Reply
Permalink
Post by Doug Newgard via arch-general
Going forward with the new release policies, would it be better to just have an
openjdk/openjre package that's always the latest version, then versioned
packages for the lts releases, such as they are?
This is exactly what will happen when java-11 is released, a generic
named java package will replace java-10.

Don't think there will be LTS releases anymore, but we will have
versioned variants whenever some breaking changes require a specific jre
for an application in our repositories.

cheers,
Levente
Peter Nabbefeld
2018-09-17 16:33:57 UTC
Reply
Permalink
Post by Carsten Mattner via arch-general
Post by Eli Schwartz via arch-general
So essentially what you really want is a way for pacman to remember your
choice. That would require pacman modify its configuration which is
something that goes against the current architecture... What would happen
instead is pacman.conf could be used to configure this.
I'm not sure if IgnorePkg or HoldPkg would have an effect here...
The way I read it, what's being suggested is something like Debian's
update-alternatives. https://wiki.debian.org/DebianAlternatives
Or a JVM version manager ala pyenv etc. Not sure.
Yes and No. These tools allow switching the active JVM. In my case that
would be overkill, I don't need that. I only need the installed software
to be reachable from NetBeans IDE. I'm usually fine running my software
on the latest JDK version - I only need other JDKs for compatibility
testing, and that's most comfortable using an IDE.

Kind regards

Peter
Guus Snijders via arch-general
2018-09-17 18:03:34 UTC
Reply
Permalink
Post by Peter Nabbefeld
[...]
Yes and No. These tools allow switching the active JVM. In my case that
would be overkill, I don't need that. I only need the installed software
to be reachable from NetBeans IDE. I'm usually fine running my software
on the latest JDK version - I only need other JDKs for compatibility
testing, and that's most comfortable using an IDE.
As an alternative : you could just extract (unpack) the pkg file to a
versioned directory in your $home and use those for testing.

That way, you can easily select any version for testing, without running
into dependancy issues for your own system.


Mvg, Guus Snijders
Carsten Mattner via arch-general
2018-09-17 22:23:52 UTC
Reply
Permalink
Post by Guus Snijders via arch-general
As an alternative : you could just extract (unpack) the pkg file to a
versioned directory in your $home and use those for testing.
Hope you don't mind me hijacking the thread to ask if you've ever
extracted an adoptopenjdk tarball and were able to use it for running
a Swing GUI. The jdk10-openjdk (not bin, didn't try aur) package in arch
works, but whatever x86_64 tarball I download from adopopenjdk won't
display Swing GUIs. It just throws exceptions about font loading.
Do you have relevant experience to share/hint?
ProgAndy
2018-09-17 22:41:04 UTC
Reply
Permalink
Post by Carsten Mattner via arch-general
Hope you don't mind me hijacking the thread to ask if you've ever
extracted an adoptopenjdk tarball and were able to use it for running
a Swing GUI. The jdk10-openjdk (not bin, didn't try aur) package in arch
works, but whatever x86_64 tarball I download from adopopenjdk won't
display Swing GUIs. It just throws exceptions about font loading.
Do you have relevant experience to share/hint?
There is a similar (the same?) error with MacOS builds:

https://github.com/AdoptOpenJDK/openjdk-build/issues/489
Carsten Mattner via arch-general
2018-09-18 08:25:06 UTC
Reply
Permalink
Post by ProgAndy
Post by Carsten Mattner via arch-general
Hope you don't mind me hijacking the thread to ask if you've ever
extracted an adoptopenjdk tarball and were able to use it for running
a Swing GUI. The jdk10-openjdk (not bin, didn't try aur) package in arch
works, but whatever x86_64 tarball I download from adopopenjdk won't
display Swing GUIs. It just throws exceptions about font loading.
Do you have relevant experience to share/hint?
https://github.com/AdoptOpenJDK/openjdk-build/issues/489
I get these:

java.lang.InternalError: java.lang.reflect.InvocationTargetException
at sun.font.FontManagerFactory$1.run(
***@10.0.2-adoptopenjdk/FontManagerFactory.java:86)
Jason Yamada-Hanff via arch-general
2018-09-17 22:34:53 UTC
Reply
Permalink
A non-Arch specific alternative would be to use sdkman: https://sdkman.io/
, which is a generic version/environment manager for JVM-related packages.
I've used it when I wanted to install some SDKs that wouldn't clobber the
system-installed ones.
Post by Peter Nabbefeld
Post by Carsten Mattner via arch-general
Post by Eli Schwartz via arch-general
So essentially what you really want is a way for pacman to remember your
choice. That would require pacman modify its configuration which is
something that goes against the current architecture... What would
happen
Post by Carsten Mattner via arch-general
Post by Eli Schwartz via arch-general
instead is pacman.conf could be used to configure this.
I'm not sure if IgnorePkg or HoldPkg would have an effect here...
The way I read it, what's being suggested is something like Debian's
update-alternatives. https://wiki.debian.org/DebianAlternatives
Or a JVM version manager ala pyenv etc. Not sure.
Yes and No. These tools allow switching the active JVM. In my case that
would be overkill, I don't need that. I only need the installed software
to be reachable from NetBeans IDE. I'm usually fine running my software
on the latest JDK version - I only need other JDKs for compatibility
testing, and that's most comfortable using an IDE.
Kind regards
Peter
Peter Nabbefeld
2018-09-17 16:31:14 UTC
Reply
Permalink
Post by Eli Schwartz via arch-general
Post by Peter Nabbefeld
Post by Eli Schwartz via arch-general
You will get prompted again and again on every pacman -Su "to see if
you're finally ready to do the replacement".
That's what I don't want - if I accidently don't type the "n" for some
reason, the JDK will be raplaced. While I could re-install it from the
repo's cache, this is a bit inconvinient. Just adding and moving to the
new one would be great.
So essentially what you really want is a way for pacman to remember your choice. That would require pacman modify its configuration which is something that goes against the current architecture... What would happen instead is pacman.conf could be used to configure this.
I'm not sure if IgnorePkg or HoldPkg would have an effect here...
Currently, I'm using IgnorePkg - this solves the main problem, but gives
me some alerts (as 5 packages are affected). And I don't know what will
happen, if JDK 11 is out: Will I have to block both (JDK 9 and JDK 10),
i.e. will the number of ignored packages (and the related alerts) have
to increase with every new JDK release? Then I will reach the point at
some time, where I do not see other important messages because of all
the alerts.

BTW, I do not want to change pacman's architecture, it shouldn't
remember anything. One solution could just be to define sth. like
"IgnoreSilent", i.e. an option like "IgnorePkg" without the alerts. But,
while the behaviour is what I want, the semantics are probably strange:
"IgnorePkg" currently adds the replacement package while not removing
the replaced one, while I'd expect it to do nothing in this case.
However, other replacements seem to work just fully or changing nothing
- is it probably possible to control this from the package?

Alternatively, a completely other option like the following could be
added like this "forever":
UpdateStrategyAdd = jdk*-openjdk jre*-openjdk jre*-openjdk-headless
openjdk*-doc openjdk*-src

Kind regards

Peter
Loading...