eWeek writes that Jason Hunter, who was Apache's representative on the JCP Executive Council, said that the JCP actually stifles competition in some ways. "The JCP does not believe in free markets," Hunter said at TheServerSide Java Symposium on Friday.

Hunter, who has been Apache's representative to the Java Community Process Executive Committee, said he knows of "a lot of examples of JSRs [Java Specification Requests] being voted down because of competitive threats."
...
Hunter wondered if the JCP will continue to dictate the direction of Java technology, "or is open source going to dictate the direction?"

Read Open-Source Guru Says JCP Is Too Closed.

I'm afraid I don't see why one should question if open source should lead the way. It shouldn't. I think the market has shown that four million people can still be wrong, and the solutions of "open source" aren't necessarily the same as the solutions provided by J2EE.

It would be nice if the two dovetailed, but I don't see that happening - too many open source people see instant solutions as the holy grail, and that's imply not the case.

I'm afraid I don't see why one should question if open source should lead the way. It shouldn't. ... It would be nice if the two dovetailed, but I don't see that happening - too many open source people see instant solutions as the holy grail, and that's imply not the case.

I don't think any instant solution should become a standard. But that is what a lot of this EJB stuff is. Now that _IS_ bad!

I am sure a lot of this JCP stuff comes from real life experiments but the time has also shown otherwise. Why is that? Why not allow proven solutions to become standards, let the best rise to the top and work from there by addressing any additional concerns that might be left. It can be commercial or open source, whatever. I don't care.

I'm afraid I don't see why one should question if open source should lead the way. It shouldn't. ... It would be nice if the two dovetailed, but I don't see that happening - too many open source people see instant solutions as the holy grail, and that's imply not the case.

I don't think any instant solution should become a standard. But that is what a lot of this EJB stuff is. Now that _IS_ bad!I am sure a lot of this JCP stuff comes from real life experiments but the time has also shown otherwise. Why is that? Why not allow proven solutions to become standards, let the best rise to the top and work from there by addressing any additional concerns that might be left. It can be commercial or open source, whatever. I don't care.

Well, one reason for not standardizing over an existing product would be that this particular product would have a huge headstart over any competitor, and chance becoming a "monopoly".

Regards,
Henrique Steckelberg

Well, one reason for not standardizing over an existing product would be that this particular product would have a huge headstart over any competitor, and chance becoming a "monopoly".Regards,Henrique Steckelberg

Oh, nobody would allow that to happen for sure. I was not suggesting that but to take a look at the proven solutions and import the stuff from them. If there is only one solution worth looking at, there is no need to standardize anything.

eWeek writes that Jason Hunter, who was Apache's representative on the JCP Executive Council, said that the JCP actually stifles competition in some ways. "The JCP does not believe in free markets," Hunter said at TheServerSide Java Symposium on Friday.

Hunter, who has been Apache's representative to the Java Community Process Executive Committee, said he knows of "a lot of examples of JSRs [Java Specification Requests] being voted down because of competitive threats."...Hunter wondered if the JCP will continue to dictate the direction of Java technology, "or is open source going to dictate the direction?"

Read Open-Source Guru Says JCP Is Too Closed.

I've said before, open source to innovate, JCP to standardize. Standardization efforts should *not* be confused with innovation efforts. Specifications should not be a place to create new products, but rather a place to standardize on existing products in the industry. A specification committee is a poor place to try and innovate. The JCP should be a place where innovators in the industry meet up to agree on how to cooperate together through standardization.

The JCP is already represented by open source organizations like JBoss and Apache. I hope to see ObjectWeb and Eclipse on the EC in the future.

Bill

I share the concerns & tend to agree with Bill.
We've seen proof of that only one week ago: the entire JDO spec being hijacked by big vendors. Anyone there still doubting their true concers were "standardization" ? LOL.
The "C" in JCP should get much more weight (again). Otherwise it will loose all credibility at the user's base. It already has with this JDO ballot farce.

It also amazes me big vendors apparently don't realize they shoot themselves in the foot in te long term if they value their own profit over the global java profit. (do I hear JBoss, anyone?)
One of the core differences between .net & Java is -for me at least- choice, richness and community involvment. For me, that's makes me choose for Java.
Let's keep it that way!

One of the core differences between .net & Java is -for me at least- choice, richness and community involvment. For me, that's makes me choose for Java.

Is not .NET a choice? You even say blah blah "makes me choose for Java.

Without .NET you have fewer choices. Get a grip.

The JCP is already represented by open source organizations like JBoss and Apache. I hope to see ObjectWeb and Eclipse on the EC in the future.Bill

True, and it would be nice to see some more aspects of the market represented as well, such as the customers of the technology.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

eWeek writes that Jason Hunter, who was Apache's representative on the JCP Executive Council, said that the JCP actually stifles competition in some ways. "The JCP does not believe in free markets,"

The JCP is dominated by major Java product vendors - the companies that make the entire Java ecosystem work by sucking in billions of $$$ from their corporate customers. Without them, Java would not work commercially.

Why do they need to belive in free markets? The JCP is dominated by big CAPITALIST companies. I was talking to a VC a few weeks ago about business plans, and I was told that the business plan he wants to see is one where the DoJ may be investigating the company for their monopoly position.

Software product companies don't want fee markets, they want to be the next Microsoft.

A key propose of the JCP standardization process is to help commercialization. Innovation is not even a distant second place compared with commercial interests.

Did Jason not really understand what the first JDO 2.0 was about? He just needed to cross reference the J2EE licensee list with the NO voter list...

PJ Murray
CodeFutures Software
Java Code Generation for Data Persistence
http://www.codefutures.com


ps Please don't read this posting as anti-Apache or negative about the fine work Jason does. I recommend Apache projects all the time.

http://www.codefutures.com/weblog/corporate/archives/software_factories/index.html

Any examples of

"a lot of examples of JSRs [Java Specification Requests] being voted down because of competitive threats."

Any examples of"a lot of examples of JSRs [Java Specification Requests] being voted down because of competitive threats."

How about the most recent example?

The JDO 2.0 specification was initially rejected, damaging its market credibility.

It does not really matter too much that JDO was voted through on the second attempt. The damage is done.

It's politics. Often it's enough just to put an opponent on the defensive to win a political battle. The future of JDO is now not 100% certain - if it can be voted down once, it can be voted down again. Makes it a "brave" decision by a development manager to back a specification that is in "doubt". The sales approach is clear "Are YOU going to risk your reputation, your career?" This is the reality in the key market - the Fortune 1000 companies that are the economic engine of the major Java technology vendors.

All very clever by major vendors that voted down JDO 2.0

Don't be surprised if Sun now starts talking about changing the JDO licensing terms to an open source license. It would be another way to protect its core J2EE franchise.

Tough luck for the smaller ISVs (like CodeFutures) that invested time and effort in JDO support. That's the way the world works. Get over it.

PJ Murray
CodeFutures Software
Java Code Generation for Data Persistence
http://www.codefutures.com

The JDO 2.0 specification was initially rejected, damaging its market credibility.

I would argue that the strong multi-vendor and developer support expressed for JDO because of this rejection did exactly the opposite: it revealed the significant use of JDO. Read the comments of BEA regarding the revote: "After further review, BEA has concluded that there is a vibrant JDO community".

It does not really matter too much that JDO was voted through on the second attempt. The damage is done.

JDO would have continued (perhaps under another name) no matter what. The potential was for damage to the JCP.

Makes it a "brave" decision by a development manager to back a specification that is in "doubt".

This would have been the case if JDO 2.0 had been rejected. It was not. Such a rejection might have damaged the credibility of future JCP specifications.

Don't be surprised if Sun now starts talking about changing the JDO licensing terms to an open source license.

As I understand it the JCP has already changed to allow open source versions of JSRs. As an example, there are already open source compatible implementations of JDO 1.0.1. JPOX is going to be the RI for JDO 2.0, and it is open source.

So how might the JCP Executive vote when EJB 3.0 comes up for its first ballot?

So how might the JCP Executive vote when EJB 3.0 comes up for its first ballot?

Hmm... now what are you suggesting?

So how might the JCP Executive vote when EJB 3.0 comes up for its first ballot?

Hmm... now what are you suggesting?

The only formal mechanism for EC members to influence JSRs is through their vote and their associated comments at the various ballots along the way. Naturally there are many informal ways in which influence is exerted. I will view with interest the votes and comments which JSR-220 receives in due course.

Tough luck for the smaller ISVs (like CodeFutures) that invested time and effort in JDO support.

I felt that way until last night when I read Mr. Burke's "standalone persistance" post in another thread here. Then I confirmed his claim by reading Sun's open letter. Now I feel good about EJB-3 persistance. As far as I can tell, consumers and suppliers of JDO can easily migrate to EJB-3 persistance without having to adopt EJB-3.

As an existing JDO-related vendor you likely have a huge competitive advantage over entirely new entrants to EJB-3 persistance. The more I think about CodeFutures already having spread itself across both EJB-2 and JDO-1, the less I understand your whining about the consolidation of the two persistance architectures. Anyway, your product looks handy.

As far as I'm concerned EJB-3 persistance is JDO rebranded. The new marketing really confused me at first, since there's nothing enterprise (ie, J2EE) about EJB-3 persistance. So I read the literature (Burke knew I hadn't), and it seems very fair to us little folk.

As far as I'm concerned EJB-3 persistance is JDO rebranded. The new marketing really confused me at first, since there's nothing enterprise (ie, J2EE) about EJB-3 persistance.

Why JDO needs to be rebranded as EJB3 persistence to confuse you and many others on the first place?

The only reason I can think of is this, for Hibernate/Toplink to "standardise" their API (under EJB3 persistence) at the expense of other vendors and the community.

Do any of you remember JBoss JDO?

What happened to that? What happened to that 2 year old announcement? The story is that at the time, we were heavily recruiting the Hibernate guys to join JBoss Inc. When they joined, we had a rethink on the JDO strategy. The Hibernate guys disliked the JDO specification for technical reasons. YOu'll have to talk to them, but I think they disliked the overall one-size-fits-all persistence architecture. There are other less obvious technical arguments, so please ask the HB crowd because I wouldn't be able to articulate it well. So that was one strike against going the JDO route.

Another one, was the business side of things. If you research the JDO market, you get a different picture of how healthy it is. 2 of the top 3 JDO vendors are public companies. Go take a look at their revenues. Strike Two.

Another thing to look at is number of downloads and forum/email traffic. We compared these to Hibernate and Hibernate dwarfed them(put together) by far. You don't want to enter a market that is much tinier than your current base. We then compared Hibernate downloads/forum/email traffic to our own CMP imp and found the traffic/downloads to be comparable. (We used to sell standalone CMP docs so we had a good solid comparison point). Strike Three, you're out!

Also remember, that the Oracle/Toplink guys had the same decision point. You'll have to ask them, but I bet they went through a similar exercise. Ask yourself this: Why would the top two POJO persistence solutions go the EJB 3.0 route? I think it boils down to (besides technical arguments) that there is a much better chance of adoption of our POJO persistence solution going the EJB 3.0 route and attaching to J2EE.

If you went to the EJB 3 BOF at JavaOne last year where Robin Roos tried to hijack our session, you would have heard customers like Goldman Sachs demand a clarification on the direction of persistence and that dual competing specifications were bad for Java.

All these arguments is why we take the position on promoting EJB3 and unifying the specifications. I know many of you think we do things just to piss people off, but, at least in this case, we thought things through before we decided on the EJB 3.0 route.

What I find *really* disturbing about the whole JDO/EJB3 debate is that the TSS Cause of the Month Club and the Bitter Bloggers are so quick to try and tear down the JCP. Proved to me how short thinking people can be sometimes.

Bill

Bill,

it is rather difficult to understand how there could be such relevant technical arguments against JDO as much as to demand creating a entirely new persistence spec, and then have JDO vendors provide BOTH JDO and EJB3 persistence APIs with the SAME IMPLEMENTATION supporting both behind them! If there were really big technical discrepancies between both APIs, I don't think this would be achievable in the first place! So it all comes down to: there aren't really technical arguments against JDO, it is purely marketing and political. That's what is making people mad about this whole JDO x EJB3 fight.

PS: if vendors revenues, download numbers or market size have suddenly become any indication of quality, I suggest we all drop Java altogether and go back coding to Win32 API. ;)

Regards,
Henrique Steckelberg

If there were really big technical discrepancies between both APIs, I don't think this would be achievable in the first place!

Well, the same could be said about CMP. We were going to build our CMP solution on top of Hibernate but decided it wasn't worth putting one ounce of energy into rewriting an EOL product.

So it all comes down to: there aren't really technical arguments against JDO, it is purely marketing and political.

You can believe what you want, but if you google: JDO vs. Hibernate (like I just did) you'll find some interesting technical arguments.

That's what is making people mad about this whole JDO x EJB3 fight. PS: if vendors revenues, download numbers or market size have suddenly become any indication of quality, I suggest we all drop Java altogether and go back coding to Win32 API. ;)Regards,Henrique Steckelberg

The thing is, you have to take everything into account when deciding what specification to support and not just technical arguments. It takes an extreme amount of energy, time, and money to implement, support, sit on committees, market and sell your implementation of a specification. At the time me made our choice, JDO seemed like a dead spec (and still does). We wanted to bring a large standards-hungry J2EE community(JBoss) and combine it with a large proprietary community(Hibernate). We thought and still think EJB was the best course to take.

If you don't like these arguments, then that is your perogative, but please understand that a lot of thought went into what direction JBoss was going to take. We didn't make this decision lightly.

There's a lot of good that has come out of this whole thing. It looks like that there will finally be a unified persistence specification that integrates with both J2EE and J2SE. The JDO experts have joined with the EJB experts in JSR-220 to fuse in their knowledge. Hibernate is involved with a standardization efforts. And finally, Java is going to get a unified POJO persistence spec that both JDO vendors and J2EE vendors agrees upon. POJO persistence is where we all want to be in the end, isn't it?

Bill

Sorry Bill for my "persistence" ;), but you are not making sense:

It takes an extreme amount of energy, time, and money to implement, support, sit on committees, market and sell your implementation of a specification. At the time me made our choice, JDO seemed like a dead spec (and still does).

So instead of leveraging upon an existing spec (JDO 1.0, on its way to 2.0), and "raising the dead" ;), it was actually cheaper and faster to create a new one from scratch? Sorry, I don't buy this argument. And everyone just saw how dead JDO is, just read all the threads regarding JDO ballot results on JCP, and all the mess having 2 persistence specs have created. If JDO was really dead, no one would have complained about anything, and people would have jumped into EJB3 persistence spec with no second thought.

We wanted to bring a large standards-hungry J2EE community(JBoss) and combine it with a large proprietary community(Hibernate).

I am sure that if Gavin had stayed with JDO by the (short) time he decided to make Hibernate JDO compliant, we would have it standard compliant and working TODAY. We would have a great proprietary community and product become standards compliant NOW, not in some months time, and without any "spec unification" wars. Everybody would be happy. Are you still sure creating a new spec was the best, cheaper, faster solution?

There's a lot of good that has come out of this whole thing. It looks like that there will finally be a unified persistence specification that integrates with both J2EE and J2SE.

I don't see this whole spec unification war as anything good. It could and should have been avoided in the first place. (It's like: let's have a war, because when it ends, we will be happily in peace...)

The JDO experts have joined with the EJB experts in JSR-220 to fuse in their knowledge.

And how is this cheaper or faster than making Hibernate JDO 2.0 compliant? How is this cheaper or faster than simply have EJB adopt JDO as its persistence spec, and be over with it?

Hibernate is involved with a standardization efforts. And finally, Java is going to get a unified POJO persistence spec that both JDO vendors and J2EE vendors agrees upon. POJO persistence is where we all want to be in the end, isn't it?Bill

Wrong. Not all WANT to be there: some have already GOT there, and are already happily spec-compliant. ;)

Regards,
Henrique Steckelberg

Bill,it is rather difficult to understand how there could be such relevant technical arguments against JDO as much as to demand creating a entirely new persistence spec, and then have JDO vendors provide BOTH JDO and EJB3 persistence APIs with the SAME IMPLEMENTATION supporting both behind them! If there were really big technical discrepancies between both APIs, I don't think this would be achievable in the first place! So it all comes down to: there aren't really technical arguments against JDO, it is purely marketing and political. That's what is making people mad about this whole JDO x EJB3 fight.

Perfectly expressed.

Also: if vendors are capable of implementing both JDO 2.0 and EJB 3.0 POJO, why shouldn't J2EE 5.0 include both as well? There are precedents for this: an example is how J2EE includes both servlets and JSPs. These have overlapping functions - they both emit HTML - and various developers perfer one over the other. Sounds familiar, doesn't it! JDO 2.0 and EJB 3.0 POJO obviously have overlapping functions, but I am assuming that EJB 3.0 POJO will have significant benefits relating to RDBMSes and running in app servers, and JDO 2.0 remains datastore-type-agnostic. There is clearly room for both. Let developers choose which is best for a particular application, while allowing easy switching between the two APIs, and their concurrent use (just like the Servlet/JSP arrangement).

What I find *really* disturbing about the whole JDO/EJB3 debate is that the TSS Cause of the Month Club and the Bitter Bloggers are so quick to try and tear down the JCP. Proved to me how short thinking people can be sometimes.Bill

What I find *really* disturbing about the whole JDO/EJB3 debate is that the TSS Cause of the Month Club and the Bitter Bloggers are so quick to try and tear down the JCP. Proved to me how short thinking people can be sometimes.Bill

Sorry for blank post!

Your posts have clarified things, and I am beginning to see what some of the arguments are for EJB 3.0 POJO not being JDO 2.0. I may not agree with some of them, but I can at least see the point of view!

I think the reason why many of us felt bitter was the opposite of what you are stating: JDO was not a 'cause of the month' - quite the opposite: it was and is a technology we have invested in and plan to use long term because it is a JSR. It seemed to us like the JCP was being short thinking; neglecting years of work and changing direction simply to track what happens to be currently popular. If this happened, why should we trust that any future JSR would be supported long term?

The vote for JDO 2.0 and the likelihood of future work on JDO to assist with a migration to EJB 3.0 has, in my opinion, improved things.

Tough luck for the smaller ISVs (like CodeFutures) that invested time and effort in JDO support.

I felt that way until last night when I read Mr. Burke's "standalone persistance" post in another thread here. Then I confirmed his claim by reading Sun's open letter. Now I feel good about EJB-3 persistance. As far as I can tell, consumers and suppliers of JDO can easily migrate to EJB-3 persistance without having to adopt EJB-3.

I agree, I don't think it is much of a leap either. Just at TSS I saw Versant stating they will have a JDO2 and EJB3 implementation. Seems the same with KODO too.

To me, this is a win-win for persistence application developers. J2EE gets POJO persistence and you get a LOT more vendors competing with each other. Makes for a much healthier standard.

Bill

*From the point of view of an corporate developer*

I think the JCP has done a great job of keeping corporations and OSS developers involved together. Many OSS ideas and innovations do make it to the JCP, and corporate involvement keeps all the big guys on the same page. I have only been in the industry for 11 years, but I have never seen such good corporation, cross vendor support in a technology before. I think this has been one of the keys to Java's success.

A JDO type conflict is going to happen from time to time. No process is perfect.

Potentially related?

http://jcp.org/en/jsr/detail?id=102

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

It looks like JDOM 1.0 (JSR-102) is still in the Expert Group Formation stage although, given the date of the original JSR, this presumably now means that the effort has been abandonned (please correct me if I'm wrong).

The comments against this JSR certainly express concern about overlap with the JAXB work, but the JSR did pass it's review ballot. Coincidentally I preferred the Java-eqsue API provided by JDom to the other APIs of the time, but I don't come across it very often any more.