Last night a feature request landed at 5 PM. The kind that sounds small during standup and turns into a mini rewrite after dinner. Our Swing app had grown into a ball of listeners and wizards. Adding one more screen felt like threading a cable through a crowded server rack. I stared at a whiteboard that looked like spaghetti, opened NetBeans 7.1, and tried a different path: migrate the feature to the NetBeans Platform. By midnight I had a window, action, menu item, settings storage, and an update to roll out on Monday. No heroics. No duct tape. Just a platform that treats desktop apps like first class citizens.
Why the NetBeans Platform clicked for this project
NetBeans 7.1 dropped last month with fresh JavaFX support, but the quiet star for me is still the Rich Client Platform. If you have a Swing app that keeps getting new screens and tools, the NetBeans Platform gives you a spine: a modular application framework, a window system, consistent actions and menus, and a built in update center. It is Swing all the way, so no rewrite. You keep your look and feel choices and your libraries. You just stop fighting the plumbing.
Technical middle: how to build rich clients on the NetBeans Platform
Modules and dependencies. You split your app into modules. Each module declares what it needs and what it exposes. NetBeans checks this at compile time and at runtime. No more mystery classpath bugs from a lost jar. You can keep using Ant or move to Maven since the Platform ships with ready project templates for both.
Lookup and services. The Platform uses a simple pattern for discovery called Lookup. Think of it as a loose way to find services without wiring everything by hand. You register a service, someone else looks it up, both sides stay decoupled. It feels like dependency injection without a heavy container.
Window System and TopComponents. Screens are TopComponents. They dock, float, save state, and reopen where the user left them. You add actions that show or focus your component and the Platform wires the menu and toolbar. Drag to rearrange panes, store the layout, call it a day. This is the part that saves the most time when the app grows.
Nodes and Explorer views. If your app shows trees, tables, or lists that represent real stuff like files, customers, or devices, the Nodes API gives you a model that connects data to UI. Explorer views render Nodes with selection, context menus, and actions already in place. You focus on the model and behavior, not on hooking yet another JTree to yet another right click menu.
Virtual FileSystem. The Platform has a virtual layer that looks like a file system but can come from jars, memory, or disk. You use it to store settings, templates, and configuration. It also drives the System FileSystem where modules register menus, toolbars, and keymaps. Reading that layer is faster than hunting for config files by path.
Autoupdate and branding. Build an Update Center, publish modules, push fixes without full installers. The branding step lets you turn the Platform into your product with your splash screen, name, and help set. No need to fork the framework.
Interop with plain Swing. You do not throw away your JFrame based screens on day one. Wrap them as TopComponents or migrate feature by feature. The Platform does not force OSGi. If you already live in OSGi land or Eclipse RCP, different story. For pure Swing teams, the NetBeans Platform fits like a jacket that was already your size.
Managerial perspective: why this helps deliver faster
- Predictable structure. New features land as modules with clear boundaries. Easier reviews. Easier testing. Less side effects.
- Shorter onboarding. Any Java dev who knows Swing can follow the Platform concepts in a week. The APIs are consistent and the official tutorials are solid.
- Built in UX patterns. Window docking, wizards, actions, and keymaps are consistent across the app. Your team spends time on features, not on trivial UI wiring.
- Safe updates. The Update Center keeps users current without desktop visits. You can stage a beta channel for field testers and roll back if a module misbehaves.
- Tooling that sticks. NetBeans IDE understands the Platform deeply. Refactors keep module dependencies in check. Maven support is mature. CI works with headless builds.
- Risk control. The Platform is open source under Oracle’s stewardship and widely used for tools, GIS, medical, and control room apps. You can audit the code and step into the source when a bug shows up.
If you are comparing to web based front ends, remember this is for teams that need a desktop rich client with tight device access, heavy data grids, or offline work. If your use case fits the browser, go web. When it does not, the NetBeans Platform cuts through a lot of ceremony you would otherwise rebuild.
Your challenge for the week
Pick one sticky feature in your current Swing app. The one that keeps breaking menus and window state. Create a new NetBeans Platform Application in NetBeans 7.1, add a module, and move that feature in. Wire one action, one TopComponent, and one service via Lookup. Add a branded splash and publish it from a local Update Center. Timebox it to a day.
When you are done, ask two questions: did the NetBeans Platform remove glue code, and did the team spend less time on plumbing? If the answer is yes, you just found a path to grow a real rich client application without the pain that usually trails Swing as it ages.
If you try this, tell me where it tripped you up or where it surprised you. I will share the best tips in a follow up and link sample projects that match common app shapes like data explorer, editor heavy tools, and dashboard driven consoles.