Allen Holub has written an opinion piece which discusses the juxtaposition of Sun open-sourcing Solaris, and some of the JCP standards. The article is obviously looking to provoke.

In the news we have Sun open-sourcing Solaris—a robust, tested, nonstandard technology—possibly setting a standard by doing so (a good thing). We also have Sun cobbling together a committee to wrest control of persistence away from open-source standards like Hibernate (a bad thing). I could support welcoming Hibernate into the JCP, but creating yet another competing technology is divisive and (I hope) an effort doomed to failure. The last thing we need is another bad standard.

Opinion: Do We Really Need the JCP?

The real issue with JCP is that it fits an already existing market with already existing needs. Solaris did fit an already existing (yes, it was dying but it still existed) market with several needs and customers (I cannot believe how many Solaris servers I've seen around where I work...).

OpenSolaris is the biggest and widest testing ground for opensourcing software at Sun Microsystems, and it is (in my own opinion) the last testing ground that opensource software needs to pass before becoming THE standard.

OpenSolaris will become OSS but it is doing so only after having shed blood and tears, after having drawn criticisms ("why didn't you opensource it before, clowns!") and doubts.

What would have happened if Sun opensourced Java instead?
In my opinion it could have been worse, far worse than opensourcing Solaris.

Sun is striving to becoming an OpenSource Framework Provider AND a Business Services Oriented company. If Solaris manages to do it, in my opinion sometimes in the future we will have an Opensource / OSI compliant version of Java... with all the good features, and all the bad features that will come out of it (re-read the BileBlog for a good point of view on the limits of OpenSource software...).

On the other hand, I feel that JCP will be needed even in then to preserve the trademark and compatibility with standards, that's just to avoid the baseline Java becoming too "banchi" accepting every one-liner written by a random Joe Programmer out there.

Of course this is only my own personal unrequested opinion :)

OpenSolaris is the biggest and widest testing ground for opensourcing software at Sun Microsystems, and it is (in my own opinion) the last testing ground that opensource software needs to pass before becoming THE standard.

OpenSolaris is a red herring and unrelated to the concept of OSS Java. In fact, OpenSolaris is the exact example of why Sun is wary of OSS Java.

OpenSolaris is a proprietary implementation and platform that implements several standards, but offers several features on its own. The whole thing that OpenSolaris is becoming is the exact thing that Sun does not want to happen to Java.

OpenSolaris will include a Linux compatability layer (Janus) to facilitate porting, but otherwise to run on OpenSolaris, there are certainly large chunks of source code that will not build on OpenSolaris because of "Linuxisms" in the code.

Just as there will be code and applications built on OpenSolaris that won't run on Linux.

Sun does not want, if it can possibly help it, that situation to exist in Java and the JVM. That was the prime complaint against Microsoft.

That's why it relies on the things like the JCP, to keep getting input from vendors and to help ensure that a JVM vendor doesn't get off the path and does their own Java.

Fragmenting the UNIX industry is what gave a company like Microsoft the ability to rise up and dominate the market. Much like some suggest the lack of a desktop standard is keeping Linux down on the desktop.

People have a love/hate relationship with choice. On the one hand choice is great: options, freedoms, variety. On the other it's very risky: which one is better, this has A, B, C while that one has B, C, D. There are some who love Baskin and Robins 31 flavors, but I still get Vanilla when I'm there (French Vanilla, actually...).

When people choose Java, Sun wants that choice to be simple. Java. Period. Not Suns Java vs IBMs Java. Having competing implementations actually shrinks the market place for Java. If I have to choose between different JVMs, well, why not start looking at something else, like .NET, or Perl, or whatever. Perl, Python, Ruby is very similar to Sun Java, IBM Java, Gnu Java. Because on the surface they're all bullet point compatible, but it's the details that matter.

Having a single Java makes Java a safer choice for companies. It's why I chose Java many years ago. Not because of Sun, but because of Sun, IBM, Oracle, BEA, etc. etc. It had community buzz and corporate buzz. The only group who hadn't jumped on the bandwagon was Microsoft. All of those options makes Java a safe choice. Fragment Java, and it loses that safety.

OpenSolaris is already in a fragmented world, so one more won't hurt it. Solaris is trying to compete against a free competitor, so making it OpenSolaris is viable tactic to maintain and grow marketshare. Lot less risk with OpenSolaris.

But OSS Java, and risk it forking and fragmenting, and having a major vendor participate, and something "safe" like .NET looks all that much more appealing.

The JCP's not trying to necessarily take valid working standards and warp them just for the sake of ... the JCP. The JCP represents a broader user base than just the original author group, and has a public mechanism (more than "this works and people seem to like it") for validation.

"Hibernate is the standard persistence mechanism" seems biased, too. When I look at what people are using and what they say they're using, I find that straight JDBC is very common, comparable to Hibernate usage - and so is DAO. This statement - "Here's the winner!" - invalidates much of the rest of his essay.

His ranting against EJB also smells like a "everyone thinks this" rant. EJB was overused; blaming EJB for its misuse is like saying "I used a dinner plate as a tire, and IT BROKE! DARN THOSE PLATES!" To be sure, Sun could have (and should have) done a better job of propagating use cases, but consider what EJB was: a better version of IBM's San Francisco. (If you're a SF advocate, please don't kill me.)

He then goes on to talk about message-driven beans being an attempt by the EJB people to keep themselves relevant, which is sort of the last nail in his coffin-lid. God forbid we should have deployable mechanisms.

I'm sorry, but having Holub use EJBs to decry the JCP just sounds retarded by the time you reach the end.

Lot of people have a problem with SUN.

So maybe do not use SUN's stuff and go somewhere else. Maybe to MS ...

SUN is responsible to it's shareholders, not to you ...

EJB criticism is so common in last days. It starts to be boring ...

Glad I am not the only person who finds this constant assumption that somehow EJBs are hard to write and work with kind of depressing.

I actually think EJB is a very good example of why we need the JCP. Trying to define an open standard that was flexible enough for the various web servers, application servers, database servers and CTM's was a pretty tall order. I have no doubt that no-one wanted to sacrifice their architecture for the common good and so on. Yet EJB came out and was adopted by vendors from almost every field and by Java developers almost everywhere. The reason it took off like a rocket when it first emerged in 1998 wasn't because Sun was really good at politics or marketing (it was pretty lousy at both), it was because it was such a huge leap forward from trying to build high-performance mission critical systems when compared to using DCOM, CORBA or indeed Java RMI. But it needed co-operation from the major players in transaction processing (IBM, Oracle, BEA, NEC and the like) to work, and the JCP enabled that to happen.

The truth is whether you're using COM+ or EJB to do it, building large scale, highly available distributed systems remains hard. The 3rd major release of EJB is on the drawing bard and people from the open source community (though the JCP) have been heavily involved in the design of it. Hopefully it will further lower the bar for people trying to build complex systems by getting rid of a lot of the (rather tedious) boilerplate type code you need to write for an EJB. But the real point is no one has a better solution to this yet. Blaming EJB for business failures is just dumb – If you need to use it learn how to use the technology for goodness sake, its really not that difficult. If you don't need to use it or don't like it use something like Hibernate or Toplink or whatever.

Its easy to say "the JCP is too slow" or "the JCP is broken" and it would be great if the process could be sped up in some way, but there is very little point in throwing away something which is working (all be it not as fast as you would like) unless you have a good idea about how to improve it. One thing I think would be a benefit would be if (just occasionally) Sun would simply adopt something direct from the Open Source community around Java. Examples? Well LOG4J, Struts and JfreeChart all spring to mind as things which could be adopted wholesale as part of J2EE/J2SE.

One thing I think would be a benefit would be if (just occasionally) Sun would simply adopt something direct from the Open Source community around Java. Examples? Well LOG4J, Struts and JfreeChart all spring to mind as things which could be adopted wholesale as part of J2EE/J2SE.

This sounds like a wonderful idea. I am in this camp too, but I don't know how you can adopt something like struts and let the developers who have been maintaining it continue to maintain it. You would have to get a snapshot of it and call it the standard, then what? Anything that the struts community chooses to change is no longer the standard. Open source works as a product because it is not a standard. I don't see how you can get past that part of it, but it is a wonderful idea.

Time and again we see this dicussion crop up.. sometimes with different groups of people... sometimes the same! :-) I guess the concept of "open source" has gathered enough momentum and support of relevant individuals by now, that we will see this happen more and more for any "standards" driven tool/toolset implementation. But I agree with people who say that Java standards can never be properly governed without a central community driven body! I guess the people who are talking about doing away with JCP are actually talking about some issues with JCP that need to be corrected rather than eliminating JCP altogether. Changes can definitely be made to both expedite the JCP work and also make it more better (leaner and less meaner?)! So let those thoughts flow!
Regards,
KR

In some cases, I think access to the RI would be great. This way, those of us who use bleeding edge stuff before the official release can fix bugs and move on with work. I don't mind bugs in the RI while it's actively being developed, but for god sake, let me fix a bug if I find one. Otherwise, I have to find a work around, when fixing the bug is a better solution.

But it needed co-operation from the major players in transaction processing (IBM, Oracle, BEA, NEC and the like) to work, and the JCP enabled that to happen.

This is the key point that many seem to be missing.

In the .NET camp, you have Microsoft and its "standards". Microsoft doesn't have a similar process to support different vendors because it simply doesn't need one due to its dominance in the market. Whatever MS says, goes. Plus it has the advantage of being able to merge the application server tier with its core OS. If they feel that their .NET system needs access to the OS kernel to run better, they have that option.

Recall that Back In The Day, there were several "application servers" on the market, notably Borland and BEA as well as others, but save for CORBA, you were pretty well locked in to the vendor for your application.

If Java is to do well, it needs to have vendor support. Sun can edict all it wants from On High, but if the vendors don't implement Suns edicts, then you have no standard at all, just another spec/implementation of a competing technology.

JCP gives vendors (among others) input into and a stake in the standards being produced. It lets them work in options that make it easier to port their existing applications and infrastructure to the new standards when they come out (think of the various caveats etc. with JMS for example).

It also give the standards less of an ivory tower "here's how things should work in a perfect world" flavor because it is being forged by folks who have implemented these things in the past.

Finally, it also enables vendors who can work towards a published spec rather than creating out of whole cloth. Witness the OSS projects that implement the JCP standards. The standards give them a large "TO DO" list that they can review and check off.

The JCP gives the market a better chance at learning and evolving as it moves forward because it takes consensus from a broad base.

Quite frankly, if you don't like what commercial companies are offering, use OSS. Given the maturity of OSS middleware today, the are plenty of choices. If you really think the JCP is broken, than get involved and fix it. If you think it's hopeless, than ignore it.

Crying about JCP without getting off your butt is easy. How about get off the seat and do some work. All the people in the community working on specs spend a lot of time and effort, so lets give credit to those individuals. No process is perfect. How about describe concrete steps for improving the JCP process. I love to bitch as much as the next guy, but that doesn't mean it should be published as an article.

+1

Very well said Peter.

actually i dislike the way things going in the java community....
jcp is very lenthy process(yes it takes a long time to produce a standard) first it propose an idea then it provide an early draft followed by several revisionsthen voting then provide the final version then provide the TCK then approve the RI and finally allow vendors toimplement their impl.,this simply may take years to give the developers a technology and accordingly supposed to produce something near perfect as it take all that time from the EXPERT GROUP to finish BUT look at what we have.... any spec they provide is not usable in its first release,and getting better by revisions till it become usable in third or forth release as the community use it and provide feed back
So why we need such experts when the real improvement come from the community not from the expert group

for example
EJB1.1 the worst technology ever and partially usable at the stage of 2.1 as all of us know that CMP is not practical solution but a performance killer and doesnot support basic OO concepts as inheritance

JSF1.0,1.1 not mature enough although there is older and better solutions in the opensource world, it does not even provide interoperability with existing solutions from jcp itself as jsp and jstl(as if and forEach tags) and need a non standard bridge to work in jsr168 portlet container and the worst,it does not support flexible templating framwork such as tiles or sitemesh and does not provide alternative

JDO 1: although it provide good abstractions such as object life cycle it does not provide by itself a good solution for persistance and users used to depend on vendor extensions and the first revision doesn't provide anything new and finally and after about 2 years it become usable in version2

servlets and jsp: several revisions has been made to allow them to be really used by web developers, that take about 4-5 years

and many more , while in opensource world a very short cycle happens, the ideas is being developed and mentained by the actual developers who really needs it and know the market requirements

so why the JCP and why they called Expert groups?!!!!

I only follow a dozen or so specs, but the ones that I do follow, the people in the JSR actually have experience. Rarely do the individuals involved in writing the spec have zero experience. having said that, everyone participating in the JSR comes from a different perspective and coming to an agreement isn't easy. It's not like developers magically create great standards out of thin air. The projects that succeed and rise to the top take time and require a ton of experience. so let's not kid ourselves with assumptions like developers know better than the people participating in the JSR. In many cases, the guys participating in JSR have much more experience and know the pitfalls of simplistic solutions. Making a spec simple and flexible isn't easy or remotely close to being easy.

The best way to fix the problem is to get involved. The JCP could change how it works to make it easier for developers to contribute ideas and get feedback. for example, when JAXB 1.0 was in beta, I discovered a bug and wanted to fix it. Since the RI source code wasn't available, I couldn't go in and fix it. In the meantime, I tried to work around the bug, but it would have been better for me if I could just fix the bug and be done with it. In comparison, when I discovered a bug in Castor, I simply posted a bug entry and provided a patch. I didn't have to wait 3-5 months for the JSR team to fix the RI and go through the lengthy process of releasing jaxb 1.0. Obviously there are licensing issues related to opening up the RI source code, but something can be done to make it easier to contribute.

Having worked in a company that "does standards" (and oversees them).

There is one simple truth, all the kids that come along to the party have one goal in mind...

"How do I modify the standard to be as close to my implementation as possible"

The JCP is no exception. Change == cost so the less change you have for making your implementation "compliant" then the less cost, simple as that. Issues of "best solution" don't really apply...

The process to get a standard created is (for everyone and every standard) painful and difficult and brings out the worst in everyone. Frankly I'm suprised there are standards at all. And when you get Sun and Microsoft around the same table...

We also have Sun cobbling together a committee to wrest control of persistence away from open-source standards like Hibernate (a bad thing). I could support welcoming Hibernate into the JCP, but creating yet another competing technology is divisive and (I hope) an effort doomed to failure. The last thing we need is another bad standard.

Hibernate is not a standard. It's a high-quality, widely used open-source product, but it is not a standard.

Competition is good. Having more than one supplier implementing an API is good, as this encourages continuously improving quality of products. It is certainly not divisive - but wishing doom on competition certainly is.

From the article:

Even now that JDO 2.0 has played catch-up, why should I go with a JDO Hibernate clone whose APIs are essentially untested in real applications

JDO has played catch-up in some ways, but has been in advance in others (fetch groups, support for non-relational stores). As for JDO being essentially untested - this is blatant nonsense. JDO has been used in many mission-critical high-performance applications.

"I don’t buy the “if they knew what they were doing, they wouldn’t do that” argument. Well-thought-out technology doesn’t let you hang yourself in this way."

I have yet to see technology invented that could not be used to hang yourself no matter how well thought out it was.

Also blaming the technology choices for a companies failure sounds to me like sour grapes. In most cases generally the blame for a companies failure lied with the CEO's who had no business plan, inexperienced architects who wanted to do the coolest technology (I worked with a lot of those) and VC's who had more money than sense.

This article to me smells of jumping on the band wagon with out much real thought.

Hmmm, let me see.

Servlets, JDBC, JMS, JNDI, JAX*, RMI, JavaMail, JMX, JTA/JTS, ...

Sure looks relevant to me.

Yes we do but it would be great if Java was open source. One thing I dont understand that SUN is say putting in a CVS tree is hassel... well let others do it for you. Another thing all the linux desktops can be Java enabled similar to MAC OSX

so we have a more even playing field?
.V