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 <o...@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

Reply via email to