Mirko Jahn

Subscribe to Mirko Jahn: eMailAlertsEmail Alerts
Get Mirko Jahn: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Blog Feed Post

Componentization wars part II - Guerrilla tactics

Usually when I am blogging, I am talking about the latest technology, standards or general trends. This time however, I wonna talk about politics. No, not about the elections in US, but about politics in software development practiced by the big players to achieve their business goals. Don’t get me wrong from the start. I think this is completely normal in general. We all are trying to achieve our goals the one way or the other, but something just doesn’t feel right…

Yesterday I read about the latest news concerning Sun’s plans about the future of JSR 277, JSR 294 and its new plans on inventing componentization for its JVM called Jigsaw. I hate to say it, but for me, it seems like Sun behaves like a small child trying to insist to be the one driving all development and not letting someone else play with its toys. It’s anything but the behavior of a well establish and industry leading company or one who wants to become one. First they completely ignored the problem of componentization in Java while persuing enterprise development with J(2)EE and missed their chance to actually set the foundation for real software reuse what you would expect from and enterprise ready language specification. Later, when OSGi began to rise they started the JSR 277 and tried to create a competing standard in secret, which didn’t work out too well as we all know. Now, because of the pressure of the community and the lack of showing a better solution they are abandoning the JSR and start developing their own “internal” componentization approach with the Jigsaw project. Of course they are claiming it is not intended to be used outside their own use case for componentizing the JVM, but it is hard for me to believe this. Call me paranoid, but for me it sounds much more like an attempt to develop another system, which after completion is suddenly moved into an official standard. Sun’s statement that they are going to revive JSR 294 and are inviting even the OSGi Alliance to participate to work on it feels more like a distraction so that Sun is able to pursue its plans with Jigsaw in private that without public notice they suddenly can come up with a self made de-facto standard. Again, I might be to paranoid, but it just doesn’t feel right. Is all that just a coincident? I don’t think so. Why can’t they embrace the work done already and see it as a great chance to propel their Language and create a true reusable software stack, no other vendor can offer? Hal Hildebrand just blogged about Sun’s attempt to introduce this new project and the way they are trying to persuade big industry players about their great intents… Well, you should really read his post about it and please tell me, if they have such humble goals, why does everyone they consult have to sign a NDA? I strongly believe that if those ideas are so great, why not share them and let the community decide and participate?

To wrap things up, I ask all of you who feel like me, share you’re opinion! Comment on Hal’s post, blog about it, link to it, spread the word. I believe we - as a community - have to stand up and say what we think to show Sun, that those kind of guerrilla tactics, especially when so easily to look through are not working. Keep your eyes open and don’t fall for the dark side ;-)

Cheers,
Mirko

Share/Save/Bookmark

Read the original blog entry...

More Stories By Mirko Jahn

Mirko Jahn worked for several years as an independent software consultant and tutor before joining the Unstructured Information Management Architecture (UIMA) group at IBM Research. At present, his major research areas cover component-based development strategies, component repositories, and migration approaches toward modular applications, along with service-oriented architecture. Mr. Jahn is heavily involved in making use of OSGi component-based developement
standards in UIMA.