[arch-general] How to have multiple JDKs parallel?

[Peter Nabbefeld]

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 at 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