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.
(Using 5.0 + the recent 5.0 form editor update) I have a form in a NetBeans module, which I designed while running JDK 6. I need this module to work on JDK 1.4 and 1.5. Tride changing source level, target JDK, running NB on a different JDK, but nothing helps - if you make the innocent mistake of designing a form while running on JDK 6, you are completely out of luck. This is a serious problem (and alas, one I predicted long ago). We cannot have NetBeans generating uncompilable code - especially uncompilable code in guarded blocks. The only fix is to either hand-edit the form file, or to redo your entire UI (and note that copy/paste between a form using javax.swing.GroupLayout and the org.jdesktop version is completely broken - all components are pasted in the upper left corner of the form). The right solution is to ship an add-on JAR for earlier JDKs, which uses the javax.swing package. Yes, I know there's some rule against that, but that rule needs to be fixed - it does not take into account that tools have to handle this problem). Then NB will simply upgrade any legacy code to javax.swing.GroupLayout. All of the alternatives to that approach are extremely ugly and will require asking strange questions of the users, etc.
> I have a form in a NetBeans module, which I designed while running JDK 6. > I need this module to work on JDK 1.4 and 1.5. Tride changing source level, > target JDK, running NB on a different JDK, but nothing helps - if you make > the innocent mistake of designing a form while running on JDK 6, you are > completely out of luck. No. There is a setting on the form (root node in Inspector) where you can set the layout code generation style. You only need to do it manually, it can hardly be done automatically. When you create a new form, this setting is set according to the global option which defaults to "auto", in which case the project platform boot classpath is checked for GroupLayout. Once the form is created, this setting is kept and not changed if you change the project platform or the global option. You must do it manually on the form if needed. (Regenerating all forms in the project automatically would be quite problematic.) We could of course have the default global option "use swing-layout library". But we want to preferentially generate standard code if the target platform permits it. We considered switching platform later to earlier versions as quite rare. > The right solution is to ship an add-on JAR for earlier JDKs, which uses > the javax.swing package. Yes, I know there's some rule against that, but > that rule needs to be fixed - it does not take into account that tools have > to handle this problem). Then NB will simply upgrade any legacy code > to javax.swing.GroupLayout. Besides we can't do this (I don't know how to fix the rule), it would be an incompatible change and would generate lots of changes in existing user forms. > All of the alternatives to that approach are extremely ugly and will require > asking strange questions of the users, etc. The current state allows the user keep using the library for eisting projects or older JDK while they can start using the standard code when they start using JDK 6. The only problem is that they need to find the setting if they want to go back from JDK 6. A admit the setting is not very discoverable... However I don't see other solution now.
This problem is still present in NetBeans 6.1 Beta, only that I cannot find a per-form setting to change the code generation. I also cannot find a means to regenerate the code after changing the global setting. This issue is biting me very hard on my Mac, when I try to revert projects from JDK 1.6 to JDK 1.5 to make them run with the latest officially available JDK on the Mac. I also have a very conservative employer where JDK 1.6 is not deployed to our 1000s of Windows desktops yet, so an easy way to make a project compatible with JDK 1.5 after it has accidentally been started on JDK 1.6 is very important.
> I cannot find a per-form setting to change the code generation Open the form and select the root node in the Inspector window. Now go to Properties window and change Layout Generation Style property to 'Swing Layout Extensions Library'. > I also cannot find a means to regenerate the code after changing the global setting. The global setting does not affect per-form settings of existing forms, it is just a default value for newly created forms. So, the regeneration does not solve anything. You must change the per-form settings.
OK, after reading the instructions slowly and carefully I finally realized that the Form is something different than the JDialog or JFrame that visually represents it and that clicking on the JDialog/JFrame and then opening the Code properties tab is not the way to influence the code generation for it. Your proposed solution worked for me, so from my perspective this has downgraded from a sorely missed feature bug to a usability problem. The Advanced setting for the default also does not make it clear in its wording that this is a default and does not do anything in retrospect. Again, this is more of a wording/intuitive usability issue than a problem with the feature (folks who have hundreds of forms might feel otherwise, but I am only speaking for myself).
Would be very very util if when you "downgrade" from 1.6 to 1.5 plataform (on Project Properties > Libraries > Java Plataform), netbeans shows a dialog asking if want to change the "Form layout generation" from all forms of the project to Swing Layout Extension. Change settings form-by-form is an expendable work, since it will always have to be done in a case like this one.
Would be very very useful if when you "downgrade" from 1.6 to 1.5 plataform (on Project Properties > Libraries > Java Plataform), netbeans shows a dialog asking if want to change the "Form layout generation" from all forms of the project to Swing Layout Extension. Change settings form-by-form is an expendable work, since it will always have to be done in a case like this one.
The need to use the org.jdesktop.layout version of the GroupLayout is close to zero these day. The manual way of changing the setting for individual forms seems quite sufficient.