[RFC][icedtea-web]: PR658 - jnlp.{pack,version}Enabled

[Denis Lila]

One more thing. In the patch I also try to implement versionEnabled.

I now think we should get rid of this, since it doesn't seem
to be supported for applets:
http://download.oracle.com/javase/6/docs/technotes/guides/jweb/tools/pack200.html#versionDownload

Also, I have one more question:
If this all looks good, should it be pushed as one changeset?
I'm uneasy about that since there seem to be at least 4 different
issues I try to fix here:
1. the jar == ajar issue (which could easily be broken for non-plugin
files too, if they created new JARDesc objects in getResources(Class<T>)
2. The naming of packed files to .pack.gz instead of .jar.pack.gz
(unrelated to the plugin).
3. Checking for "gzip".equals(con.getContentEncoding()) before checking
for pack200 and gzip encoding (again, unrelated to plugin).
4. And the main bug: the lack of implementation of packEnabled
for plugins (fixed by the instanceof).

Should I break it up?

Thank you,
Denis.

----- Original Message -----
> Hi.
> 
> This is supposed to fix the packEnabled issue.
> 
> ChangeLog (with explanations of changes).
> 
> + * netx/net/sourceforge/jnlp/PluginBridge.java
> + (usePack, useVersion, usePack(), useVersion()): added.
> + (PluginBridge): initializing usePack, useVersion.
> 
> These methods are called from getDownloadOptionsForJar to determine
> whether pack/versionEnabled is on.
> 
> + Also added import java.util.Arrays.
> + * netx/net/sourceforge/jnlp/cache/ResourceTracker.java
> + (downloadResource): changed the order in which pack200+gz
> compression
> + and gzip compression are checked.
> 
> This fixes a problem where the http connection object told us that
> the stream was "gzip" encoded. A file could have been compressed
> with both pack200 and gzip, so a return value of "gzip" from
> con.getContentEncoding() is still correct, but in these cases
> we assumed incorrectly that it was _only_ gzip encoded, so we
> ended up trying to use a pack200 file as a jar file.
> 
> + * netx/net/sourceforge/jnlp/cache/ResourceUrlCreator.java
> + (getUrl): if usePack now calling concat instead of replace.
> 
> This
> http://download.oracle.com/javase/6/docs/technotes/guides/jweb/tools/pack200.html#pack200
> says that when using packEnabled X.jar should be named X.jar.pack.gz.
> We were computing X.pack.gz.
> 
> + * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java
> + (getDownloadOptionsForJar): added special case for PluginBridge,
> using
> + better jar comparison.
> 
> Two changes here:
> 1. this explicitly tests whether the file is a
> PluginBridge. The call to desc.getPropertiesMap() would always
> return an empty Map when file is a PluginBridge. I tried changing
> the implementation of PluginBridge.getResources so that
> getResources(Class<T> launchType) would have a case for
> PropertyDesc.class, but that caused problems later, when we
> called System.setProperty on the returned properties.
> 
> 2. I replaced "jar==aJar" with a URL.equals() comparison. Without
> this, the condition would always evaluate to false when file is
> a PluginBridge, because of this line in PluginBridge.java:
> jarDescs.add(new JARDesc(new URL(codeBase, jars[i]),
> null, null, false, true, false, true));
> 
> It creates new JARDesc's, so == fails.
> Should I use CacheUtil.urlEquals here, instead of URL.equals?
> 
> I tested this with two applets that use packEnabled:
> My toy test applet (it's working if a diagonal line is drawn):
> http://icedtea.classpath.org/~dlila/tmp/
> 
> What started this all:
> http://www.jroller.com/dgilbert/entry/jfreechart_and_jxlayer
> 
> They both load successfully, without any exceptions thrown.
> For me, the second applet is horribly slow with icedtea-web.
> This is probably because I was using a debug build of icedtea6,
> but I thought I should mention it. If someone could test it
> with a product build, that would be great.
> 
> I would appreciate any feedback.
> 
> Thank you,
> Denis.