Like last year, in my Agile Architecture - Technologies and Patterns session at SpringOne2GX,
I asked the attendees the same three questions surrounding class,
package, and module design. This year, I had roughly 80 folks attend
the session, and here is the rough breakdown of the hands shown after
each of the questions.

How many spend time designing classes, both the behavior of a class and the relationships between classes? About 80% of attendees raised their hands.

How many spend time designing packages, both the behavior of a package and the relationship between packages? Roughly 20% raised their hands.

How many spend time designing JAR files, both the behavior of a JAR and the relationship between JAR files? Again, about 20% raised their hands.

These are consistent responses to what I see elsewhere, as well. I
was hopeful that since I was attending the Spring conference, a few
more developers were leveraging OSGi
and actually spending some time on module design. But that doesn’t look
to be the case. Maybe modularity isn’t sexy enough? I suppose that’s
just a bit more fodder for the argument that there is no migration path for modularity, and that we need better tools, tutorials, and educational materials
to help us design modular software. Fact is, I had more than one person
stop to ask me where they can find more information. And that’s why
recently, I’ve been focusing my talks on what we can do today, right now, to design more modular software.

I know we’ll be there someday. After my OOPSLA tutorial this week, Alex Buckley stopped by and we chatted for a while on modularity in JDK 7. Whether it’s Jigsaw, OSGi,
or both, we can’t be sure. But one thing is certain - modularity is
coming to the Java platform, and while it might not be all that cool
and exciting right now, it’s going to play a significant role in how we
architect and design applications going forward.