asked on

Class loader Problem

I have an ejb client application that works fine when deployed manually. I then decided to decided to deploy with Java Web Start, the deployment goes fine but some of the app. functions don't work and return an error on the console. Here is a copy of the error message.

Java Web Start Console, started Thu Nov 13 10:38:39 EST 2003

Java 2 Runtime Environment: Version 1.4.0_03 by Sun Microsystems Inc.

Logging to file: C:\Test-me\Log.txt

java.lang.ClassFormatError: cc/admin/email/client/AdministratorUI$18 (Illegal Variable name " val$jtf")

      at java.lang.ClassLoader.defineClass0(Native Method)

      at java.lang.ClassLoader.defineClass(Unknown Source)

      at java.security.SecureClassLoader.defineClass(Unknown Source)

      at com.sun.jnlp.JNLPClassLoader.defineClass(Unknown Source)

      at com.sun.jnlp.JNLPClassLoader.access$1(Unknown Source)

      at com.sun.jnlp.JNLPClassLoader$1.run(Unknown Source)

      at java.security.AccessController.doPrivileged(Native Method)

      at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)

      at java.lang.ClassLoader.loadClass(Unknown Source)

      at java.lang.ClassLoader.loadClass(Unknown Source)

      at java.lang.ClassLoader.loadClassInternal(Unknown Source)

      at cc.admin.email.client.AdministratorUI.createTermAndYearDialog(AdministratorUI.java:440)

      at cc.admin.email.client.AdministratorUI.jMenuItemSCTAY_actionPerformed(AdministratorUI.java:398)

      at cc.admin.email.client.AdministratorUI.access$6000471(AdministratorUI.java:77)

      at cc.admin.email.client.AdministratorUI$6.actionPerformed(AdministratorUI.java:212)

      at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)

      at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Unknown Source)

      at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)

      at javax.swing.DefaultButtonModel.setPressed(Unknown Source)

      at javax.swing.AbstractButton.doClick(Unknown Source)

      at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)

      at javax.swing.plaf.basic.BasicMenuItemUI$MouseInputHandler.mouseReleased(Unknown Source)

      at java.awt.Component.processMouseEvent(Unknown Source)

      at java.awt.Component.processEvent(Unknown Source)

      at java.awt.Container.processEvent(Unknown Source)

      at java.awt.Component.dispatchEventImpl(Unknown Source)

      at java.awt.Container.dispatchEventImpl(Unknown Source)

      at java.awt.Component.dispatchEvent(Unknown Source)

      at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)

      at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)

      at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)

      at java.awt.Container.dispatchEventImpl(Unknown Source)

      at java.awt.Window.dispatchEventImpl(Unknown Source)

      at java.awt.Component.dispatchEvent(Unknown Source)

      at java.awt.EventQueue.dispatchEvent(Unknown Source)

      at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)

      at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)

      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)

      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)

      at java.awt.EventDispatchThread.run(Unknown Source).

The portion of my code responsible for this is:

final JTextField jtf = new JTextField(termAndYear[1]);
jtf.addKeyListener(new JTextFieldFormat(jtf,4));
jtf.addFocusListener(new java.awt.event.FocusAdapter() {
public void focusGained(FocusEvent e) {
jtf.setCaretPosition(0);
jtf.selectAll();
}
});

Apart from that action, the application works just fine. The interesting thing is, this does not happen if I run the application locally using the required jar files. It only happens when deployed with Java Web Start.

I'll appreciate any help. Thanks

SuperKarateMonkey

What is a JTextFieldFormat? It doesn't appear in the 1.4.2 API. Is this a custom-built class or am I missing something?

Right now, it smells an awful lot like this issue is the JDK/JRE version, unless a JTextFieldFormat is a custom-built class, and perhaps you're not uploading the right .jar file for it.

ASKER CERTIFIED SOLUTION

Igor Bazarny

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

SuperKarateMonkey

The fact that jtf is final means that it's properly visible to it's anonymous inner class. I strongly suspect the problem is with this JTextFieldFormat object, which doesn't appear to have any definition I've ever heard of.

kunlenzo247

ASKER

Thanks buddy. JTextFieldFormat is a custom class but I think I have a lead on what the issue is. It has to do with the inner class loading and the final objects that I declared. When I comment those lines(jtf.setCaretPosition(0) and jtf.selectAll()) and redo the packaging, it doesn't come up with the errors. So I guess it's because of the inner class.
The problem is, I have a couple of inner classes referencing final objects in my app. What can I do please?
Thanks

Kunle

SOLUTION

SuperKarateMonkey

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

SuperKarateMonkey

Oh ,and you'll also need to add one additional method to your class:

public void focusLost( FocusEvent e )
{
// Do nothing
}

Otherwise, you don't actually implement FocusListener

kunlenzo247

ASKER

Here is an example of a method that sets a table model based on parameters passed.

private void updateUIComponents(final JTable table,
final Object[][] records,
final String[] header) {
Runnable doSetTableValues = new Runnable() {
public void run() {
table.setModel(createTableModel(records,header));
}
};
SwingUtilities.invokeLater(doSetTableValues);
}

And I have other instances that are simlilar. Does it mean that my only solution is to re-code all over especially considering the fact that it runs fine locally using the same runtime.

Thanks.

SuperKarateMonkey

Well, if the problem is simply in the anonymous inner classes, then no, you needn't re-code. Just eliminate them and implement the interfaces instead.

As for this runnable stuff, Runnable is an interface as well. You can have another class implement it and then use that class instead, though in that case you might not be able to have your master class implement it itself, since you're deferring execution.

However, it's entirely possible that the errors are only coming from the adapters, not the Runnable(). Try eliminating the adapters first, then see if it'll work. I'm not precisely sure why you can't use anonymous inner classes with Java Web Start: It might have to do with the security manager treating web start stuff as applets, perhaps.

Also look into solving this threading problem with a Thread object, or a TimerTask. I couldn't give any suggestions how without seeing the code, but that might work if the Runnable stuff is hosing you.

kunlenzo247

ASKER

I think you are right about the security manager cos I read up on ClassLoader and defineClass() (like I pasted above) and realised that my anonymous inner classes are responsible for the result because the default class loader cannot correlate my objects that I declared as final with the corresponding classes. I really don't fancy the idea of restructuring the codes all-over.
Maybe it's a bug that needs to be fixed in Java Web Start cos I also came across a simlilar thread in a JDC forum. i.e
http://forum.java.sun.com/thread.jsp?forum=38&thread=372291
You could check it out too. It's exactly what I'm facing and no known solution yet. I'll appreciate any further contributions. Once again, thanks for your efforts.

Kunle.

Igor Bazarny

The field it's complaining about is synthetic field in the anonymous class, inserted by the compiler. This field refers to the value of the final local variable. It is not the local variable itself. Apparently classloader doesn't like the field name created by the compiler.
There is no way to control field name compiler uses. If moving to another JVM is not an option (and we still don't know whether 1.4.2 has this problem), the only solution I see is change of code so that there will be no synthetic fields.