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.
The upcoming changes in the form module in the area of new layout design support require a new external library to be added to NetBeans. This library contains a new layout manager and several related classes. It will be used by the form editor and also added as a library to user projects (will be needed to execute the created forms). The library is developed by Sun as a project on java.net under SwingLabs project (https://swinglabs.dev.java.net/). It has not been published yet (planned for JavaOne). I can provide complete project sources for interested reviewers. In NetBeans the library will be placed in the IDE cluster in modules/ext, in cvs as form/release/modules/ext/ as can be already seen on the form_new_layout branch. The name of the library jar file is 'swing-layout.jar'. The library in NetBeans will be named as "Swing Layout Extensions". The placement, installation, usage, etc is quite analogical to AbsoluteLayout library.
When the library is added to dev trunk (together with the new layout design support functionality) it will be used only if the new layout design is enabled via a cmd line switch - so just for "experimental purposes". So it won't be available by default. Before we make it official (i.e. without the switch) we will create a module for the library so it is also usable for modules within the IDE. By then we expect the project to be announced on java.net, and also that the library will be distributed as a JAR file with the version number included in the file name. This all will happen before feature freeze and we will do another review for it.
Created attachment 22343 [details] diff
Asking for review.
<localizing-bundle>org/netbeans/modules/form/resources/Bundle</localizing-bundle> should be <localizing-bundle>org.netbeans.modules.form.resources.Bundle</localizing-bundle> (as per ResourceBundle.getBundle etc.). I suppose that the actual java.net project which hosts this is not publicly visible yet. What will be the licensing terms for the binary JAR when it is released? Will be distribute sources as well, or just link to java.net for that? What backward compatibility goals do the developers of this library have? Since it is not generally available yet, I assume only a handful of people have tried to use it in real products, so it is conceivable there are significant oversights in its API design that would need to be corrected after more experience is gained with it. If we expose it as a lib for our users, what risk is there that there will be incompatible changes made after (1) we make it available in NB dev builds, (2) our next official NB release? If there are such incompatible changes, could the form editor itself quietly upgrade user forms to use the new API, or would there be more serious problems? My guess is that since this is just a "pure" support library (LayoutManager2 impl), strict b/w compat is enforceable, and any major redesign would be done by introducing a new parallel LM2 impl - but we should get confirmation about this. (Sorry to be picky here, but incompatibilities that break user projects are much more serious than incompatibilities that break third-party modules, so we need to think about the risks carefully.) Does the form module itself (form.jar) statically refer to swing-layout.jar? Or only user form classes? The patch implies that the former is true (since it is added as a Class-Path extension). BTW preparing a patch to arch.xml might be a good idea; you will need to do it sooner or later anyway.
> I suppose that the actual java.net project which hosts this is not > publicly visible yet. What will be the licensing terms for the binary > JAR when it is released? Will be distribute sources as well, or just > link to java.net for that? It is going to be LGPL. I suppose we will not distribute the sources (just link to java.net). We will just include javadoc. As for the backward compatibility, I agree it is extremely important. In the current state the layout extension API is not final yet. And there is more API than just LayoutManager2. We expect it will be tuned before announcing. During this period it is possible some incompatible change is introduced. That's one of the reasons why we plan to have the new form functionality available only on a switch. We will discouradge people from using it for real work. We also plan to mark the forms created in the experimental phase so they will not open in the offical version (i.e. without the switch). This all should happen before (our) feature freeze - we expect the layout API is reasonably done by then allowing to evolve compatible way. The good news is that this is a Sun project tailored for us so we have good control over it. And the backward compatibility is of high priority for us. Even if the layout APIs changed incompatibly we shuld be able to upgrade quietly the existing forms as the layout data is stored in form file representing a model that is independent on the APIs that construct the resulting UI. The only concern then would be that the users might code against the layout library manually. In the case we needed (1) to do a major change and (2) to preserve user written code we would create a new library (new layout manager implementation). But we believe this won't be necessary. > Does the form module itself (form.jar) statically refer to swing-layout.jar? > Or only user form classes? The patch implies that the former is true (since > it is added as a Class-Path extension). Yes, form module uses this library. > BTW preparing a patch to arch.xml might be a good idea; you will need to do > it sooner or later anyway. Good point. I'll do that. Thanks for comments.
Closing this - together with issue 62497.