-------------- Quick summary -------------------------
When using web start or the app client script I'd like to be able to include a
splash screen in the application-client.xml file that is passed as an argument
to the JRE.
-------------- The long winded version --------------
I'm a little late to this discussion, but I have a couple web start specific
observations. I've been using the web start functionality for a little while
and, besides the large download, there is one thing that would keep me from
using it in a production environment.
When I launch an application via web start, there is a delay, with no user
feedback or splash screen, while the acc loads.
With the client script download I can modify it and give the jre a splash screen
to use until my application takes over and can show a real, progress monitored,
splash screen. I use the same image for both and it looks like one splash
screen from the second you double click the app until the UI frame loads.
Tim Quinn wrote:
>
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>