The interweb is no longer safe. I just unsuspectingly surfed across The Worst Thing Ever and now I have to go pull out my eyeballs with a rusty corkscrew.

Just remember: DO NOT BE FOOLED BY IMITATIONS!

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.

This is a digital message-in-a-bottle to any Kicking Giant fans who may be googling around the web.

Years ago, my copy of Secrete Teenage Summer was destroyed in the Great Sone Cadillac Fire of '95. By then the tape was completely OOP and soon became impossible to find. None of my friends have a copy. I can't find it anywhere.

These were some of my favorite songs of the early nineties, and it's now been ten years since I heard them. Summer is almost here again and for somewhy I really want to hear them again. Someone out there must have ripped it into mp3s...

Sony has announced that it is going to put up a service to allow Everquest players to sell in-game items for real cash money.

This is 180 degrees from the policy of most other MMORPGs, which expressly forbid that sort of thing. It has the potential to ruin the virtual economy and alienate players who aren't willing to fork over extra cash to get that +5 Vorpal Sword of the Bunny or whatever.

It will be interesting to see if this is successful (i.e. if it doesn't ruin the game). If so, maybe we'll see a new business model for these things: the game and the subscription are free, and the host company makes money by running a mini-EBay for virtual items.

OMG I think I'm going to die. I'm stting here minding my own business at my favorite neighborhood cafe in SF. Now this woman sits down at the next table wearing an insane amount of perfume.

Ladies, this is not ok. If I can smell you without invading your personal space, you're wearing too much. There oughtta be a law.

I've been thinking a lot about modularity lately. Specifically: what can you do to ensure that a large, evolving Java codebase is written and maintained in a modular way? Despite having just turned 10 years old, Java still hasn't provided a good answer.

There certainly are many tools and techniques for identifying poorly-modularized Java code, but precious few that help you write modular code in the first place. By the time you have to bust out JDepend and Refactoring, you're already pretty much screwed. What I want are some practical guidelines on how to get modularity from the outset.

The key word in that sentence, of course, is 'practical'. For me, this means that modularity

• is achieved using only standard tools
• requires little or no special effort to maintain
• does not unduly inconvenience developers
• is easily understood

These things are important because the kinds of projects where modularity is most needed (i.e., big ones) are also the projects where complicated rules are most difficult to enforce. If you need to get 300 people to each do something exactly right, it had better be pretty simple.

This simplicity is elusive because Java has no builtin constructs for describing modularity. As soon as you need to define a modular unit that is broader than an individual class or package, you're on your own as far as the JLS is concerned.

A well-designed build system can pick up some of the slack here by ensuring that modules get compiled independently. Unfortunately, there currently are no standard patterns here - the design of modular Java code is better-understood than the design of modular Java builds. Similarly, jar files can help enforce modularity at runtime, but they still fall short a few places, mainly in that they provide no way to restrict afferent (inbound) dependencies.

So, the question I'm wrestling with is how to take a set of imperfect tools and achieve some useful level of modular separation. I really don't think this issue gets enough attention. It's fairly easy to find abstract theories that use a lot of UML to describe the ideals of modularity; however, there are very few practical ideas floating around on how to achieve it in a large Java codebase in the real world.

I have a few thoughts about this that I'm going to blog about soon, but I'd love to hear of any other ideas in the meantime.