rom: Kumar Srinivasan <###@###.###>
Subject: Re: 64-bit JavaWS
To: ###@###.###
Cc: ###@###.###
MIME-Version: 1.0
Content-MD5: o+JhxEuuKhwT7RDcZxIiog==

Steve,
Sounds good, lets capture this information and put it up
on the JaWS internal home page so that we can refer to it
when we decide to cross the bridge.
Thanks!

>Kumar,
>
>Andy and I were thinking about 64-bit JavaWS, mostly along the lines
>of what you & I talked about on the phone. So here's what we think
>we would have to do, to get 64-bit JavaWS.
>
>1. Recompile JavaWS JNI code under 64-bit & bundle it appropriately
> so that System.loadLibrary() can find it under 32 or 64 bit.
>
>2. (optional but desired) Add JNLP field to select 64-bit VM so that
> JavaWS application developers can deploy a 64-bit JNLP application.
> This requires a JNLP spec change.
>
>3. Modify JavaWS application native lib JAR handler to correctly
> extract 64-bit native libs. Modify JNLPClassloader to correctly
> setup environment so apps using System.loadLibrary() can find
> their native libs.
>
>Notes: We don't have to recompile any front-end (javawsbin) native
>code because 32-bit process can launch a 64-bit (Java in this case)
>process. This is true on Solaris and I assume it's true on Windows.
>I'm also assuming that 32 and 64-bit native libs can coexist on
>Win64 in a way that System.loadLibrary() can find the appropriate
>libs (something analagous to sparcv9 subdir on solsparc).
>
>Also, 2 is optional because anyone who wants to deploy to 64-bit is
>probably in an enterprise environment and can control which JREs are
>available to JavaWS. Therefore, they can guarantee their app will
>run on 64-bit by tweaking version strings in the app & in the JRE
>configuration. This is just a workaround though - the correct
>way would be to implement #2 and add a JNLP tag.
>
>-Steve