![install4j problems install4j problems](https://i.stack.imgur.com/532eI.png)
When using a static bundle - would that install (on Windows) again inĬ:\program files\common files\i4j_jres\ or But before definitely voting I have some additional questions: I'm not sure if there's any limits on storage/bandwidth by GitHub/Travis that will cut us off (similar to what we encountered when using Git LFS).Įveryone please feel free to weigh in on what we should do with the bundled JREs going I tend to option 2, as option 3 creates a lot of useless data with every commit leading to a new pre-release. The obvious drawback here is that the size of each GitHub release will increase by almost 100 MiB (about 2x what we use today), which will also require additional upload bandwidth from Travis. This gives users the option to choose to download an installer with or without a bundled JRE.
![install4j problems install4j problems](https://i.stack.imgur.com/trxMo.png)
This will require users to always install Java themselves.
Install4j problems update#
( NOTE: Per ej-technologies support (but I haven't confirmed), if we include a newer static bundle, it will update any existing bundled JRE, even if it was originally installed via a dynamic bundle.) Use a static bundle, This will increase Windows and Mac installer sizes by 30-40 MiB (the Unix installer does not support a bundled JRE).Therefore, based on the all the previous comments, I see three possible alternatives (please add any other I may not have thought of): So, it sounds like we should drop the dynamic bundle given that we have no control to update older JREs that may have been previously installed by TripleA. It was confirmed that, when using a dynamic bundle, any existing bundled JRE on the system will not be updated. I received a response to my install4j support ticket. But I think that's offset by providing JRE-free installers that will be the same size as today's installers.
![install4j problems install4j problems](https://forum.step.esa.int/uploads/default/optimized/3X/8/1/8104ae65f119a3e3c2566e4dcc8f84273d11b956_2_690x495.png)
The biggest drawback is the download size will increase by several tens of MiB. The benefit of the static bundle is it will be properly upgraded. But, as an optional extension to that idea, we could also provide parallel installers that include a statically-bundled JRE for users who truly don't want to be bothered with installing a JRE.
Install4j problems upgrade#
If it turns out there's no way to upgrade a dynamic bundled JRE, then I think what myself and suggested above should be considered: namely, removing the bundled JRE altogether. I'm still waiting on a response to my support ticket. The installer itself requires a JRE to run, so I believe it's some native bootstrap code that is responsible for installing the bundled JRE before the Java installer is actually launched. In fact, it's so low-level, it occurs while bootstrapping the installer. All the details of installing it appear to be buried inside the install4j runtime. I don't believe we have any control over the bundled JRE installation process beyond enabling it and specifying what version we want installed.