Re: [arch-general] How to have multiple JDKs parallel?
On 17.09.18 09:31, Peter Nabbefeld wrote:
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.
Op ma 17 sep. 2018 12:04 schreef Olli olli@suruatoel.xyz:
On 17.09.18 09:31, Peter Nabbefeld wrote:
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
On Mon, Sep 17, 2018 at 12:34:54PM +0200, Guus Snijders via arch-general wrote:
Op ma 17 sep. 2018 12:04 schreef Olli olli@suruatoel.xyz:
On 17.09.18 09:31, Peter Nabbefeld wrote:
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.
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
Am 17.09.18 um 12:42 schrieb Luke English:
On Mon, Sep 17, 2018 at 12:34:54PM +0200, Guus Snijders via arch-general wrote:
Op ma 17 sep. 2018 12:04 schreef Olli olli@suruatoel.xyz:
On 17.09.18 09:31, Peter Nabbefeld wrote:
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.
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
On 9/17/18 7:50 AM, Peter Nabbefeld wrote:
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).
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".
Am 17.09.18 um 15:58 schrieb Eli Schwartz via arch-general:
On 9/17/18 7:50 AM, Peter Nabbefeld wrote:
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).
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
On September 17, 2018 10:06:04 AM EDT, Peter Nabbefeld peter.nabbefeld@gmx.de wrote:
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...
On 9/17/18, Eli Schwartz via arch-general arch-general@archlinux.org wrote:
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.
On Mon, Sep 17, 2018 at 5:48 PM Carsten Mattner via arch-general arch-general@archlinux.org wrote:
On 9/17/18, Eli Schwartz via arch-general arch-general@archlinux.org wrote:
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
Am 17.09.18 um 18:20 schrieb Guillaume ALAUX via arch-general:
On Mon, Sep 17, 2018 at 5:48 PM Carsten Mattner via arch-general arch-general@archlinux.org wrote:
On 9/17/18, Eli Schwartz via arch-general arch-general@archlinux.org wrote:
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
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
On Mon, Sep 17, 2018 at 18:26:04 +0200, ProgAndy wrote:
This might be a use case for remakepkg to remove the replaces-entry in the java10 packages.
*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
On 9/17/18 12:26 PM, ProgAndy wrote:
This might be a use case for remakepkg to remove the replaces-entry in the java10 packages.
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.
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!
On 19.09.18 10:41, Leandro Papi via arch-general wrote:
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
Am 19.09.18 um 13:41 schrieb Olli:
On 19.09.18 10:41, Leandro Papi via arch-general wrote:
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
On 9/19/18, ProgAndy admin@progandy.de wrote:
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.
On 19/09/2018 17.00, Carsten Mattner via arch-general wrote:
On 9/19/18, ProgAndy admin@progandy.de wrote:
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,
On 9/19/18 11:50 AM, Bardur Arantsson wrote:
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.
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.)
On 20/09/2018 09.13, Eli Schwartz via arch-general wrote:
On 9/19/18 11:50 AM, Bardur Arantsson wrote:
(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,
On Mon, 17 Sep 2018 18:20:49 +0200 Guillaume ALAUX via arch-general arch-general@archlinux.org wrote:
On Mon, Sep 17, 2018 at 5:48 PM Carsten Mattner via arch-general arch-general@archlinux.org wrote:
On 9/17/18, Eli Schwartz via arch-general arch-general@archlinux.org wrote:
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
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?
On 9/17/18 6:27 PM, Doug Newgard via arch-general wrote:
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
Am 17.09.18 um 17:48 schrieb Carsten Mattner via arch-general:
On 9/17/18, Eli Schwartz via arch-general arch-general@archlinux.org wrote:
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
On Mon, Sep 17, 2018 at 6:34 PM Peter Nabbefeld peter.nabbefeld@gmx.de wrote:
Am 17.09.18 um 17:48 schrieb Carsten Mattner via arch-general:
On 9/17/18, Eli Schwartz via arch-general arch-general@archlinux.org wrote:
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
Your best bet would be to download the PKGBUILD file and rename the package name. You'll probably need to make a few other changes as well as often the package name is used to download the package etc.
Update the provides,conflicts as needed
Now you'll have a package that can coexists with all the others and pacman won't even ask to upgrade it.
Op ma 17 sep. 2018 18:34 schreef Peter Nabbefeld peter.nabbefeld@gmx.de:
[...]
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
On 9/17/18, Guus Snijders via arch-general arch-general@archlinux.org wrote:
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?
Am 18.09.18 um 00:23 schrieb 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:
On 9/17/18, ProgAndy admin@progandy.de wrote:
Am 18.09.18 um 00:23 schrieb 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:
I get these:
java.lang.InternalError: java.lang.reflect.InvocationTargetException at sun.font.FontManagerFactory$1.run( java.desktop@10.0.2-adoptopenjdk/FontManagerFactory.java:86)
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.
On Mon, Sep 17, 2018 at 9:34 AM Peter Nabbefeld peter.nabbefeld@gmx.de wrote:
Am 17.09.18 um 17:48 schrieb Carsten Mattner via arch-general:
On 9/17/18, Eli Schwartz via arch-general arch-general@archlinux.org
wrote:
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
Am 17.09.18 um 16:21 schrieb Eli Schwartz via arch-general:
On September 17, 2018 10:06:04 AM EDT, Peter Nabbefeld peter.nabbefeld@gmx.de wrote:
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
participants (15)
-
Andy Pieters
-
Bardur Arantsson
-
Carsten Mattner
-
Doug Newgard
-
Eli Schwartz
-
Guillaume ALAUX
-
Guus Snijders
-
Jason Yamada-Hanff
-
Leandro Papi
-
Levente Polyak
-
Luke English
-
Olli
-
Peter Nabbefeld
-
ProgAndy
-
Tinu Weber