JRE in user home (#1410)

[wladimirleite]

Closes #1410.

Proposed Changes

The launch4j configuration files (and generated executables) were updated to use a JRE in the user home, if available.
If it is not present, it will use the usual bundled JRE (from "iped\bin").

When the analysis UI is starting, it checks if the JRE in the user home is present, otherwise it will copy from the bundled folder, so it can be used the next time IPED is launched.

Results

In our local network, a very small case was taking ~40 seconds until the main window became visible.
Using the local JRE reduced to ~18 seconds.

[Just a side note, it is still too slow, because of the poor performance of our local server/storage/network. The splash screen (#1416) would still be useful here.]

Limitations

One concern when using a JRE in the local home folder is how to update it.
As described above, the proposed implementation just copies from the bundled JRE folder to the home folder.
There is a pitfall here: how to update the local folder if we decide to change bundled JRE?

As the application will be using the local JRE, the copy will fail (JRE files are being used when the application is running).
If the newer version is incompatible (e.g., IPED starts to require a version like 14 or 17 and local JRE contains a 11), the application won't even start.

Launch4j version check is for installed JREs only (it looks in the Registry the versions numbers), so it won't be able to check the JRE version in the home folder.

The solution I implemented to overcome the "how to update the JRE" issue was to use the version number in the folder name.
Therefore, whenever the bundled JRE is updated, it should use a new folder (configured in AnalysisConfig.txt).
Launch4j configuration files must be updated (to use the correct folder) and executables need to be generated again.

I know this is not convenient (at all), but as IPED bundled JRE is not updated very often, I hope the proposed approach is acceptable.

[wladimirleite]

Updated Launch4j configuration files (and the used ICO, that I couldn't find in the project's repository).
Launch4jConfigs.zip

Not sure if it possible/desirable, but putting these files somewhere in the project's repository (even if the executable creation is done manually) may be a good idea.

[lfcnassif]

Thank you @tc-wleite!

The solution I implemented to overcome the "how to update the JRE" issue was to use the version number in the folder name.

Agreed, same as I thought.

I know this is not convenient (at all), but as IPED bundled JRE is not updated very often, I hope the proposed approach is acceptable.

I don't think this is that inconvenient, totally fine to me, thank you!

[lfcnassif]

Thank you @tc-wleite!

[lfcnassif]

@tc-wleite what do you think about putting the JRE version into the code and changing the homeJREFolder option to a boolean "copyJREToUserHome", so the new behavior would work even if users reuse old config files and it would also allow to disable the new behavior?

[wladimirleite]

@tc-wleite what do you think about putting the JRE version into the code and changing the homeJREFolder option to a boolean "copyJREToUserHome", so the new behavior would work even if users reuse old config files and it would also allow to disable the new behavior?

I agree!
Thinking a bit more, a Java version should match a IPED version, so I guess hardcoding makes more sense.