New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too many problems from old Java versions #4358

Open
simon33-2 opened this Issue Nov 15, 2018 · 31 comments

Comments

Projects
5 participants
@simon33-2
Copy link
Contributor

simon33-2 commented Nov 15, 2018

Me and others have been spending way too much time sorting out issues caused by mostly Windows platforms with old versions of Java causing incompatibilities.

Is there some way that the installer could at least validate that the Java is up to date? Or some other option? In 1.8 it bundled the Java which was more stable than present but I guess you don't want to go back to that.

@ssoloff

This comment has been minimized.

Copy link
Member

ssoloff commented Nov 15, 2018

I looked through the install4j documentation to see if there was a way to force it to upgrade a previously-installed bundled JRE with a later one referenced by the current installer. Unfortunately, I wasn't able to find any way to do this.

I'm assuming the main issue affecting users is the 1.8.0_66 JRE lacking the required CA certs that have been causing HTTPS errors with MARTI. I suspect that issue could arise again in the future, as CA certs get renewed.

Given that we can't find a way to automatically upgrade bundled JREs, I wonder if we should just drop them and have users manually install Java, when required? If they can download and install TripleA, it's likely they can do the same for a compatible JRE.

@ssoloff

This comment has been minimized.

Copy link
Member

ssoloff commented Nov 15, 2018

Actually, while the install4j documentation came up empty, this SO question seems to indicate it may be possible to upgrade a bundled JRE. I will investigate.

@RoiEXLab

This comment has been minimized.

Copy link
Member

RoiEXLab commented Nov 15, 2018

If everything fails, we could also investigate bundling custom java 9+ runtime images with every installer.
Of course this gets more feasible the more the code is clearly separated from each other because this would reduce the filesize by a lot.
But it would definitely be interesting to know how big a custom JRE would be in the current state of the code.

@ssoloff

This comment has been minimized.

Copy link
Member

ssoloff commented Nov 16, 2018

I found the options mentioned in the linked SO question, and they both appear to be enabled in our installer:

install4j-update-bundled-jre

I'll have to try installing 3635 first without an existing JRE, and then look at the installation log from 12226 to see what it is (or is not) doing.

Also, re-reading the install4j docs, I found a reference that mentions the bundled JRE will be updated when it is a static bundle, that is embedded within the installer media file. There is no mention of such an update for a dynamic bundle, that is download-on-demand, which is what we currently use.

@panther2

This comment has been minimized.

Copy link
Member

panther2 commented Nov 16, 2018

The problem on Windows is that the "bundled" JRE is installed in either
c:\program files\common files\i4j_jres\ or
C:\Users\<username>\AppData\Local\i4j_jres\

Some Windows users don't know that these paths and folders do even exist. So the i4j_jres installation is almost "invisible" to them. It does not appear in Windows Control Panel - where they are used to find all installed software - either.

The process of identifiying the Java version that actually is used by TripleA is hard for many, too.

For years I have recommended users to install Java (JRE) from java.com instead of relying on the "bundled" install. To me this appears to be a transparent solution. Every Windows user can tell which Java is installed then, just by visiting the Control Panel.

Also Java checks for updates automatically, then (by default, setting is configurable).
This prevents from problems.

@ssoloff

This comment has been minimized.

Copy link
Member

ssoloff commented Nov 16, 2018

I'll have to try installing 3635 first without an existing JRE, and then look at the installation log from 12226 to see what it is (or is not) doing.

I ran the above test. Looking at the installer log during the upgrade, I confirmed the properties discussed at the above SO question are set correctly. Unfortunately, there is no indication install4j even attempts to update the bundled JRE.

I created a support ticket with ej-technologies to determine if bundled JRE updates apply to dynamic bundles (what we're using) or just static bundles.

@simon33-2

This comment has been minimized.

Copy link
Contributor Author

simon33-2 commented Nov 16, 2018

What about a way of verifying that the version of Java is Java 8 of at least patch X? Would that work?

@ssoloff

This comment has been minimized.

Copy link
Member

ssoloff commented Nov 16, 2018

@simon33-2 I don't believe we have any control over the bundled JRE installation process beyond enabling it and specifying what version we want installed. All the details of installing it appear to be buried inside the install4j runtime. In fact, it's so low-level, it occurs while bootstrapping the installer. 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.

I'm still waiting on a response to my support ticket. If it turns out there's no way to upgrade a dynamic bundled JRE, then I think what myself and @panther2 suggested above should be considered: namely, removing the bundled JRE altogether. 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. The benefit of the static bundle is it will be properly upgraded. The biggest drawback is the download size will increase by several tens of MiB. But I think that's offset by providing JRE-free installers that will be the same size as today's installers.

@simon33-2

This comment has been minimized.

Copy link
Contributor Author

simon33-2 commented Nov 17, 2018

So both installers would be provided? What would the users see on triplea-game.org/download? The bundled one or the Java requiring one? I'm inclined to think the bundled installer should be the easiest one to get.

@ssoloff

This comment has been minimized.

Copy link
Member

ssoloff commented Nov 17, 2018

@simon33-2 Sorry for not thinking that through a bit more. My proposal was that users would see both installers on the GitHub releases page. For example:

TripleA_1.10.0.0.13067_macos.dmg
TripleA_1.10.0.0.13067_macos_nojre.dmg
TripleA_1.10.0.0.13067_unix_nojre.sh
TripleA_1.10.0.0.13067_windows-32bit.exe
TripleA_1.10.0.0.13067_windows-32bit_nojre.exe
TripleA_1.10.0.0.13067_windows-64bit.exe
TripleA_1.10.0.0.13067_windows-64bit_nojre.exe

Then on triplea-game.org, I guess we'd just pick one to point to. I tend to agree with you that the installer with the bundled JRE would be the most appropriate. In the secondary text that pops up once you click a download link, we could provide a short blurb and a link to the other installer (e.g. "Already have Java installed? Click here for a smaller download."). That way, an observant user will have access to both installers per platform (sans Unix) from the download page. And veteran users will eventually learn how to directly download the nojre version if they wish to maintain their own version of Java.

@simon33-2

This comment has been minimized.

Copy link
Contributor Author

simon33-2 commented Nov 17, 2018

I don't think there was any question that users would see both installers on the github releases page, but that is not where most of them go to download the game.

Sounds like we're in agreement that the aggregated installer should be the main one. Perhaps we should have some small text only links to grab the no-jre installers?

@simon33-2

This comment has been minimized.

Copy link
Contributor Author

simon33-2 commented Nov 17, 2018

Of course, the bundled JREs wouldn't cause any problem if they weren't actually being used. Is it not possible to just ignore such pests?

@ssoloff

This comment has been minimized.

Copy link
Member

ssoloff commented Nov 17, 2018

Perhaps we should have some small text only links to grab the no-jre installers?

Yeah, whatever the visual design gurus think looks best. 😄

Is it not possible to just ignore such pests?

There is a way to configure install4j to use a custom JRE search sequence, but I haven't really looked into it. It might be necessary to mess with that, even for new installers that use the above proposed solutions, to avoid picking up any previously-installed bundled JRE. (Looking at a few more install4j options, I think our original mistake was marking the bundled JRE as "shared," which prevents it from being removed when TripleA is uninstalled.)

@simon33-2

This comment has been minimized.

Copy link
Contributor Author

simon33-2 commented Nov 17, 2018

So if we used the custom search sequence we could kill the use of Java 8-66 once and for all and in a new release? Or is that not realistic?

@ssoloff

This comment has been minimized.

Copy link
Member

ssoloff commented Nov 17, 2018

I don't know exactly what's possible with that feature. It will require some investigation.

@panther2

This comment has been minimized.

Copy link
Member

panther2 commented Nov 17, 2018

This issue will soon rise again:

When users on axisandallies.org are now forced to update their TripleA to at least https://github.com/triplea-game/triplea/releases/tag/1.9.0.0.13066 ( #4361 ) I am sure that many will run into the outdated i4j_jres issue, as many are on quite old TripleA versions.

This should no way block the release of the forum-compatible version, of course.

@ssoloff

This comment has been minimized.

Copy link
Member

ssoloff commented Nov 20, 2018

I received a response to my install4j support ticket. It was confirmed that, when using a dynamic bundle, any existing bundled JRE on the system will not be updated.

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. Therefore, based on the all the previous comments, I see three possible alternatives (please add any other I may not have thought of):

  1. 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). (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.)
  2. Do not bundle a JRE at all. This will require users to always install Java themselves.
  3. Provide two installers per platform: one with a static bundle and one without a bundled JRE. This gives users the option to choose to download an installer with or without a bundled JRE. 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. 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).

Everyone please feel free to weigh in on what we should do with the bundled JREs going forward.

@DanVanAtta @RoiEXLab @ron-murhammer @simon33-2

@simon33-2

This comment has been minimized.

Copy link
Contributor Author

simon33-2 commented Nov 20, 2018

I'm voting option 3. Not sure if those issues you raise will be a problem though.

@panther2

@panther2

This comment has been minimized.

Copy link
Member

panther2 commented Nov 20, 2018

@ssoloff I tend to option 2, as option 3 creates a lot of useless data with every commit leading to a new pre-release. But before definitely voting I have some additional questions:

When using a static bundle - would that install (on Windows) again in
c:\program files\common files\i4j_jres\ or
C:\Users\<username>\AppData\Local\i4j_jres\ ?
Would that one leave a registry entry to appear in Windows Control Panel as Software installation?
(Different from a dynamic one that does not do so.)

Can a bundled Java version instead be installed in
c:\...\TripleA\i4jres\ ?
(I remember "Minecraft" installations that bundled a JRE installing in the Minecraft directory)

That would be extremely helpful when giving support to users.

Does a bundled version (actually I never installed one) install side by side next to a present Java (from java.com) installation? Or does it check whether there is already a system-wide Java present, and if yes, does not install at all?

Being aware that the difference between a pre-release and a release is just a tag - would it be somehow possible to create bundled versions according to your option 3 only for releases? Either automated or manually? Given the usually low frequency of releases - that could prevent from creating additional masses of data trash with every pre-release.

@simon33-2

@ssoloff

This comment has been minimized.

Copy link
Member

ssoloff commented Nov 20, 2018

@panther2 Some good questions there, and some that I hadn't considered before.

When using a static bundle - would that install (on Windows) again in
c:\program files\common files\i4j_jres\ or
C:\Users\<username>\AppData\Local\i4j_jres\ ?

AFAIK, changing from a dynamic bundle to a static bundle does not change the location where the bundled JRE is eventually installed. (BTW, on my Windows 8.1 box, when installing TripleA as a non-admin, the bundled JRE ends up in C:\Users\<username>\.i4j_jres, not C:\Users\<username>\AppData\Local\i4j_jres.)

Would that one leave a registry entry to appear in Windows Control Panel as Software installation?
(Different from a dynamic one that does not do so.)

I don't believe that behavior would change. We're simply changing the delivery mechanism. Everything else about the bundled JRE should remain the same. Therefore, the bundled JRE would continue to not appear in Control Panel. (All of those claims are pending actually testing it, obviously. 😄)

Can a bundled Java version instead be installed in
c:\...\TripleA\i4jres\ ?

Yes, and I should have mentioned this above... There's another flag in the installer associated with a bundled JRE that indicates whether the JRE should be "shared" or not. TripleA currently sets this flag to true. If we turned it off, the bundled JRE would be installed in a subdirectory of the TripleA installation directory (not exactly sure where). Also, the bundled JRE would then be uninstalled when TripleA is uninstalled.

The only drawback I can see by not making the bundled JRE shared is for a user who wishes to install multiple versions of TripleA side-by-side. There would then, theoretically, be one JRE per installation. However, I'm inclined to think this is a rare situation outside of devs and map makers. Also, it can be alleviated by installing a standalone JRE (see below).

Does a bundled version (actually I never installed one) install side by side next to a present Java (from java.com) installation? Or does it check whether there is already a system-wide Java present, and if yes, does not install at all?

If a version of Java is already installed on the system (e.g. via the Oracle JRE installer), the TripleA installer will not install the bundled JRE (that's how it works with a shared/dynamic bundle; I assume it would be the same behavior for a non-shared/static bundle).

Being aware that the difference between a pre-release and a release is just a tag - would it be somehow possible to create bundled versions according to your option 3 only for releases?

That's a good idea. Unfortunately, I don't think it would work given our current release process. You are correct in that we simply "flip a switch" to turn a pre-release into a release. However, because the pre-release is generated before that switch is flipped, we wouldn't know ahead of time if that pre-release will ever become an actual release, and thus don't know if we should generate the extra installers or not. So, we're kind of stuck in the situation that we would have to generate them all in the event an arbitrary pre-release was promoted to release.

@panther2

This comment has been minimized.

Copy link
Member

panther2 commented Nov 20, 2018

Thank you, @ssoloff .

A bundled Java inside the TripleA directory would definitely be a huge improvement.

So all in all this is my vote:

If we can somehow figure out a way to bundle only the releases I would vote for this option (above option 3 - installing a bundled Java inside the TripleA directory).

If the consequence of bundling was creating data masses for every pre-release I would vote for not bundling Java at all (above option 2). From a user-support point of view this appears to be the easiest solution anyway.

Either way we still need to identify which Java version actually is used by TripleA once the user runs into any Java issues. I wonder if that info could be stated in the UI (maybe under "Engine Preferences").
Still the user might have prehistoric i4jres-installations causing trouble with TripleA that can only be removed manually.

@ssoloff

This comment has been minimized.

Copy link
Member

ssoloff commented Nov 21, 2018

Either way we still need to identify which Java version actually is used by TripleA once the user runs into any Java issues. I wonder if that info could be stated in the UI (maybe under "Engine Preferences").

@panther2 Is there a reason asking the user to bring up the console and click Properties is not sufficient? If you're not aware, users can now bring up the console without actually starting a game. They can go into Engine Preferences > Game and enable the Show Console setting. Clicking Save will immediately bring up the console. (Not as simple as it used to be in 3635 when we had a dedicated button to do this under Engine Preferences, but much better than having to start a local game. 😄)

If we really want to put the JRE version front-and-center, we could easily display it on the main screen either above or below the Engine Version, if you think that would help.

@panther2

This comment has been minimized.

Copy link
Member

panther2 commented Nov 21, 2018

@ssoloff

Is there a reason asking the user to bring up the console and click Properties is not sufficient? ...

Yes, I am aware of this. To you and me it is a breeze, indeed, but to many users this is a barrier. Giving support on Java issues sometimes takes a lot of time,...

If we really want to put the JRE version front-and-center, we could easily display it on the main screen either above or below the Engine Version, if you think that would help.

It would help the supporter and the supported 😄

@simon33-2

This comment has been minimized.

Copy link
Contributor Author

simon33-2 commented Nov 22, 2018

And identify the frigging build everywhere we display the version. It doesn't appear in any logs at present.

@DanVanAtta

This comment has been minimized.

Copy link
Member

DanVanAtta commented Nov 22, 2018

Please confirm my understanding of this problem is correct:

  • The 'install-if-needed' JRE with install4j is only installed once and then not updated on future TripleA versions.

Is that about right?

With regards to file sizes, we've come a really long way: https://github.com/triplea-game/triplea/releases/1.8.0.10.912

I am relunctant to see download size get larger. I'm leaning option 3 with possibly some updates to the download page.

Second question, how much of a download file size increase are we talking about exactly?

@ssoloff

This comment has been minimized.

Copy link
Member

ssoloff commented Nov 22, 2018

Please confirm my understanding of this problem is correct:

  • The 'install-if-needed' JRE with install4j is only installed once and then not updated on future TripleA versions.

Is that about right?

Correct.

Second question, how much of a download file size increase are we talking about exactly?

Should be between 30-40 MiB, depending on the platform (~200% increase).

@DanVanAtta

This comment has been minimized.

Copy link
Member

DanVanAtta commented Dec 10, 2018

An idea:

  • have game detect java version, and if the version is less than a minimum then we'll show users a prompt asking them to download a bundled version.

This might let us keep the unbundled version as the recommended download. We can determine download counts from github releases, if we see there are majority more bundled downloads then unbundled, we'll know then the default should be for a bundled download.

@ssoloff

This comment has been minimized.

Copy link
Member

ssoloff commented Jan 5, 2019

A Mac user noted in #4455 (comment) that, on a fresh macOS system with no JRE installed, the installer correctly downloads the bundled JRE, but then fails to find it post-download.

Just noting that here, as it's tangentially related. However, it probably requires an issue of its own. I'll create one if we can confirm it happens with the latest stable macOS installer.

@DanVanAtta

This comment has been minimized.

Copy link
Member

DanVanAtta commented Feb 16, 2019

https://resources.ej-technologies.com/install4j/help/doc/index.html#install4j.helptopics.concepts.jreBundles

install4j offers you a number of strategies for JRE bundling. A statically bundled JRE is always distributed along with your application. Dynamical bundling means that if the installer cannot find a suitable JRE on the target computer, it will download a JRE bundle from your web server.

A shared JRE bundle will not be uninstalled when the application that has installed the bundle is uninstalled itself. If you dynamically bundle a JRE for multiple installers and install it as a shared JRE, only the first time when a user installs one of your installers, a JRE will be downloaded. Subsequent installations of other installers will find that shared JRE.


It sounds like if we unshare the bundled JRE, we can continue having an on-demand download of the JRE and it would then start to be updated when we updated the bundled JRE version. I'm hoping I'm not missing anything, seems like an easy fix for this.

@DanVanAtta

This comment has been minimized.

Copy link
Member

DanVanAtta commented Feb 19, 2019

@ssoloff @simon33-2 , what do you think please of this plan:

(1) Create a static bundle installer and offer it to those having problems. We've had a lot of downloads and few reported problems. Given the relative success with the DL numbers, this makes me think we should continue with dynamic bundle installer as the download of choice
(2) Decide if we will go to Java 11 in the next release. If not then add a 'min java' check to the game that will prompt the user to download the installer with the static bundle
(3) If we can show there are problems with the dynamic-bundle, then we can stop offering them as needed.

@simon33-2

This comment has been minimized.

Copy link
Contributor Author

simon33-2 commented Feb 22, 2019

Sounds like an improvement to the status quo. At least if people have problems they can be referred to the bigger download.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment