Dependencies for Java related items moving to open JRE/JDK?

[ferventcoder]

This is more of an awareness question. Have we looked into this as a way of allowing folks not to get hit by any potential licensing issues?

[AdmiringWorm]

This have not been looked into AFAIK.

However, I did a quick search of the repository now (for all mentions of java, jre or jdk), and didn't find any package that actually have java as its dependency (other than a deprecated java runtime package).

So at least in the repository itself, there is nothing that needs to be looked into.

[majkinetor]

Yet, its only matter of time when we will have java dependency here.

[ExE-Boss]

See also: JohanJanssen/ChocolateyPackages#39

That would move AdoptOpenJDK packages here.

[majkinetor]

FYI

I switched few of the latest packages to AdoptOpenJDKJRE package ( by @johanjanssen ) instead of the javaruntime that was previously used as later requires a license for commercial use since 2019.

So far: plantuml, yed and tv-browser all seem to work fine but lets see how it will behave in the wild with this setup.

With tv-browser I intiially used adoptopenjdk11jre which doesn't seem to set registry stuff (even with adequate -ia parameter) so I got it working with it by symlinking jre to its subdir java or by adding registry stuff manually (see #1350). Today I found that jre version 13.3 doesn't require this.

[johanjanssen]

@majkinetor the fact 11 doesn't set registry stuff and 13 does is probably because of the fact that 11 still uses the zip to install and 13 the msi.

If you prefer to use Java 11 as it's an LTS version (13 is not), I can create a new version of the package based on the msi.

[johanjanssen]

I noticed that Java 11 will get an update release in two weeks. I will release a Chocolatey package for that release based on the MSI.

[majkinetor]

Thx @johanjanssen.

Again, consider migrating it here, especially since on your issue list are some stuff that need 0 attention here.

[johanjanssen]

I'm not completely convinced that it will improve much. But I'm ok if you guys want it.

So what needs to be done?

I know embedding the package is one thing. But also the packages should follow the strict guidelines, where can I find them?

[majkinetor]

https://github.com/chocolatey-community/chocolatey-coreteampackages/blob/master/CONTRIBUTING.md

Just PR here and we will help.

I know embedding the package is one thing

Embedding is critical in this case - you need to have infinitelly available executable for your project. Even if chocolatey gallery is deprecated one day packages are still available either in your local cache, your intranet cache (artifactory, nexus...), Github releases etc... So it can't get lost either.

However, not sure if embedding is possible due to size limitations.

[johanjanssen]

However, not sure if embedding is possible due to size limitations.

It's growing hard, now on 178 MB. The last two releases added 9MB. So I wouldn't be too surprised if it goes above 200 MB in the (near) future. You still want to embed it and move it to the core packages?

[majkinetor]

Embedding is probably best left when this limit of 200MB is removed.

As of migration, i think it would be beneficial. If we are all going to use adoptopenjdk as dependency to java projects, its best that most known repository holds it as more people can be involved in enhacing the package, such as adding more parameters, fixing corner bugs or just making it better related to some other package which may require some extra setting and so on.

Ofcourse, its far from mandatory. Feel free to decide any way.

[majkinetor]

I got one report that package finished using the wrong JRE: https://github.com/majkinetor/au-packages/issues/129

This could ofcourse happen in other similar scenarios (python2 vs 3 as an example etc.) so not sure if this should be considered a bug or not. I was taking java executable from the PATH which is a problem in such context. Package should explicitelly try to use adoptopenjdkjre and find it via some method. I am not sure what is the best method to do is - hardcoding a path in script or iterating some registry keys until adopt word is found in case they are handled both in JavaSoft registry section or something else...

[johanjanssen]

I don't know if I understand your remark correctly. You mean that another Java build was used (for instance the Oracle JDK) instead of the AdoptOpenJDK one that you expected?

I wouldn't hardcode dependencies to a specific build of Java. People now have the choice to use OpenJDK, AdoptOpenJDK, Amazon Corretto, Liberica JDK or others. Hardcoding dependencies to one of them basically eliminates the choice for people to choose their own build, or at least makes it a lot harder.

[ExE-Boss]

That will probably depend on https://github.com/chocolatey-archive/chocolatey/issues/7/https://github.com/chocolatey/choco/issues/858.

[majkinetor]

I agree with you @johanjanssen, however, virtual packages may be implemented in next decade or never (first ticket is almost decade old). It looks wrong to depend on specific package and use something else once installed.

[johanjanssen]

Yes, but you could also opt to not declare the Java dependency explicitly. Just don't add it as a dependency, then it's up to the users to pick the dependency they want. It's what for instance the Maven package is doing as well.

[majkinetor]

Majority of users dont care, they just want it to work. That is what package manager promisses too, to not care about complexity of installation. Maven is not great example since it is dev tool. To use TV browser you dont even have to know about java.

[ExE-Boss]

I could probably get a pseudo‑virtual package to work by using the chocolateyInstall.ps1 script and an extension to maintain a registry of provided virtual packages.

[majkinetor]

It can be done, but keep in mind that some solutions will be considered hostile, those that mess up with chocolatey internals such as package files directly etc.

I think it should be done (even in hostile manner) given that choco.exe has almost 0 improvements over years, low number of new features despite the high need, and no new devs (if you don't count trivials) despite general interest.

Anyway, If you start something it would be good to be here or part of coreteam extension.

[majkinetor]

I will close this as it seems there is nothing more to discuss. I also think this is the best option since Microsoft is one of the sponsors of the project and it looks like they are ramping up their support for java.