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]
Asking for review.
(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.