Eduardo Pelegri-Llopart wrote:
> How hard would it be to have a JRE-client specific configuration? It
> would seem to me that some deployments will be (maybe very large)
> intranet with strong requirements on the clients' configurations, so
> some customers may be willing to force their desktops to upgrade.
I expect we will encourage users to choose which JRE release to use with
several things in mind (see below). I don't think GlassFish itself will
need to be built or configured differently to take advantage of new and
coming improvements in the JRE.
1. I was intrigued by the possibility of using the Java kernel (Consumer
JRE) technology in GlassFish itself, especially for the app client
container. So I wrote to the folks working on the Java kernel effort.
They have not now - nor do they plan to - expose or support that
technology for use by developers for their own apps, even system apps
like app servers. The implementation was described as quite specific to
the JRE itself. They are advising people to wait for the implementation
of JSR-277 - the Java Module System.
2. I expect we will make good strides in reducing the app client
container footprint (number and sizes of JAR files required) using the
V3 module technology. This will not only shrink the footprint but
should also give app clients the advantage of just-in-time module
loading into the JVM - just as the Java kernel work gives the JRE
itself. The V3 module technology will not in and of itself provide the
deferred download behavior, but...
3. A near-equivalent of the deferred download behavior should be there
for Java Web Start launches if, as I plan, we use JAR indexing for the
app client container JAR in GlassFish V3. Java Web Start in Java SE 6
takes full advantage of JAR indexing, postponing the download of any
referenced JAR until its contents are needed.
I'm not sure where we stand at the moment about the minimum Java SE
release we'll require for GlassFish V3. But even if we will not require
Java SE 6, the approach I've sketched above allows us to build the
GlassFish V3 app client container to take advantage of these advances in
JRE technology without requiring users to run a particular minimum
release of Java SE.
We would certainly advertise the benefits of using Java SE 6 if
end-users will launch app clients using the GlassFish Java Web Start
feature. And we would advertise the benefits of the Consumer JRE/Java
kernel technology for app clients as it becomes available. Then users
can choose the Java SE release (and the rollout plan in their
enterprise!) that makes sense for them.
- Tim
>
> Would need validation of user's requriements, of course....
>
> Tim Quinn wrote:
>>
>>
>> glassfish_at_javadesktop.org wrote:
>>> Isn't there an issue about the size of the jars needed by Java Web
>>> Start clients of EJB3 beans. Would be nice to see improvements in a
>>> similar vein as the streamlining/simplification going on with the
>>> Consumer JRE and with JavaFX.
>> Indeed there is, and it's been written about extensively and
>> improving this is very high on our list for V3. It's actually an
>> issue whether the client is launched using Java Web Start or not, but
>> it's definitely more visible that way.
>>
>> We will not be able to take full advantage the improvements coming in
>> the JRE because V3 won't be able to assume a suitably advanced JRE.
>> Having said that, the modular approach that permeates V3 will drive
>> this improvement in the client to reduce the number and size of JARs
>> needed.
>>
>> - Tim
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>