Unresolved issues, Hans's swan song
- From: Hans Muller <Hans.Muller@...>
- To: users@..., jsr-296-eg@...
- Subject: Unresolved issues, Hans's swan song
- Date: Wed, 07 May 2008 15:01:15 -0700
- Mailing-list: contact users-help@...; run by ezmlm
After nearly 21 years, I'm leaving Sun Microsystems. I'm moving
to Adobe, to work on Flex, starting Monday May 12th. Although I
will not be carrying on in my role as spec lead for JSR-296 I am
working with my colleagues in the Java Client Group to make sure that
someone qualified picks up the torch.
As I'd mentioned in mid-March, I have not been able to devote much
time to the project for quite a while and I apologize for leaving
before the getting the last set of issues and bugs sorted out.
In addition to the bugs and RFEs listed in the issue tracker, there
are several major design questions that remain unresolved that I'd
like to get into the record. Many of these have been brought up
before and I don't think all of them have to be completely resolved
before the JSR enters public draft status.
* Support for additional application types
Currently, the framework implementation only provides explicit support
for an application with one main JFrame which defines the
application's lifetime. Secondary windows and dialogs can come and go
in a SingleFrameApplication but when the main frame is closed, the
application exits. Similarly, when the application's main frame
is iconified, all of the secondary windows are hidden.
Several additional application types should be supported. Here
are sketches of what I'd had in mind. More refinement is needed.
Similar to SingleFrameApplication except that the application can
create more than one main frame. The application exits when the last
visible main Frame is closed.
- ServiceApplication (aka "tray application")
An application whose lifetime is unrelated to the frames it creates.
On Windows, applications like this often display an icon in the system
tray. The icon can provide a context menu and its dynamic appearance
can communicate application status.
An application deployed as an Applet. In this case the application's
lifetime is defined by the lifetime of the JApplet. Applets add two
additional lifecycle states that aren't supported by the Application
base class, start and stop, which might be recast as "pause" and
* The Application singleton is problematic.
It's very useful to give application modules access to
application-specific resources, actions, tasks, and GUI elements.
Doing so neccesarily introduces a dependency and the approach we've
taken is to provide a static Application singleton. A singleton is
easy to understand and imposes little on the design of the framework's
elements, and works nicely enough in small applications. On the other
hand, its nagging presence has some drawbacks:
- It complicates independent component development.
If you're developing application parts that might be incorporated in
application framework apps, then you have to decide how you'll deal
with any dependence on the singleton. This ends of being part of a
set of decisions one has to make about how much the parts should
depend on the application framework's types.
- Multiple applications per JVM are very difficult
Since the singleton is static, only application "containers" - like
the Java (applet) Plugin - that create a different classloader for
each application can support running more than one application
framework app in the same JVM.
- It complicates unit testing
Unit tests that depend on the Application singleton being launched,
initialized, and started, are difficult to write (for example
* Support for customizing the services provided by ApplicationContext
Sophisticated applications sometimes want to be able to extend or
reconfigure the ApplicationContext, e.g. to add a new service or to
replace an existing one. This is a tricky substitution to make
because if it's not done before the Application singleton is
constructed, then some of the application may capture references to
the old ApplicationContext object (presently the Application
constructor creates its ApplicationContext instance). The original
plan for enabling ApplicationContext customization was to use
java.util.ServiceLoader.load() to create the ApplicationContext
* Task should have-a SwingWorker rather than being a subclass.
The primary motivation for this implementation change is to simplify
supporting application framework ports to pre-Java6 JDKs. Presently
the prototype implementation bundles the 1.5 backport of SwingWorker
). This jar file must be
present at runtime. It would be preferable to rewrite the Task class
so that swingworker.jar would only be needed at runtime when