Modular Java == Buildable Java
I started out today with a simple goal; “Let’s build OpenJDK for OMAP this morning.” I said to myself. So I begin with a fresh build tree, pulling in the build recipes bit by bit. I start to see unresolved depencency issues. “No problem, I know where to get that.” I mutter under my breath. Then I hit another, and another. “Rhino? Really?!” I mutter as my mood darkens. “SNOBOL-native?!”* In fact over an hour later and I’m still in this dependency hell. Since it’s not the most interesting work, my brain had time to wonder why this problem exists. “It’s because Java is one big monolithic bowl of jello.” my internal voice spoke up. I don’t even like jello. Yes, of course this is why there are so many dependencies. The dark side of having so much functionality in the run-time is so much complexity and tight coupling in the build-time. “What could possibly be the solution?” I wondered again…
“Java Modularity!” Of course, it’s so simple! If the JDK was broken up into semantic chunks, the build-time complexity could be greatly reduced if you only have to build what you need. “But does a simple Java build really matter?” I pondered. After all, only a select unlucky few ever have to actually build the damn thing. Most of us just install binary packages and get on with it. Well, I have no metrics, and cannot be sure, but it seems to me that a big cost of build complexity is adoption and inclusion of Java in other open source projects. If I am a distro maintainer (or a machine maintainer), or I have a project that depends on JDK, and the build is difficult or breaks often, I may move on to greener pastures. Complexity is risk and cost. So, a simple, sane, and universal Java build system would put more jvms on more machines, distros, and platforms. This is a worthy goal! I really hope the latest push for Java modularity makes some traction in OpenJDK sources soon!
* Haha, I kid!