Lazy JAR downloading with JNLP-powered applet

[Qu0ll]

I have not deployed an applet using JNLP before and I have a couple of
questions about lazy JAR downloading in this scenario.

1. It seems I should be able to use DownloadService to download JARs when I
want them but I am curious to know how and when the JARs would be downloaded
otherwise. If I specify say 5 JARs in the JNLP file, is it necessary to
explicitly use DownloadService to download them or will they all be
downloaded when they are required or perhaps when the applet is launched? I
am guessing it's not when the applet is launched or else there wouldn't be
much point in having DownloadService so how does it manage the downloading
of JARs if DownloadService is not explicitly utilised?

2. And, depending on the answer to (1), does the same apply to extensions?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Roedy Green]

1. It seems I should be able to use DownloadService to download JARs when I
want them but I am curious to know how and when the JARs would be downloaded
otherwise. If I specify say 5 JARs in the JNLP file, is it necessary to
explicitly use DownloadService to download them or will they all be
downloaded when they are required or perhaps when the applet is launched? I
am guessing it's not when the applet is launched or else there wouldn't be
much point in having DownloadService so how does it manage the downloading
of JARs if DownloadService is not explicitly utilised?

If the jars contain nothing but classes and resources, you don't need
the DownloadService at all. You just declare them in the JNLP with
your preferred download strategy. Everything happens automagically
after that.

See http://mindprod.com/jgloss/jnlp.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"You can have quality software, or you can have pointer arithmetic; but you cannot have both at the same time."
~ Bertrand Meyer (born: 1950 age: 59) 1989, creator of design by contract and the Eiffel language.

 

[Qu0ll]

If the jars contain nothing but classes and resources, you don't need
the DownloadService at all. You just declare them in the JNLP with
your preferred download strategy. Everything happens automagically
after that.

See http://mindprod.com/jgloss/jnlp.html

Thanks Roedy, that's a useful resource. But I am still unclear as to the
way extensions are downloaded. In my applet I intend to use the JOGL
extension but it is only required if certain navigation paths are chosen by
the user so I only want to download JOGL if and when it is required. Is
that possible or are extensions always downloaded "eagerly"?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Andrew Thompson]

I have not deployed an applet using JNLP before and I have a couple of
questions about lazy JAR downloading in this scenario.

1. It seems I should be able to use DownloadService to download JARs when I
want them but I am curious to know how and when the JARs would be downloaded
otherwise.  

*Typically* when the class is first referenced.
Having said that, there are exceptions.
- Natives. They are required eagerly. I am not sure
if the DownloadService can add them to the classpath
the first time you go to use them, I have not tried it,
but Sun's general advice is 'eager'.
- Jar's containing SPI classes. E.G. extra codecs for
Java Sound. Either the Jar is downloaded eagerly, or
you need to take 'active control' of the download via
the DownLoadService.

This 'when first referenced' strategy can trip up many
developers that are attempting to launch Jars lazily,
since they will often instantiate the classes of the
lazy Jars, eagerly. This overrides the 'lazy' declaration
and the entire app. is downloaded before appearing on-screen.

..If I specify say 5 JARs in the JNLP file, is it necessary to
explicitly use DownloadService to download them or will they all be
downloaded when they are required ..

Barring the caveats above for things like SPIs and
natives, yes. Although..

..or perhaps when the applet is launched?  

...that is how it ends up, for many.

2. And, depending on the answer to (1), does the same apply to extensions?

Basically yes. (I cannot think of any situations
where the behaviour would be different).

I have a page devoted to examples of using the
DownLoadService, but note that I was trying with
my own dialog, and it never worked completely right
<http://pscode.org/jws/cache/>

Example 8 is just broken, it does not launch.
Example 7 still had some quirks, but launches OK
and shows 2 of the 3 images (the 3rd is missing).

I must revisit & fix those examples sometime, but
I am too caught up at the moment with Java Sound
based projects.

 

[Qu0ll]

*Typically* when the class is first referenced.
Having said that, there are exceptions.
- Natives. They are required eagerly. I am not sure
if the DownloadService can add them to the classpath
the first time you go to use them, I have not tried it,
but Sun's general advice is 'eager'.
- Jar's containing SPI classes. E.G. extra codecs for
Java Sound. Either the Jar is downloaded eagerly, or
you need to take 'active control' of the download via
the DownLoadService.

This 'when first referenced' strategy can trip up many
developers that are attempting to launch Jars lazily,
since they will often instantiate the classes of the
lazy Jars, eagerly. This overrides the 'lazy' declaration
and the entire app. is downloaded before appearing on-screen.


Barring the caveats above for things like SPIs and
natives, yes. Although..


..that is how it ends up, for many.


Basically yes. (I cannot think of any situations
where the behaviour would be different).

I have a page devoted to examples of using the
DownLoadService, but note that I was trying with
my own dialog, and it never worked completely right
<http://pscode.org/jws/cache/>

Example 8 is just broken, it does not launch.
Example 7 still had some quirks, but launches OK
and shows 2 of the 3 images (the 3rd is missing).

I must revisit & fix those examples sometime, but
I am too caught up at the moment with Java Sound
based projects.

Thanks for the info. With those problems you are having getting
DownloadService to work, do you feel they are problems in your code or are
they bugs/issues with the service itself? That is, are you confident that
it can be made to work?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Andrew Thompson]

"Andrew Thompson" <[email protected]> wrote in message

(stuff re DownLoadService)

..With those problems you are having getting
DownloadService to work, do you feel they are problems in your code or are
they bugs/issues with the service itself?  

My code. I am positive(1) I saw it all 'work as
advertised' before I started messing with the
dialogs. In fact, the default behaviour if you
simply 'instantiate the class' (ex worrying about
the DownlLoadService at all) is to show a generic
JNLP progress dialog.

(1) Though it was a fair while ago that I last
looked at, or worked with, the code.

I should be revisiting the topic in the near future,
this time for classes, as opposed to images, I will
keep you informed of (grins) progress, if you'll do
the same (assuming you decide to go ahead with trying
lazy downloads - which I do highly recommend).

 

[Qu0ll]

(stuff re DownLoadService)


My code. I am positive(1) I saw it all 'work as
advertised' before I started messing with the
dialogs. In fact, the default behaviour if you
simply 'instantiate the class' (ex worrying about
the DownlLoadService at all) is to show a generic
JNLP progress dialog.

(1) Though it was a fair while ago that I last
looked at, or worked with, the code.

I should be revisiting the topic in the near future,
this time for classes, as opposed to images, I will
keep you informed of (grins) progress, if you'll do
the same (assuming you decide to go ahead with trying
lazy downloads - which I do highly recommend).

Good to hear. I certainly will be proceeding with lazy downloading, it is
vital to the success of my applet. JOGL is a large library and I simply
don't want to download it if the end user never interacts with the applet in
such a way that requires it. The same logic will be applied when I
integrate JMC into the applet.

Yes, I will keep you updated as to my progress over the coming weeks and
thanks for your input.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Andrew Thompson]

...I certainly will be proceeding with lazy downloading,

Cool.

.. it is
vital to the success of my applet.  JOGL ..

There is a generic JNLP available for JOGL, but I
am pretty sure it does not do well as far as 'lazy
downloads' go. It is all 'eager'.

Wait, there it is..
<https://jogl.dev.java.net/webstart/jogl.jnlp>

Um.. actually, my 'Text Editor' (that I would normally
use to launch little apps., one of which pulls the
content of an URL and dumps it in a JTextArea) just
crashed and won't re-open (go figure). I'm going to
reboot & try replying to the rest of this, after that.

 

[Wojtek]

Qu0ll wrote :

In my applet I intend to use the JOGL extension but it is only required if
certain navigation paths are chosen by the user so I only want to download
JOGL if and when it is required.

As an end user I would be annoyed if I clicked on a button and was
greeted by a download dialog.

Why not do the download in a separate background thread while the user
is busy doing other things in the foreground?