Copy embedded JRE to user home and reuse it

[lfcnassif]

As discussed recently on #622

[wladimirleite]

Another option, not sure whether it is feasible, would be copying the provided JRE to users home (something like C:\Users<user>.iped\jre), in Windows machines.
So after the first execution, it will use this JRE instead.

Using the installed JRE is good, but nowadays there are many versions around, so finding a compatible JRE (11 with JavaFX) won't be very likely, except in controlled machines.

[lfcnassif]

Another option, not sure whether it is feasible, would be copying the provided JRE to users home (something like C:\Users.iped\jre), in Windows machines.
So after the first execution, it will use this JRE instead.

Good idea. That could be used for the second process in the bootstrap, but I think for the first one, the embedded JRE would still have to be used.

[wladimirleite]

@lfcnassif, is the JRE choice currently controlled by the launch4j configuration?
I know you are working on other issues, may I take a closer look at this?
Can you share the launch4j configuration file? (if it is not already in the project)
For the IPED cases accessed through our local network, this enhancement may help.

[lfcnassif]

@lfcnassif, is the JRE choice currently controlled by the launch4j configuration?

yes

I know you are working on other issues, may I take a closer look at this?

Sure!

Can you share the launch4j configuration file? (if it is not already in the project)

They are attached below, there is one for processing and other for analysis.
Launch4jConfigs.zip

The related config is this:

Maybe newer Launch4j versions could have more useful options.

For the IPED cases accessed through our local network, this enhancement may help.

I totally agree.

[lfcnassif]

PS: AFAIK one Launch4j limitation is that it can't check for JavaFX.

[wladimirleite]

Thanks @lfcnassif! I will take a closer a look and let you know if I find anything useful.

[wladimirleite]

Launch4j supports multiple bundled JRE paths, which is great!
That allows looking first at user home directory (%USERPROFILE%\.iped\jre) then in the IPED bundled jre (iped\jre).

After a few hours struggling here, I found out it is not working properly due to a bug in Launch4j, which was not so great :-)
I opened a ticket, but the project does not seem very active nowadays.
https://sourceforge.net/p/launch4j/bugs/224

As the fix seems trivial, I will try to build it from source.
As the issue is in C part, not sure if it would be simple...

[lfcnassif]

Launch4j supports multiple bundled JRE paths, which is great!
That allows looking first at user home directory (%USERPROFILE%\.iped\jre) then in the IPED bundled jre (iped\jre)

I saw that but didn't check if env vars would work, great!

After a few hours struggling here, I found out it is not working properly due to a bug in Launch4j, which was not so great :-)

Thank you for your valuable time @tc-wleite.

[lfcnassif]

Sorry, I hit the wrong button.

[wladimirleite]

I saw that but didn't check if env vars would work, great!

Environment variables are supported and working fine.
%USERPROFILE% was correctly replaced by its actual (full) path.
Unfortunately a bug is preventing the solution I had in mind to work, because the second path would be relative (iped/jre).
Supporting multiple paths separated by a semicolon was implemented in Launch4j about 3 years ago, so it is quite strange to have a trivial (to reproduce and fix) bug there.
Anyway, I will try to figure out how to overcome this.

[lfcnassif]

Something like %WORKINGDIR% works?

[wladimirleite]

Something like %WORKINGDIR% works?

%EXEDIR% worked!
As it is replaced by an absolute path, the multiple paths feature worked fine.
So I won't need to compile Launch4j :-)

[lfcnassif]

Great!

[lfcnassif]

Just a thought, another related idea is to also copy iped/lib folder to user home. To not bloat user home with lots of IPED versions, a compatibility schema could be used, obviously this would put more maintenance effort on our side... Probably this is not needed at all after #1420 is integrated.

Actually, one of my ideas to #1341 is to allow opening cases from the Case creation/config UI and maybe creating a new option, the opposite of --portable, to don't copy libs and tools to the case folder, this would be useful for cases analyzed by examiners end-to-end.