[izpack-dev] Is it possible to change the JVM during the lifetime of the installer?

[Coquelicot]

hello,

first of all, big thanks for IzPack installation package - it is a
great piece of software and is working very good for me.

There is a little snag, though: I have been thinking about the
following issue for some time, maybe you will be able to help: the
IzPack installer is built as a JAR file and thus must be run using the
Java Virtual Machine. One of the panels can be used to select the
JDK/JRE version that will run the application. Is it possible to
either change the JVM that is running the installer to 'switch' to the
selected JVM from the JDKPanel? The thing is that the installation
process needs to examine if the target JVM supports certain features
(in my case Java Advanced Imagery API; I attempt to find out about
that by trying to load some classes that are supported by the JAI, and
not by the 'stock' JVM).

The similar thing occurs when I am trying to use IzPack to install
Java software on both 32- and 64-bit machines; the architecture
dependent files (native executables) need to be copied according to
the architecture used; the 64-bit system (Windows) can have 32-bit JVM
installed that is used when the installer JAR is started by clicking.
I would like to be able, after selecting the JDK/JRE from JDKPanel,
conduct the installation using the target JDK/JRE (the one that will
be used to run the application).

Big thanks, kind regards

Lukasz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Julien Ponge]

Hi,

So you mean that you select another JRE/JDK, and dynamically continue
the execution from it?

In this case that is not possible :-)

Cheers

--
http://izpack.org/
http://jpz-log.info/
http://julien.ponge.info/

[Coquelicot]

yes, that's what I thought...

I guess there is no way to trick one JVM's classloader to try to use
other JVM's libraries?...

Or: maybe something like: 2 installers; one that will, after selecting
the 'target' JVM, will start it up (from ProcessPanel for example?...)
and conduct the rest of the installation? (sounds very much like
hacking)

Lukasz

[Julien Ponge]

> Or: maybe something like: 2 installers; one that will, after selecting
> the 'target' JVM, will start it up (from ProcessPanel for example?...)
> and conduct the rest of the installation? (sounds very much like
> hacking)

Yep, serializing the state then relaunching could be a solution...

[Coquelicot]

Hmm, this is certainly better that 'installer launching 2nd installer'
(eliminates the need for 2 installers).

When you speak of 'serializing the state' - which classes should be
serialized?... would serializing the topmost class ('Installer' ?...)
would do the trick?...

Lukasz

[Julien Ponge]

Yep, but that was the big picture (i.e., you store the installer
state, and launch a second one that knows how to recover, etc) :-)

[Tim Farrell]

Another way around this is to carry the platform
jres as part of your distribution and use a
launcher shell to select the right JRE to use in
running the installer. Not a windows friendly solution but who cares:)

At 01:06 PM 12/15/2009, you wrote:
>Yep, but that was the big picture (i.e., you store the installer
>state, and launch a second one that knows how to recover, etc) :-)
>
>On Tue, Dec 15, 2009 at 6:22 PM, Coquelicot <coquel...@gmail.com> wrote:
> > Hmm, this is certainly better that 'installer launching 2nd installer'
> > (eliminates the need for 2 installers).
> >
> > When you speak of 'serializing the state' - which classes should be
> > serialized?... would serializing the topmost class ('Installer' ?...)
> > would do the trick?...
> >
> >
> > Lukasz
> >
> >
> >
> > On Tue, Dec 15, 2009 at 6:15 PM, Julien Ponge
> <julien...@gmail.com> wrote:
> >>> Or: maybe something like: 2 installers; one that will, after selecting
> >>> the 'target' JVM, will start it up (from ProcessPanel for example?...)
> >>> and conduct the rest of the installation? (sounds very much like
> >>> hacking)
> >>
> >> Yep, serializing the state then relaunching could be a solution...
> >>
> >> --
> >> http://izpack.org/
> >> http://jpz-log.info/
> >> http://julien.ponge.info/
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this list, please visit:
> >>

> >> Â Â http://xircles.codehaus.org/manage_email

> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >

> > Â Â http://xircles.codehaus.org/manage_email

> >
> >
> >
>
>
>
>--
>http://izpack.org/
>http://jpz-log.info/
>http://julien.ponge.info/
>
>---------------------------------------------------------------------
>To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email

[Coquelicot]

yes, this may work - provided that IzPack classes are implementing
Serialized interface correctly :).

I will try to explore that - if it works, I will share the experiences
on the mailing list.

thanks for the idea, Julien!

Lukasz

[Coquelicot]

Tim,

well, this is a very crude solution :). And personally - I don't care
about the Windows, but the installer has to :).

I will try to explore the serialization solution (even though it will
probably include creation of huge temporary files), it will be a good
introduction to Java object serialization.

thanks for help!

Lukasz

[Bartz, Klaus]

Hi Lukasz,
spontaneously I see two solutions.
1. Look into JDKPathPanel. There you can see how to start a second JVM. Write a short java main program which tests the things you need and writes the result on System.out. In the JDKPathPanel you can see how to parse the things the program has written on stdout (or - if you need - on stderr).

2. If you only have to know the existent of JAI on Windows, look into registry. It is little bit strange because SUN has changed registry path in the past.

HKLM\SOFTWARE\SUNW\Java Advanced Imaging old and new age
HKLM\SOFTWARE\Sun Microsystems, Inc.\Java Advanced Imaging middle age

HKLM\SOFTWARE\SUNW\JAI ImageIO Tools old and new age
HKLM\SOFTWARE\Sun Microsystems, Inc.\JAI Image I/O Tools middle age

To search and verify registry key and values see also JDKPathPanel.

Cheers

Klaus

-----Ursprüngliche Nachricht-----
Von: Coquelicot [mailto:coquel...@gmail.com]
Gesendet: Dienstag, 15. Dezember 2009 17:24
An: d...@izpack.codehaus.org
Betreff: [izpack-dev] Is it possible to change the JVM during the lifetime of the installer?

hello,

first of all, big thanks for IzPack installation package - it is a great piece of software and is working very good for me.

There is a little snag, though: I have been thinking about the following issue for some time, maybe you will be able to help: the IzPack installer is built as a JAR file and thus must be run using the Java Virtual Machine. One of the panels can be used to select the JDK/JRE version that will run the application. Is it possible to either change the JVM that is running the installer to 'switch' to the selected JVM from the JDKPanel? The thing is that the installation process needs to examine if the target JVM supports certain features (in my case Java Advanced Imagery API; I attempt to find out about that by trying to load some classes that are supported by the JAI, and not by the 'stock' JVM).

The similar thing occurs when I am trying to use IzPack to install Java software on both 32- and 64-bit machines; the architecture dependent files (native executables) need to be copied according to the architecture used; the 64-bit system (Windows) can have 32-bit JVM installed that is used when the installer JAR is started by clicking. I would like to be able, after selecting the JDK/JRE from JDKPanel, conduct the installation using the target JDK/JRE (the one that will be used to run the application).

Big thanks, kind regards

Lukasz

---------------------------------------------------------------------

[Tino Schwarze]

On Tue, Dec 15, 2009 at 05:24:17PM +0100, Coquelicot wrote:

> There is a little snag, though: I have been thinking about the
> following issue for some time, maybe you will be able to help: the
> IzPack installer is built as a JAR file and thus must be run using the
> Java Virtual Machine. One of the panels can be used to select the
> JDK/JRE version that will run the application. Is it possible to
> either change the JVM that is running the installer to 'switch' to the
> selected JVM from the JDKPanel? The thing is that the installation
> process needs to examine if the target JVM supports certain features
> (in my case Java Advanced Imagery API; I attempt to find out about
> that by trying to load some classes that are supported by the JAI, and
> not by the 'stock' JVM).

For that purpose, I'd ship a single .class file (CheckJVMFeatures.class)
and launch that using the target JVM. It should be possible to get a
useful exit code.

HTH,

Tino.

--
"What we nourish flourishes." - "Was wir nähren erblüht."

www.lichtkreis-chemnitz.de
www.tisc.de