Skip to main content

Issue 43: Moving swingx components into sub-packages

2 replies [Last post]
Mark Davidson
Joined: 2006-02-17

I would like to move forward on this so judging from some of the input from the forums as well as hallway discussions with some J2SE/Swing engineers, we will move the components into sub-packages. I think we would like to try this. If this is totally the wrong directions then we can always move it back.

The following is a summary of the discussion:


Move some of the larger components from the base package into the sub-packages.

For example, moving a component like say JXTable from

org.jdesktop.swing.JXTable to org.jdesktop.swing.table.JXTable.

-- Reduces package interdependency
-- Makes it easier reduce the size of the deployment bundle based on usage
-- Developers using a non-trivial component can look at the package (and
package doc) to get the whole story about using that component.
-- Encourages greater use of package private classes.

-- This is not how Swing currently does it.
-- Not scalable in the medium term. Small components placed in swing.*
today may need to be placed in* tomorrow


- Mark Davidson: easier to learn, easier to prune unused functionality, may lead to less exposed implementation details.
- Patrick Wright: Will make it easier to learn a system of functionality.
- Adrian Sutton: Agreement but caution against loosing flexiblity.
- Ronald Tetsuo Muira: Agreed but only for complex components.

- Joshua Marinacci: Main components should be in a common package for convenient class importing.
- Ramesh Gupta: May make api "break" in the long term as components which exist in the base package may migrate to the sub packages as they get more complex.

- Richard Bair: Is there guidance on package structures? A: Not that I could find.

In addition, I was talking to Amy and a couple of Swing engineers around here and there was agreement that we should give it a try. This project is fluid and a means to explore other ways of developing Java API. We can always move classes around. I'm sure that when (if) parts of JDNC make it into the Java platform there will be name changes, api changes and package changes once again.

We will move forward on this proposal.

Thanks for all your input.


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-07-15

Even if these are moved to the sub-packages, can there be a stub in the main package for backward compatibility and consistency with swing. Something like

package org.javadesktop.swing;

public class JXTable extends org.javadesktop.swing.table.JXTable {

Ronald Tetsuo Miura

Because the API is in its early stages (very unstable), there's no need to create those stubs (there's no legacy dependent code, because it hasn't been released yet). We're discussing this now, exactly to avoid the need to place this kind of hack into the final API like Jakarta Commons-Lang, that has both org.apache.commons.lang.math.NumberUtils and org.apache.commons.lang.NumberUtils for legacy compatibility.

Siva Dirisala wrote:
>Even if these are moved to the sub-packages, can
>there be a stub in the main package for backward
>compatibility and consistency with swing.
>Something like

To unsubscribe, e-mail:
For additional commands, e-mail: