Soviet-era JCP needs change, concedes top commissar
Time to tear down this wall
Just over six months into the job, Java Community Process chairman Patrick Curran has reached a firm conclusion on his organization: "We have to change," he said. "No more smoke-filled rooms."
The context for Curran's comments was the recent QCon event, where Spring framework father Rod Johnson had just likened the JCP to a commissar in Soviet Russia. "The Politburo knows what's best for the proletariat, and the Politburo meets in the form of JCP expert groups," he said.
His point was that, historically, the JCP has standardized too many things. "When you try to standardize everything you end up with a degree of thought control where there is a failure to critically evaluate technologies."
Johnson did not condemn all the JCP's standards as bad. He mentioned the Java language itself, the Servlet API, the Java Transaction API and Java Message Service as examples that have been "extremely beneficial".
When it came to Entity Beans, though, he was withering. "The Entity Bean technology somehow ignored every piece of prior art, with the result that you had two generations of completely failed technology," he said. "The cause of object-relational mapping probably lost at least six years because of that, and [it caused] billions of dollars of wasted development."
Quietly spoken Curran said he's aware the JCP is dominated by the creators of Java technology, not the developers using it, and seemed determined to steer the JCP towards a more transparent and inclusive process. "Sometimes what we're producing is not what you need," he said.
"The only way to fix that is to have more involvement of end-user companies in the JCP. They are seriously under represented."
Other problems are a perception that things happen behind closed doors, the legal agreement that you need to sign to participate, and the unfriendly JCP web site.
"The spec leads are encouraged to maintain a web page and to create a public mailing list. Many of them do not do this," he said, something he promised to change.
Despite his harsh words, Johnson said he believes the JCP is changing for the better, particularly with Sun Microsystems' renewed commitment to open source, and even came to its defense. "It's not fair to sit back and say: 'Sun should fix the JCP'. Community engagement doesn't work unless the community engages," he said.
Nice to see they admit that EJBs are excerement.
I wonder when they will admit that ordinary "beans" are c***p as well. A bit of jiggery pokery with naming conventions allowing getLost() and setUp() to return the value of public variable Lost or set the value of public variable Up in the absense of an expicit method would have acheived the same effect without requiring millions of lines of useless code.
The biggest mistake
Log4J was already established as the best logging framework when JSR-47 came round, but the JCP said "not invented here" and had to come up with their own (crap) version. Result? No one, but no one, uses java.util.logging, while log4j is the first jar file I add to any new project.
Even when Apache asked very nicely for them to modify JSR-47 so that log4j could become the default provider, they said piss off - despite the fact that several other JSRs issued revised versions as a result of feedback from the community (JMS 1.1 did away with P2P and P/S domains, for example).
If the JCP wants to change, and wants to show that they have changed, the first thing they should do is throw away java.util.logging and incorporate log4j into the JDK (or at least provide an SPI so that log4j can be the default provider).
they should start with the basics,
Choose one implementation of Exceptions, Runtime or Declarative
Add in .Net style property declarations.
and then they can start on the impossible, try and teach new developers to question the JVM and not blindly belive that it's a gift from god that will never fail.