Jive Community Forums


  JavadesktopFAQ JavadesktopWIKI JavadesktopBLOG JavadesktopPROJECTS JavadesktopHOME javadotnet javadesktopFORUMS javadesktopARTICLES

JDesktop Network Components

by Amy Fowler
June 22, 2004

More For Less

Over the years, we have consistently heard feedback about building desktop clients for the Java™ platform ("Java clients") that can be summed up in just one word: simplify. Skilled developers have been able to create all kinds of rich, responsive applications with the Java platform, however developers with less time to invest are often thwarted by the size and complexity of the interfaces they need to master. This situation is not peculiar to the Java platform; all of the platforms that provide comprehensive support for building desktop applications — such as GNOME, KDE, and Mac OS X — are necessarily complicated. However, what some of them have, and what the Java platform lacks, is a shortcut for developers who are building applications that match a small number of common archetypes. Database and web service front ends, forms-based workflow applications, and simple chart/graph information visualization clients are good examples of these common archetypes.

Thus, we have initiated a new open source project on javadesktop.org, JDesktop Network Components (JDNC), which aims to provide the shortcuts required to construct these sorts of desktop applications in significantly less time by reducing the learning, design, and coding requirements. Additionally, JDNC has a specific goal to make these shortcuts accessible to a broader developer base. This ambition has led us to develop a high-level XML markup language for JDNC that makes the richness of the Java client platform, previously accessible primarily to developers comfortable with the Java language, amenable to markup developers as well! The goal to make Java desktop client development accessible to a wider audience is also driving our focus to make JDNC a natural companion for development tools, which is a critical requirement.

This article provides an overview of the problem space and technology, and closes with our plea that you get involved to help shape it:

Data-Centric, Enterprise Desktop Clients

Although applications rarely fit neatly into a cookie-cutter mold, we've found that many of the applications which enterprise developers need to build share a common cross-section of functionality. In developing JDNC, we are creating shortcuts for these common features so that developers can get applications up very quickly and then easily enhance them over time. Central to these "shortcuts" is a suite of very high level user-interface (UI) components which leverage Swing, but provide common functionality in a simpler JavaBeans™ component API. Although these components are indeed the project's namesake, they are only part of the solution.

The most central feature shared by what we call "data-centric, enterprise desktop clients" is connecting users with data — loading it, viewing it, filtering it, editing it, validating it, saving it, and so on. And these days that data is usually tied to a network data source, such as an SQL database, HTTP servlet, or WebService, bringing with it the complexity of networking. JDNC does the heavy lifting here, by providing built-in support for dealing with these network data sources, including multithreaded support (so the UI doesn't block during network operations) and incremental loading — hence, the "Network" in "JDesktop Network Components".

The application model for a data-centric enterprise client boils down to the life cycle of its data. JDNC promotes this notion by supporting the pattern of clearly separating the data from the UI, but making it very easy to bind the two together. Application data is encapsulated in one or more client-side, UI-independent data models, such as a JDBC RowSet or a JavaBeans component. The data-model interface should be easy to understand and easily configurable from tools, with simple properties to configure its data source, metadata, edit constraints, validation logic, etc., and simple actions for common operations such as load, insert, modify, cache locally (for off-line use), and update (back to server). The UI components are then bound to that local data model (or models) with a simple syntax. From a tool the binding might be created by drawing a line between graphical representations of the two objects. The connection between the UI and the local data model is handled by JDNC's binding mechanism, which automatically handles input validation, type conversion, pushing and pulling values to/from the model, and reporting errors to the user. This frees the developer to focus on their data and how it should be presented in the UI, rather than on the plumbing which glues the two together.

And once a Java client, running on a memory/CPU-rich machine, has its hold on that local data model, there is all the power offered by the rich UI components and Java 2D™ API in viewing, manipulating, and editing that data, usually without any additional round trips to the server.

As JDNC is a work in progress, we have not yet implemented all the functionality required to realize this vision. For example, support for disconnected RowSets (JSR 114) will be included in the release following 0.5. However, 0.5 does include an experimental version of a data-binding framework for Swing components which, being central to our purpose, should evolve substantially over the course of the project. You can view JDNC's Feature Summary for detailed information about current and planned features.

JDNC's Layered Approach

As we were coding JDNC, we quickly realized that if we carefully layered the technology, we could offer simplification not only to enterprise desktop client developers, but to Swing programmers in general. Many of the features we were building into the large-grained components (table sorting and filtering, forms and data binding, etc.) are also quite useful to someone who's using Swing's flexibility to construct a custom client which might not fit one of JDNC's target archetypes. Thus, we've carved JDNC into three distinct layers, as shown as the colored boxes in the image below:

While the upper layers have dependencies on the lower layers, you may choose to use JDNC at the layer which best fits your needs and skill set. If you're a Swing developer looking for a richer table component, then you might choose to use only the Swing Extensions. If you're a developer familiar with the Java language but not the Swing API, then you should find that the higher level JDNC API simplifies your effort in constructing a basic Java UI. And if you prefer the declarative style of XML, then the JDNC markup language is the place to start. Let's peek at these layers from bottom to top.

Swing Extensions

The Swing Extensions package includes extensions to the Swing API for the common features required by JDNC. These APIs have been designed to be congruous with Swing and can be used in any Swing application, but the components are lower level than the components in the JDNC API layer. Some of these features may be candidates for a future J2SE release. Below are some of the key packages currently in this project:

Swing Extensions Package Description
org.jdesktop.swing Contains API and extended Swing components which provide common functionality required by data-centric, enterprise client applications, such as JXTable, JTreeTable.
org.jdesktop.swing.actions Contains classes related to the JDNC actions framework.
org.jdesktop.swing.binding Contains API which enables Swing UI components to be easily bound to data models, such as a JavaBeans component or RowSet.
org.jdesktop.swing.data Contains API used to process data in a client application, including data models and adapters, metadata, validation, and type conversion.
org.jdesktop.swing.decorator Contains API used to implement coordinated sorting, filtering, and highlighting of the extended Swing cell-rendering component classes such as JXTable and JTreeTable.
org.jdesktop.swing.form Contains the JForm component, which enables easy
creation of user-interface forms which bind to arbitrary data models, such as a JavaBeans component or RowSet.
org.jdesktop.swing.table Contains API required by the extended JXTable component.
org.jdesktop.swing.treetable Contains API required by the JTreeTable component.

This package set will evolve as you help us develop JDNC, so please see the Swing Extensions javadoc for the most current package info.


The JDNC API layer contains the high level UI components which wrap the Swing Extensions layer to make common use cases easier to construct. These components are intended to follow the JavaBeans component patterns whenever possible, so they should be usable within existing tools, such as NetBeans. These components will provide attractive default visuals, usability features, and data binding out of the box so that a developers can get professional results quickly. These components are contained in the org.jdesktop.jdnc package. The initial suite contains:

  • JNTable: scrollable view on tabular data (wraps JXTable)
  • JNTreeTable: scrollable outline view on hierarchical data with columns (wraps JTreeTable)
  • JNForm: container for view/editing of arbitrary data (wraps JForm and uses binding framework)
  • JNEditor: scrollable, rich text editing component (wraps JXEditor)
  • JNTree: scrollable view on hierarchical data (wraps JXTree)

Admittedly this set is small and by no means includes all the high level components that developers need to construct end-to-end enterprise desktop clients. We have a long list of needed components (login panel, preference sheet, directory view, data-bound controls, etc.) and we look forward to expanding this list as you tell us (or contribute!) what needs to be there. Please see the JDNC API javadoc for the most current API info.

Note that these components wrap, rather than extend, their low-level Swing counterparts for a couple of reasons. First, we want their API to be simpler, which involves more selective exposure of the low-level component's properties and methods. Second, we want them to support scrolling and other layout features with minimal effort from the developer. These components should be easy for non-Swing developers to use, as they do not require knowledge of Swing design patterns, such as swing model interfaces, cell renderers, and the like. They offer less flexibility, but that's what makes them simpler to learn and use.

JDNC Markup Language

And last but not least we arrive at the highest level, the level that initially motivated this project: the JDNC markup language. The JDNC markup language provides an XML syntax for configuring rich, data-centric, enterprise clients that can be easily deployed either as a Java Web Start application, or as an applet within a browser. The JDNC schema allows markup developers to assemble clients which leverage the JDNC components and Swing extensions without having to first master the APIs or even object-oriented programming. While XML remains a hot technology, we've learned it's just as controversial, so let's address the common issues up front.

First, why XML? While it's true that, at least for us Java geeks, hand editing XML can be more painful than authoring code in the Java language ("Java code"), it offers a number of advantages that are particularly well-placed in the UI arena:

  • XML's declarative nature helps constrain the design problem; while one can spend untold hours pondering how to organize UI code, XML is basically a tree.
  • UI hierarchy is clearly exposed in XML, which isn't necessarily the case in code.
  • XML lends itself to generation and transformation, which means servers can deal with it.
  • XML tools exist today, such as schema guided editors and graphical viewers, therefore developers can be productive immediately

Is this comparable to XAML? No. JDNC's XML configuration language is geared towards expressing rich, data-centric enterprise clients (as described in previous section) in the simplest possible manner, and therefore the schema is intentionally limited. It does not include general tag support at the UI toolkit or graphics level and we are not recommending developers use JDNC's XML configuration for general purpose Swing development. There are existing toolkit-level XML dialects that can be used for this — eNode and SwingML to name a couple — which segues right to the next issue.

So why not use one of the many existing XML UI markup languages? In our goal to create significant shortcuts for a small set of common application archetypes, we consciously chose to define a markup language which was a level higher than the existing toolkit-level markup languages we were familiar with. Over time, we may find that many data-centric enterprise clients will require more fine-grained control of the UI than the JDNC schema offers, at which time we'll evaluate the options, as wheel reinvention is a waste of precious time. Additionally, the JDNC schema has been designed so that it can be mixed with other XML dialects (for example, SVG and XForms).

What about XForms? When we implemented JDNC's basic form functionality, we looked at leveraging the XForms specification. While XForms is a well-designed specification that solves the numerous deficiencies in HTML forms, we were not convinced it would provide the ease of development and short learning curve we were after. Additionally, implementing XForms is a significant task which did not fit into our target schedule for going open source. That said, we intend to revisit this topic and are open to the opinions of the development community, as we know lots of brain power went into that spec.

Can applications be built with JDNC markup and Java code? Yes! The markup and Java code approaches are not mutually exclusive and in fact we expect many applications will be constructed with the combination. For example, a developer might start out using the markup language to get the application up quickly, but incorporate business logic and behavior using Java code. This markup/code integration is something we need to enhance, going forward.

Deployment of Choice

JDNC is all Java code, therefore the three standard client deployment options are supported:

When using the JDNC markup language, the same JDNC XML markup file may be used in all three cases. JDNC provides the bootstrapping classes (org.jdesktop.jdnc.markup.runner.Application, org.jdesktop.jdnc.markup.runner.Applet) which interpret the XML file and realize its contents in the appropriate top-level UI container (JFrame for applications, JApplet for applets).

Community Evolution

As promised at the 2003 JavaOneSM conference, we have released JDNC as an open source project on javadesktop.org. This enables us to make the technology available to you early enough so that you can directly shape the vision, the feature set, and even the code. There is still a lot of work to do — the JDNC feature set is far from complete and there remain rough edges, especially in the API, which has not had extensive usage outside of unit testing and markup-driven use-cases. But, that is exactly why we need your involvement.

Join our forum or use our e-mail list to talk with us about what problems you're facing in creating rich, enterprise desktop clients. Tell us what you find useful and where you think we're off track. Work with us as we make the technology marry better with tools. File bugs and requests for enhancements. Submit code changes. Submit new components. We are anxious to engage directly with you to make Java desktop client development as productive and satisfying as we all know it can be.

Read or Post a Comment


About javadesktop.org and java.net

javadesktop.org is a java.net community for developers of applications with rich client interfaces. java.net is a Web site used by the developer community that expands the Java technology portfolio of applications, tools and services in applied areas of technology and vertical industry solutions. More than 52,000 developers worldwide have joined the java.net collaborative community, and are engaged in more than 900 projects ranging from Java technology-based games development to desktop technologies to enterprise development such as Java Web services. java.net is sponsored by Sun, the creator and leading advocate of Java technology, with editorial resources and technology infrastructure provided by CollabNet, Inc. and O'Reilly & Associates.