This week's giveaway is in the Spring forum.
We're giving away four copies of REST with Spring (video course) and have Eugen Paraschiv on-line!
See this thread for details.
The moose likes Swing / AWT / SWT and the fly likes How to organize a Swing project Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of REST with Spring (video course) this week in the Spring forum!
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "How to organize a Swing project" Watch "How to organize a Swing project" New topic

How to organize a Swing project

Hunter McMillen
Ranch Hand

Joined: Mar 13, 2009
Posts: 492

Hi everyone,

I am not that familiar with Swing or GUIs in Java, to fix that I have created a project for myself to help learn swing etc. I am running into the issue where I am getting more and more code; but I dont really know how I should organize Swing projects. Right now I have separated the creation of the user interface, and the event handler from the main program file, and this is my current package structure.

package structure:

I was wondering if organizing the way I am is a good idea or is there a better way? I am especially curious about how to separate the EventHandler from the main file because once I moved it out of the main file it stopped registering my events. I am still working on that.

any input would be great.

"If the facts don't fit the theory, get new facts" --Albert Einstein
Stephan van Hulst

Joined: Sep 20, 2010
Posts: 4221

Hi Hunter,

Usually, I don't put my GUI classes in separate packages, unless a particular component becomes very big.

I usually have a structure like this:

-> model/business logic

-> GUI components, event handlers, helper classes

-> extra classes belonging to MyComponent, MyComponent resides in the project/view package.
Only when MyComponent is very complex, otherwise they go in the view package as well.

This was inspired mostly by the way Swing organizes its classes. Take JTree or JFileChooser for example. They have a separate package for extra classes.
I only separate my event handlers from the class they belong to when they are general enough to be used by other classes as well. If the event handlers perform very specific operations relating to some component, best not to separate them.

The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.
Hunter McMillen
Ranch Hand

Joined: Mar 13, 2009
Posts: 492

cool thank you for your quick reply. I also have a couple more questions I hope that is ok.

1) Right now my main class file is listener for many of the events that occur within my program (since i integrated the event handler back into it), I was wondering if this was bad style.

2) I have a JMenuBar with menus on it, and each item in the menus corresponds to a method in my program, how do you general group those functions into classes? a class like FileMenuOperations seemed weird to me.

Stephan van Hulst

Joined: Sep 20, 2010
Posts: 4221

Always use a separate listener per action. Anonymous ActionListeners are great! For typical actions that a user can perform (usually in the form of menu items or tool bar buttons) I like to extend AbstractAction instead.
I agree. Here's the link:
subject: How to organize a Swing project
It's not a secret anymore!