Updating and Autoloading Modules sounds like something only the platform team would love. Truth is, if you are shipping on the NetBeans Platform, it is your daily bread. With NetBeans 6 and its shiny Plugin Manager, the whole story got more approachable, but the ideas have been around for a while.
This is a practical walkthrough from someone who keeps breaking apps so you do not have to. Short bursts, plain language, and a few traps to avoid when you push updates to users backstage.
Why should you care about autoload at all
Because startup time and stability live there. An autoload module is a quiet helper. It stays off until another module needs it. If that need goes away, it slips back off. No dialog. No drama.
Think of libraries, pure APIs, and glue that has no UI. Those are perfect autoload candidates. Your toolbar gadget or window system addon is not. Keep user facing bits explicit.
What exactly flips an autoload module on
Dependencies do. When a regular module declares a dependency on another module or a token, the platform enables the autoload provider to satisfy that need. No need for the user to tick a box.
You can express needs with module dependencies or with tokens using provides and requires. Tokens are handy when the name of a concrete module should not leak into your API story.
Where do updates come from in a real app
From an Update Center catalog. It is a simple XML sitting on your site. The Plugin Manager reads it, lists what is new in Available or Updates, and downloads NBMs as needed. It respects the proxy settings from Options, which matters behind office firewalls.
For an RCP product, ship your own catalog URL in Settings and point it to your server. You can host it on plain HTTP. Keep the catalog tidy with clear categories so the list is not a jumble.
How should I version my modules for smooth updates
Two fields run the show. The code name base is the identity. Do not change it unless you want pain. The specification version is the contract. Bump it when you add or change exposed behavior.
The update client compares specification versions to decide if something is newer. Keep this number moving forward in every release. If you break compatibility in an API, raise the number and update dependents to match.
Should I split API and implementation
Yes. Keep a small API module with few public packages. Put the rest in an implementation module. Make the API autoload so it turns on only when someone calls it. Keep implementation regular or eager depending on behavior.
Restrict what you publish. Use the public packages setting to export only what others should see. If you really must share private bits across a few modules, use friend packages. Try not to though.
What is the deal with eager modules
An eager module enables itself when its dependencies are there. No user click. It is a nice fit for automatic registries, background listeners, or glue that responds when an API appears.
Mix eager with tokens and you get a clean switch. Provide a token from a core feature, have an eager module require it, and watch it wake only when that feature is present.
How do I keep startup fast while adding features
Use layers and Lookup to register services. Avoid heavy work in installers. Keep classes lazy to load. Push optional features to separate modules and make them autoload or eager instead of always on.
Measure. The platform can show a startup time log. If a module adds a second on boot, fix that before you ship. Users forgive an update, they do not forgive a slow morning.
When do I need a restart after an update
Most module updates will ask for a restart. Classes and UI registrations live long. If you updated only branding files or docs you may sneak by, but plan for a restart in your messaging and release notes.
Keep updates small and grouped by feature. Users are happier restarting once after five fixes than five times after one each.
What about clusters and packaging
Put your app modules in your own cluster, not in the platform ones. That way your updates do not step on the platform and vice versa. Keep third party libraries in a dedicated cluster too so you can bump them without touching core features.
Ship NBMs through the catalog, and for full installers use the same clusters. Consistency saves you when you debug an update gone wrong on a customer machine.
How do I make updates feel safe to users
Sign your NBMs. The Plugin Manager shows the signer and users feel better clicking Install when your name is there. Write clear module descriptions and release notes. Put your support link right in the description field.
Use friendly names and a clean display category. People search by what they remember, not by your internal code.
What are the common foot guns
Changing the code name base mid flight. Forgetting to bump the specification version. Exporting every package just to make a deadline. All of these come back later and bite.
Another classic is mixing UI with autoload. If the module shows a window or a toolbar, keep it regular so users can enable or disable it on purpose. No surprises.
What is the quick checklist before publishing
Set code name base and keep it. Raise specification version. Limit public packages. Choose autoload for libraries and APIs. Use eager for glue. Put user facing features in regular modules with a clear category and description.
Test updates from the catalog URL on a clean user dir. Verify proxy and restart flow. Read the log. If it looks boring, you did great.
Bottom line Keep your modules small, your contracts clear, and your updates steady. Autoload and the Plugin Manager do the heavy lifting when you set them up with care. Ship often, keep users in control, and your NetBeans Platform app will feel light even as it grows.