How do you make a Java desktop application modular? How should the modules be classified?
As a design goal, modularity means that you want to have an application composed of separate parts (modules) where each part has its area of responsibility and contains all classes concerned with that area (high cohesion), and communication between those parts happens through narrow, well-defined and -documented interfaces (loose coupling).
You achieve this by planning your design beforehand and adjusting those planse and refactoring the code constantly during implementation.
It's useful to make a difference between technical modules such as GUI, network communication or DB access (which often form layers, though these may be sub-divided into several modules), and domain modules that contain the application-specific logic and often don't form layers.
Have a look at OSGi technologies. Each module of your application (called a bundle) is a separate jar, and OSGi takes care of dependency resolution and dynamically loading bundle classpaths etc.
For desktop applications I would strongly recommend looking at DA-Launcher from www.dynamicjava.org. It makes deploying your app SOOO much easier. They also have a few things like dynamic JPA that are useful for any OSGi app.
You mean modular like Eclipse?
If you base your java desktop application on Eclipse RCP or NetBeans RCP, you'll get modularity "for free" (almost ;-))
The answer to Your question really depends on what did you mean by "modular".
There are several levels of concerns that you must consider when making your application modular.
First of all you must consider if the "modularity" you seek is architectural modlarity, deploymeyment time modularity or runtime modularity.
In any case every consecutive level implies all of the previous levels.
For starters - to make your application modular you have to start from architecture. Separate your concerns into well defined clean cut parts that have well defined interfaces to the "outside world". Use of good design patterns and dependency injection and designing for unit testability go a long way here towards achieving nice separation of concerns that is the bedrock of modular design.
Start from small but keep in mind the large picture. When designing a bit larger chunks (or modules) of your system make sure they have as few overlapping areas as possible. Every module should make almost no assumptions about the environment they run in and be serving only one single concern. Any services it requires from it's peers should be explicitly provided by external initialization (preferably using dependency injection for gluing the modules together into a working app).
If your architecture is modular, it is an easy task to separate the concerns into their own deployment units (in form of projects, jars, bundles, plug-ins, extensions or whatever) and you can start easily mixing and matching various modules during the deployment to get the exact feature set you need for the particular application instance. This is what I mean by deployment time modularity.
Going a long way towards enabling deployment time modularity are Dependency Injection frameworks like Guice, Spring framefork and others.
Runtime modularity the way I see this is something akin to the modularity provided by Eclipse and NetBeans plugins or Mozilla extensions where you can change the configuration and set of your application modules after the deployment/installation.
This implies some sort of architecture and infrastructure that recognizes new plug-ins/extensions either at application initialization time or dynamically at runtime.
Latter also means that all your modules must be build with implicit assumption that any service that a module uses can easily dissapear at any point in time, making the extra effort to ensure robustness of the code running in this volatile world.
I would also recommend Eclipse RCP or have a look at Netbeans RCP. The two are very similar. One thing that separates them is that Eclipse RCP uses native GUI libraries instead of Swing which Netbeans uses.
Pros and cons is that Elcipse might be a bit faster though you are more limited to the kind of controls the operating system offers. Netbeans uses Swing which might be more familiar to most Java developers and the ability to develop custom controls are endless.
Its been a while since I worked with Eclipse RCP so I'm probably wrong about developing custom controls in Eclipse RCP.
The thing they have in common is that developing smart and modular desktop apps is fun and you get professional looking apps in much less time!
You could also take a look at the Java Plug-in Framework,
JPF can greatly improve the modularity and extensibility of your Java systems and minimize support and maintenance costs.
have a try with Spring RCP
when organizing your GUI part of application...