Re: [Openjnlp-devel] Lazy jars

[Mario C. <mar...@po...>]

Kevin,

First of all, the specification states that "a JNLP Client is always allowed
to eagerly download all resources if it chooses".  I think that as a
default, you could use that instead of not doing anything with lazily
downloadable resources.  At least things would work, and comply to the spec
too.

Second, I reread this part of the specification and it still seems to me
that my patch is a valid implementation as per the spec.  I agree with you
that it is desirable to cache the lazily downloaded resources (for
performance but especially for offline launching), but I don't think you are
required to.  My solution was inspired by a footnote in a previous version
of the spec that said "Lazy download is a standard feature of the Java 2
Platform's class loading mechanism."  This pointed directly to the
URLClassLoader, as far as I can tell.  However, this footnote disappeared
from later revisions, so maybe they did imply that caching was if not
mandated, at least strongly suggested, considering the offline scenarios.

In my opinion, lazy resources should be specified as remote URLs initially,
and these remote references be progressively replaced with local URLs as the
resources are downloaded in the background.  However, URLClassLoader does
not support such replacements of jars.  On the other hand, using the remote
URL on the first execution, and the local URL on subsequent executions,
achieves the same results.

Just my current thoughts on the subject, open to discussion... : )

Mario

> > I tried running a JNLP app that used lazy loading of some jars, and it
> > simply didn't work because of ClassNotFoundExceptions. Going through
> > the code, I noticed that nothing is done about lazy jars. My
> > understanding of the spec. is that these jars should always be loaded
> > over the network, like applet jars. Is so, the correct way to
> > implement it would be to add the remote (http:) URLs
>
> You are correct, OpenJNLP does not yet support lazy jars. Unfortunately,
> your interpretation of loading lazy jars doesn't seem to agree with the
> specification. Lazy jars still are cached locally, but are not retrieved
> until needed. The pertinent part of the JNLP specification is Section
> 4.4, "Parts and Lazy Downloads". For this reason I don't think I can use
> your suggested changes (as good as they are) but I will use your work as
> motivation to get lazy jars implemented.
>
> [...]