Bundling multiple JREs/JDKs in a single flatpak

[C-512L]

The SDK extensions' scripts in all versions (8, 11 and latest) point in the building process to the same place (/app/jre and /app/jdk). This is a problem for any flatpak package that needs to bundle two different versions of the JRE/JDK (e.g. minecraft launchers due to latest game version requiring Java 16+). There are some ways to workaround it but are a little hacky. I think there might be a solution from the SDK side rather than future packages having to circumvent this limitation.

[mbooth101]

IMO the Right™ solution is to contribute to the application to make it work on modern Java so you don't need to ship two JREs. It's honestly pretty easy to port to new versions of Java -- I don't want to make it easier to do the wrong thing.

[KhalilSantana]

I mostly agree with your points @mbooth101, however, I don't think flatpaks have enough marketshare (users vs traditional pkg formats) to seriously 'dictate' the 'correct way', and as such, not supporting this workflow might cause more issues than it solves.

In other words, I'd say not supporting this would create more attrition with developers than necessary, and workarounds will not always be possible (consider the strong encapsulation '--illegal-access' switch being removed in the future, for example), so maybe in order for flatpak to succeed this perceived 'step back' might be necessary.

[mbooth101]

I mostly agree with your points @mbooth101, however, I don't think flatpaks have enough marketshare (users vs traditional pkg formats) to seriously 'dictate' the 'correct way', and as such, not supporting this workflow might cause more issues than it solves.

I'm not suggesting we dictate anything, I just suggesting we be good citizens and participate in the community by contributing code upstream to fix the issue -- this is how open source works.

In other words, I'd say not supporting this would create more attrition with developers than necessary, and workarounds will not always be possible (consider the strong encapsulation '--illegal-access' switch being removed in the future, for example), so maybe in order for flatpak to succeed this perceived 'step back' might be necessary.

It is not "not supported" you can do it quite easily with the addition of one mv command in the "build-commands" section of your flatpak build manifest:

/usr/lib/sdk/openjdk11/install.sh
mv /app/jre /app/jre-11
/usr/lib/sdk/openjdk/install.sh

I don't see this as "hacky" at all. In fact having a special feature in the OpenJDK extension is worse because then it has to be there forever or I risk breaking applications that start using it.

Maybe I'm misunderstanding why this is a big problem for applications.

[C-512L]

I mostly agree with your points @mbooth101, however, I don't think flatpaks have enough marketshare (users vs traditional pkg formats) to seriously 'dictate' the 'correct way', and as such, not supporting this workflow might cause more issues than it solves.

I'm not suggesting we dictate anything, I just suggesting we be good citizens and participate in the community by contributing code upstream to fix the issue -- this is how open source works.

In other words, I'd say not supporting this would create more attrition with developers than necessary, and workarounds will not always be possible (consider the strong encapsulation '--illegal-access' switch being removed in the future, for example), so maybe in order for flatpak to succeed this perceived 'step back' might be necessary.

It is not "not supported" you can do it quite easily with the addition of one mv command in the "build-commands" section of your flatpak build manifest:

/usr/lib/sdk/openjdk11/install.sh
mv /app/jre /app/jre-11
/usr/lib/sdk/openjdk/install.sh

I don't see this as "hacky" at all. In fact having a special feature in the OpenJDK extension is worse because then it has to be there forever or I risk breaking applications that start using it.

Maybe I'm misunderstanding why this is a big problem for applications.

This is a good solution, at least for me and it just works (its what i did basically in my case).
It might be a good idea to document that for future people asking

[mbooth101]

This is a good solution, at least for me and it just works (its what i did basically in my case).
It might be a good idea to document that for future people asking

Yes, it's been long on my todo list to write more blog articles about using the OpenJDK extension :-) I'll leave this bug open as a reminder to document this use-case.

[mbooth101]

BTW @AndroidC512L @KhalilSantana if you like you can CC me on upstream bugs where this problem exists, I have a lot of experience of getting old Java projects working on modern Java -- maybe I can offer advice.

[KhalilSantana]

I'm not suggesting we dictate anything, I just suggesting we be good citizens and participate in the community by contributing code upstream to fix the issue -- this is how open source works.

I didn't mean dictate in a coersive way (hence the quotes), I meant in a 'support presure' kind of way, like deprecating a function or API.

It is not "not supported" you can do it quite easily with the addition of one mv command in the "build-commands" section of your flatpak build manifest:

I was unaware that the workaround was this simple like this, so maybe it's not a problem at all then.

[d-513]

IMO the Right™ solution is to contribute to the application to make it work on modern Java so you don't need to ship two JREs. It's honestly pretty easy to port to new versions of Java -- I don't want to make it easier to do the wrong thing.

Impossible when you work with launchers like Minecraft launchers which need to be able to use older gam versions for modding.
But yeah, mv work well enough, i'm not sure why we can't just add-extension the jdk though?