![]() ![]() "JRE") images, quoting oracle (dot) com: jlink Jlink's intent is to create runtime (i.e. That one or the other is a suitable runtime depends on the set of modules required by an application. Jlink is used to produce both the 'JDK' and 'JRE'. It’s only related because jlink passes the JRE burden off to the developers, but the JDK versus JRE argument is more about those bullets above. jpackage isn’t the answer either, but I find these to be separate discussions that are more about bundling versus using a preinstalled version. It’s a nightmare to get just right on all platforms. I see a lot of mentions of jlink but I’ve been working on a JLink-based installer for months (happy to provide a link to the PR!). I don’t have this answer, but Adoptium team does. How much effort is it for the Adoptium team to keep providing both for eternity?.The answer to this would depend on how the JRE is located for a particular app. Does using the JDK instead of the JRE provide compatibility issues?.Probably “Yes”, it’s less than 1/3 in size! Is the JRE so significantly smaller that it’s warranted to be offered as a download?.In my opinion, they’re not really directly related. “Where do I get my runtime already installed on the PC” decision. I’m afraid many developers won’t invest the effort and instead switch to a JDK. Of course we could switch to jlink, but I still find it a bit of a hassle to setup everything. But for that you need javac which was never in legacy JREs.Īlthough i don't think adopt should just stop releasing JREs for 11, maybe 17+ would be a good time for it if it isn't too late yet. For example you could argue that part of running Java 11+ is being able to run JEP 330 single-file source-sode programs. The contents of a JRE are not very well defined. jdeps + some greping and you basically have 90% of what you need (i wrote a blog post about this). If you are missing a module you will notice it right away and you can add it.Įven if you would like to strip the custom runtime down to a minimum (again for a dusty app which isn't using java modules), it usually isn't very difficult either to get an initial list of modules. ![]() One reason why its so easy is because you code against your custom runtime, and you test against it. A server app doesn't suddenly start using a desktop module. In my experience, maintaining a module list is not very difficult (even for non-modularized projects), because it rarely ever changes. I am sure adopt could post the list of modules somewhere which were used for the legacy JRE so that users could reproduce the same image if they want. Migration should be fairly straight forward since if image size doesn't matter, passing 'ALL-MODULE-PATH' to jlink will produce a ~105 MB large image with everything in it. Of course I don't know how much work it's to maintain the JRE's for Adoptium and if the number of downloads for the JRE are worth the effort. I'm afraid that if the JRE's are no longer available, then people will switch to a JDK or a JRE build from another vendor instead of jlink as it's easier and less maintenance.Īlso if I look at the number of downloads (see below) for some of the Chocolatey packages (Windows package manager) I maintain, then I see the JRE is still quite popular. But it's still a bigger effort then simply using a JRE. Of course it's all possible and we might be able to automate some parts. Then we would have to run the steps every time a new minor or major version of Java is released. ![]() Preferably one for each application to have them as small as possible. Instead of simply using the latest Docker image, we would have to create our own Docker image. If I look at for instance it's still some work to use, especially if the application doesn't use the module system. I've looked at jlink before, but it's less straightforward. It's also easy to maintain as we can simply change the Docker image tag once a new minor/major version of Java is released. We are using AdoptOpenJDK Java 11 Docker JRE images and hope to switch to Java 17 JRE images once/if available.įor us, they're a lot better than JDK's as they're a lot smaller. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |