So, when I was last trying to write something serious, it was about writing modular code. Sam pointed out that I should define what I would want to achieve; here it is:

The benefits here are pretty widely understood and accepted. Code that is cleanly organized has fewer bugs and is more maintainable and can evolve much more easily to meet changing requirements.

I'm a firm believer in structuring code in a way that provides clues to how it should be used and what it means. Internal nasty bits should be hidden away in private modules, Public usable bits should be exposed in bright cheerful public modules. If you don't have clearly-defined modules, you have to rely on your users to read the documentation to understand what they should and shouldn't touch (and we all know how likely that is).

Another important byproduct of modularity is the ability to restrict access to a system's internals. This is particularly important in any sort of container, where the classloader needs to prevent rogue code from downcasting into implementation classes. It's certainly possible to write ClassLoaders and SecurityManager that do this, but it's not always easy, especially if you have lots of modules with complex relationships between them. It would be much easier if Java had a formal mechanism for declaring and enforcing restrictions on a module's afferent (inbound) dependencies.

This last one may be a pipe dream, but in theory it sure would be nice to have modular deployment. This allows for the possibility of end users installing or updating only specific modules as needed. This obviously needs to be done with care, especially in managing the QA matrices, but it's something that can be important in large-scale applications.