United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-8022042 Java Plugin Runtime parameter for setting classpath does not work
JDK-8022042 : Java Plugin Runtime parameter for setting classpath does not work

Details
Type:
Bug
Submit Date:
2013-04-20
Status:
Closed
Updated Date:
2013-12-05
Project Name:
JDK
Resolved Date:
2013-08-07
Component:
deploy
OS:
windows_7
Sub-Component:
plugin
CPU:
Priority:
P3
Resolution:
Fixed
Affected Versions:
7u21
Fixed Versions:
7u40 (b33)

Related Reports

Sub Tasks

Description
FULL PRODUCT VERSION :
java version  " 1.7.0_21 " 
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) Client VM (build 23.21-b01, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Windows 7 - Service Pack 1

A DESCRIPTION OF THE PROBLEM :
We have a Java component (bean) which uses the ActiveX Bridge so it can be accessed through COM by a Windows application. The Java component loads classes from an external Jar file, so it relies on the classpath parameter (-cp=) in the Java Runtime Parameters of the Plugin Control Panel settings.

This mechanism has worked in all previous versions of the Java Plugin. However, when using Java 1.7, the class in the external jar file is not loaded and a ClassNotFoundException is generated.

We have tried disabling the Next-generation plugin, but that has not helped either.The only things we can do to make it work are:
1. Extract the classes from the jar and copy them to the AXBridge\Lib directory.
2. Copy the jar file to the C:\Program Files (x86)\Java\jre7\lib\ext directory.
However, neither of these approaches are acceptable solutions for our customers.

REGRESSION.  Last worked in version 6u45

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a Java Bean that loads a class using the standard Java classloader mechanism.
2. Package the bean so it is registered for use with the ActiveX Bridge.
3. Set the classpath in the Plugin Java Runtime Parameters (using the Java Control Panel) to reference a Jar file that contains the class that needs to be loaded by the bean. (e.g. -cp=c:\Jars\MyJar.jar)
4. Run the Windows application to call the Java Bean through COM
5. A ClassNotFoundException will be generated because the jar file containing the required class cannot be found.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The required class is loaded by the Java Bean. The specified jar file should be found in the classpath setting of the Java Plugin Runtime parameters.
ACTUAL -
A ClassNotFoundException is thrown.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
130420 012508(Generate.generateComplete loading view generator)[E]:
java.lang.ClassNotFoundException: com.unisys.jellygen.GenerateMyASPdotNET
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.unisys.util.ObjectLoader.load(ObjectLoader.java:60)
at com.unisys.jellygen.Generate.generateComplete(Generate.java:642)
at com.unisys.jellygen.GenerateProxyLDA.generateComplete(GenerateProxyLDA.java:298)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.Trampoline.invoke(Unknown Source)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source)
at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.BeanDispatchImpl.invoke(Unknown Source)


130420 012508(Generate.generateComplete)[E]:
com.unisys.jellybeans.NoSuchObjectException: Can't find object: com.unisys.jellygen.GenerateMyASPdotNET
at com.unisys.jellygen.Generate.generateComplete(Generate.java:647)
at com.unisys.jellygen.GenerateProxyLDA.generateComplete(GenerateProxyLDA.java:298)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.Trampoline.invoke(Unknown Source)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source)
at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.BeanDispatchImpl.invoke(Unknown Source)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
I do not have a convenient test case at the moment to demonstrate the problem. Please let me know if you need me to create this for you.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Option 1. Extract classes from Jar file and copy them to the AXBridge\Lib directory.

Option 2. Copy Jar file to C:\Program Files (x86)\Java\jre7\lib\ext directory
                                    

Comments
this might be related to jp2launcher fix - i thought we did preserve most of the old code related to axbridge though.  anyway - need to try to reproduce.
                                     
2013-04-25
I think it should be already fixed by 8016005, because now we relaunch JVM if there are user args in JCP, but I don't have a user's test to check it's fixed.
                                     
2013-08-06
Should be resolved as part of fix for JDK-8016005, please verify.
                                     
2013-08-07



Hardware and Software, Engineered to Work Together