HomeI 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!
Loading recent content...
Post Comments
Add Your Comment!
any one please tell me how to insert a datetime valuve in to ms sql 2005 using java se...the format needed for input is yyyy-MM-dd HH:mm:ss.SSS..
Hi Alex,
Yes, for Java application modularity OSGi works quite well. We use Concierge on BUG to expose modular hardware sensors as OSGi services. But, using FOSS JVMs in open source products has a relatively high cost and complexity due to the monolithic nature of the JVM and the self-referential nature of the build system. Ideally I'd like a core JVM (x86, ARM) and CDC-foundation-esq classpath with robust, open ways of adding components and features.
cheers
ken
We've been doing modular Java with OSGi for the last ten years. Yes, it's something important to focus on, but in reality Jigsaw is only sufficient for modularity within the JDK itself; it's not something that's going to lend itself to other systems. Granted, if you want to lock yourself down to a proprietary (albeit open source) JVM, then Jigsaw could be the way to go - but if you really want modular Java that will be write once, run anywhere, then OSGi is the only enterprise-ready solution.
» Comments RSS