This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I can open java form classes that inherit from JPanel, but when I open form com.sun.forte4j.j2ee.lib.ui.XMLSerializationClassesEditor, which inherits from com.sun.forte4j.j2ee.lib.ui.EJBMPropertyEdtiorSupport (both of these are in the S1S closed source), I get the following exception: ***************** Annotation: Cannot create form based on the class specified (extended) in the java source file. The problematic class is: com.sun.forte4j.j2ee.lib.ui.EJBMPropertyEditorSupport. It was not possible to load the class or create an instance of it. Form Editor will use javax.swing.JPanel instead (for design only). See the ide.log file for details about exceptions. The ide.log file is located in the D:\netbeans_userdata\system folder. java.lang.InstantiationException at sun.reflect.InstantiationExceptionConstructorAccessorImpl.n ewInstance (InstantiationExceptionConstructorAccessorImpl.java:30) at java.lang.reflect.Constructor.newInstance (Constructor.java:274) at java.lang.Class.newInstance0(Class.java:296) at java.lang.Class.newInstance(Class.java:249) at org.netbeans.modules.form.CreationFactory$1.run (CreationFactory.java:127) at org.netbeans.modules.form.FormLAF$1.run (FormLAF.java:56) at org.openide.util.Mutex.doEventAccess(Mutex.java:916) at org.openide.util.Mutex.readAccess(Mutex.java:204) at org.netbeans.modules.form.FormLAF.executeWithLookAndFeel (FormLAF.java:42) at org.netbeans.modules.form.CreationFactory.createDefaultInst ance(CreationFactory.java:123) at org.netbeans.modules.form.RADComponent.createBeanInstance (RADComponent.java:185) at org.netbeans.modules.form.RADComponent.initInstance (RADComponent.java:128) at org.netbeans.modules.form.FormModel.setFormBaseClass (FormModel.java:97) at org.netbeans.modules.form.GandalfPersistenceManager.loadFor m(GandalfPersistenceManager.java:264) at org.netbeans.modules.form.FormEditorSupport.loadFormData (FormEditorSupport.java:528) at org.netbeans.modules.form.FormEditorSupport.access$000 (FormEditorSupport.java:37) [catch] at org.netbeans.modules.form.FormEditorSupport$1.run (FormEditorSupport.java:113) at java.awt.event.InvocationEvent.dispatch (InvocationEvent.java:178) at java.awt.EventQueue.dispatchEvent(EventQueue.java:443) at java.awt.EventDispatchThread.pumpOneEventForHierarchy (EventDispatchThread.java:191) at java.awt.EventDispatchThread.pumpEventsForHierarchy (EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:138) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:130) at java.awt.EventDispatchThread.run (EventDispatchThread.java:98) ******************** I have the j2eelib.jar, which contains EJBMPropertyEditorSupport, mounted in my Filesystems tab. The superclass in question is there also and looks OK to me. I also deleted my userdata, which didn't help, and then I updated and rebuilt my path, but unfortunately the problem remains. I tried opening another form class that inherits from this same superclass and I get the same error (the other class I tried is com.sun.forte4j.j2ee.ejbmodule.editors.ContainerTransaction Editor). I can mount j2eelib and open the source for the superclass, EJBMPropertyEditorSupport (which is a JPanel), and it looks OK. I located another another form class that doesn't inherit from JPanel: com.sun.forte4j.j2ee.lib.editors.SecurityRoleMapEditor (it inherits from RefArrayEditor), and it gets the same exception when I try to open it. So, I believe there is a regression in the trunk codeline open source, with opening a java form class that does Not inherit from JPanel.
Form editor needs to create an instance of the superclass to show it in the designer. So the superclass should always be a JavaBean and should not be abstract. If it is not possible, form editor tries to use some other superclass and shows the warning... But your case seem to be even more problematic. EJBMPropertyEditorSupport is not a visual component (I guess it extends java.beans.PropertyEditorSupport) which looks strange to me. Isn't the form you intend to design an innerclass in XMLSerializationClassesEditor? Then you should separate it to a standalone class, form editor is not able to handle innerclass forms... (see issue 19155). I can give you more info/advice if interested. (You may see also issue 27186.)
There must be a procedure for closing a bug that reports a regression. And whatever that is, I suspect that procedure was not followed here, because, if we can't fix the problem, we at least we have to provide the customer a description of a workaround.
We could discuss if this is regression or not, but it does not make much sense to me... I can give you more details about possible fix (or warkaround). It should be easy, as I tried to write already above: 1st step: Move the innerclass XMLSerializationClassesPanel (representing the form) from XMLSerializationClassesEditor to a standalone class (and rename the .form file accordingly). Form editor is not able to handle innerclass forms. 2nd step: Change the class the XMLSerializationClassesPanel extends to a non-abstract class (the JPanelWithTable superclass used now is abstract, so make it non-abstract, or create one more class in between). Form editor tries to create an instance of the class the form class extends, it expects it is a JavaBean. These steps applies to all similar cases... Does it work for you?
I consider it a regression when code that worked fine in an earlier release suddenly stops working correctly in a new release. In this case we have several netbeans form classes that used to work fine, but they no longer work correctly in the trunk codeline. Now, when we try to edit these forms, the error shown above is displayed; and note that this error did not happen in version 3.3 and earlier (some of these forms were built in netbeans version 2). As I'm sure you know, making a change to Netbeans which breaks existing customer code, no matter how obscure we think it is, is a serious change to make, and I think that is what has happened (possibly accidentally) in this case. In general, I believe that non-backward-compatible changes need to be discussed at length, and possibly even approved by the P-team. Thank you for the suggestions for how to change my code, but I would prefer to modify my existing code, and I don't think I should have to (and neither should customers who may have similar forms). I would prefer to see this regression fixed, if possible, so all forms built in earlier versions of netbeans will continue to work in the latest release, unless we make a conscious decision to break backward compatibility for this case. Possibly compatibility can be maintained by making certain simplifying assumptions about form classes which contain the form as an inner class, and/or have a superclass that is abstract. All we need to do is maintain behavior that is similar to what we supported in 3.3.
I don't consider this a regression, because innerclass forms were never supposed to be used or told to be supported. There's no way how you could create an innerclass form (or a form extending some abstract class) using form editor. Doing this by changing the form in source editor additionally - like moving the generated code to innerclass, changing the declared superclass to some incompatible class than the form was created on, etc. are not documented and not supported. The fact it worked somehow sooner is rather by accident. We had no idea someone could create forms this way, so we did not preserve this "functionality". Now it is hardly possible to go back and not to screw up the new things (i.e. general bean forms). But hopefully not quite impossible, I'll try to hack it somehow (together with issue 27186). BTW NetBeans 3.3 behaves the same way, the only difference is that it just prints a warning to console, NB 3.4 shows it in a dialog. Anyway, this is just a warning, you can work with the form as usual, no data should be lost.
I've made a fix, seems working to me... There should be no error messages, just a warning in console and ide.log with detailed information. Could you verify it? (Should be available in dev build 20030114 and later.)
*** Issue 19185 has been marked as a duplicate of this issue. ***
Verified