Someone just sent me a mail linking JSR 316. A JSR that will specify Java Enterprise Edition 6, the successor of Java EE 5, which was defined in JSR 244.Now before we take a look, lets just investigate some recent trends in the Enterprise computing world. Hmm, BEA moved their micro Service Architecture on top of OSGi, IBM Websphere 6.1 seems to have chosen OSGi, Jonas is an EE framework build on OSGi from day one, and the JBoss Microcontainer is modified to support OSGi. On top of that, we have one product that made many people re-think Java EE: Spring. Now this product fell in love with OSGi. The market clearly says one size does not fit all. One would expect that these trends have some influence on Java EE 6? Sigh, think again.
To address the problem that one size does not fit all, Sun proposes to create a few more sizes, called profiles. Surely that should fit all? Well, profiles have been tried in J2ME (for Sun people working in JEE, this is the other leg of the JCP standards department focused on constraining environments) and they failed in my opinion. Profiles require specifications and specifications are expensive to produce. Therefore, there will always be a push to minimize the number of profiles. However, in real life, no profile will be perfect for a specific application because the demands differ so much. So profiles cost a lot but still make most people unhappy because it is likely not a perfect fit.
There is a very simple solution to the problem of a limited set of profiles: componentization. Instead of gluing a number of Java APIs together and calling it a profile, we need to allow the developers to exactly choose the components they need. Let the developer make their own profiles! Wow, isn't that a great concept?
What would we need for this? Well, we would need a component framework that allows the management of these components. Preferably dynamic so that we do not have to restart the server all the time while developing or running business critical applications. We would also need a model where the components could collaborate without requiring singletons with their nasty side effects. Does such a component framework exists? Yes, it is called OSGi/JSR 291. Does JSR 316 refer to OSGi/JSR 291?
Nope.
JSR 316 only mentions JSR 277 in the specification request, in a rather indirect way. They basically say that 277 is coming and they'll defer any decisions until it is there. Seems fair because 277 is older and more mature than 291 looking at their numbers? Well, except for the fact that 277 is still in draft review and 291 is already final because 291 could be based on the very mature specification that originated in 1999 and has gone through 4 major revisions. So there must be another reason why JSR 291 is not mentioned? Maybe 277 will provide features that JSR 291 does not have? Hmm, not really. Looking at the JSR 277 specification request one can not claim that the ambition level is high in comparison to JSR 291/OSGi: no dynamics, no class space consistency, no unloading, no package imports, etc. Their early draft was still on a rather simplistic level. The only real addition over 291 is the repository and there are many loose ends. JSR 277 recently opened up the mailing list, taking a look at the discussions it seems that they are still struggling with some of the basics of modularity. However, fortunately, the JSR 277 expert group has promised to make the 277 module system interoperate with JSR 291/OSGi. That makes choosing OSGi risk free as well as providing the additional benefit of running today on a wide range of VMs (from 1.2 to 6, also in embedded devices), unlike JSR 277 that will only run on Java 7 when it comes out late 2008. So why should JSR 316 wait? The perfect solution exists today and is promised by JSR 277 to be compatible with tomorrow?
In a context free society basing JSR 316 on OSGi/JSR 291 would be an absolute no-brainer. I can not think of one rational argument why JSR 316 would not choose OSGi today so we can get the advantage in Jave EE 6. Can you?
Peter Kriens
Hy,
ReplyDeleteI've been following this blog for a long time. I like module systems (like OSGi) and I program all day under one (the one from NetBeans).
Basically as an outsider to these specs, I have to say the OSGi looks like a /technologically/ nice thing but with a lot of /corporate/ twist.
If I look at JSR 277 I see it will be part of Java 7, which will be open source and the RI/TCK will be delivered with Java 7. Simple enough.
If I look at JSR 291 I see something that will be licensed to all interested parties but with $50.000 / 3yr RI licence and $50.000 /3yr TCK licence. On the JRS 291 download page I see a PDF which only grants the licence in order to give "review / feedback" permissions (huh?). This doesn't look like something I would like to use in an upcoming open-source (GPL I think ?) product.
JSR 316 targets explicitly Java 6+ so it seems normal to target the module system that will come with JSR 277. By your logic, if they would choose JRS 291, then they might as well cancel JSR 277 altogether, no ?
I read on some slides from JavaOne that JSR 277 will have some special support for other module systems (OSGi specifically) so I have the feeling you might still get what you want. Just not in such a straight-forward 100% OSGi way.
Full disclosure: I'm a member of the NetBeans Dream Team.
Peter, I can understand your frustration, but I prefer your blog when you talk about classloading problems and other fun stuffs going on in OSGi.
ReplyDeleteHere it is all "deja vu"... Come on get over it and use your energy to spread the good word about OSGi, and let the community decide which technology is best.
I forgot one thing, you should have mentionned the modularization work going on in Harmony.
ReplyDeleteThe Java EE reference implementation is Glassfish. I think a great way to increase interest would be to make the Glassfish v3 a bundle. May be even make a Grizzly bundle for the HTTP Service instead of Jetty.
ReplyDelete