-
Bug
-
Resolution: Fixed
-
P2
-
6u22
-
b136
-
x86
-
windows_xp
-
Verified
J2SE Version (please include all output from java -version flag):
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)
Does this problem occur on J2SE 5.0.x or 6ux ? Yes / No (pick one)
Since Java 6u10
Operating System Configuration Information (be specific):
Windows XP [Version 5.1.2600]
Hardware Configuration Information (be specific):
Bug Description:
Next-generation java-plugin doesn't download pack200 compressed JARs
Steps to Reproduce (be specific):
Follow the description on http://download.oracle.com/javase/6/docs/technotes/guides/jweb/tools/pack200.html and deploy an applet
with both .jar and .jar.pack.gz archives.
Set the parameter <PARAM NAME="java_arguments" VALUE="-Djnlp.packEnabled=true"/> in the apple tag.
Make sure that the next-generation java-plugin is enabled in the java control panel.
Go to the website wich contains your applet and check the java console for downloaded applet archives (press "3" for network logging).
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The pack200 compressed applet archives (.jar.pack.gz) should be downloaded.
ACTUAL -
The classic jar archives (.jar) are downloaded.
REPRODUCIBILITY :
This bug can be reproduced always.
Even the simple testcase on evaluation works fine at first,a very simple way found to reproduce the pack200-Bug with the testcase:
1) Restart your browser to make sure no running JVM is attached to the browser (tested with WinXP / IE 8 / Java 6U23)
2) Go to java.com and run the java detection applet
3) Go to your pack200-testcase (for example http://localhost/test/example1.html)
The applet won't start because it is unable to load the main class from the pack200-archive.
If you skip step 2, the testcase runs without any problem.
Also, if you go to a non-applet-page after step 2 and wait for some seconds until the JVM is terminated the testcase runs fine, too.
the root cause of the bug might be the java plugin does not launch a new JVM
instance if the java_argument in the applet tag differ from the arguments of
already launched JVMs. It simpy launches the applet in the running JVM and
omits the java_arguments.
Believe it is a serious bug.
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)
Does this problem occur on J2SE 5.0.x or 6ux ? Yes / No (pick one)
Since Java 6u10
Operating System Configuration Information (be specific):
Windows XP [Version 5.1.2600]
Hardware Configuration Information (be specific):
Bug Description:
Next-generation java-plugin doesn't download pack200 compressed JARs
Steps to Reproduce (be specific):
Follow the description on http://download.oracle.com/javase/6/docs/technotes/guides/jweb/tools/pack200.html and deploy an applet
with both .jar and .jar.pack.gz archives.
Set the parameter <PARAM NAME="java_arguments" VALUE="-Djnlp.packEnabled=true"/> in the apple tag.
Make sure that the next-generation java-plugin is enabled in the java control panel.
Go to the website wich contains your applet and check the java console for downloaded applet archives (press "3" for network logging).
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The pack200 compressed applet archives (.jar.pack.gz) should be downloaded.
ACTUAL -
The classic jar archives (.jar) are downloaded.
REPRODUCIBILITY :
This bug can be reproduced always.
Even the simple testcase on evaluation works fine at first,a very simple way found to reproduce the pack200-Bug with the testcase:
1) Restart your browser to make sure no running JVM is attached to the browser (tested with WinXP / IE 8 / Java 6U23)
2) Go to java.com and run the java detection applet
3) Go to your pack200-testcase (for example http://localhost/test/example1.html)
The applet won't start because it is unable to load the main class from the pack200-archive.
If you skip step 2, the testcase runs without any problem.
Also, if you go to a non-applet-page after step 2 and wait for some seconds until the JVM is terminated the testcase runs fine, too.
the root cause of the bug might be the java plugin does not launch a new JVM
instance if the java_argument in the applet tag differ from the arguments of
already launched JVMs. It simpy launches the applet in the running JVM and
omits the java_arguments.
Believe it is a serious bug.