The chat transcript of the recent 'Growing Support for JDO in the community' chat has been posted. The chat was very good, covering everything from technical questions to fierce accusations about the Java Data Objects (JDO) specification.
Check out Growing Support for JDO in the Community Transcript
The 'transpersist' user seemed really angry about JDO. What does the community think about some of his allegations?
I have to say, I am getting more and more put off at Sun putting these implementations out there without going through an open source standardization process. When it came to questions about NetBeans integration, open-source release... nothing but 'dancing' was done (i.e. we're considering it).
Then, they say that their process isn't PROPRIETARY rather that is is OPEN. Which is ridiculous. Because the JCP is very proprietary. It is run by Sun, for Sun. Here comes the big marketing machine... yet again. Soon, we'll be buying $5,000 implementations of JDO from BEA.
Well... as far as I'm concerned, Sun == Microsoft. Reading that transcript reminded me of the various chat sessions the Microsoft had announcing their own 'open standards'.
So does anyone know if an open-source implementation/integration of JDO is being worked on?
There is Castor JDO, which is open-source, but it is not quite compliant with the spec. I don't think it is a big deal, though - check it out - I actually like it better than Sun's spec.
jacek at numatica dot com
Have you had a chance to review the JCP 2.0 rules? It seems pretty open to me, a great improvement over 1.0. Infact, Sun has already been voted down on a number of JSR's, most notably IBM's Web Services Model JSR. I don't think it is possible to claim that JCP is proprietary anymore.
Furthermore, I am very surprised at the speed at which these JSR's are designed and developed. I may be wrong, but I attribute this to the structure/design of the JCP. Look at how slow these Web Services consortiums move, JCP is much faster by comparison, and still relatively 'open'. How can one claim that Sun has total control when Sun has already been voted out on a couple of issues?
I can appreciate the speed of the JCP process. But to me, that really isn't the issue. I am an open-source advocate. It really comes down to philosophy more than anything.
Independent standards body may move slower, but it is _independent_. When it comes to standardization... I assure you... faster isn't necessarily better.
The issue is about what limitations can/should/are placed upon supposed 'innovation'... and what constitutes 'intellectual property'. Or what constitutes copyright infringement. Or why there is no competition in the Java environment. Or why Java standards are declared by a single body (Sun) alone.
There are many such issues at hand. I am a Java developer who actively participates in the open-source community. I actively develop tools for others to use freely in their own projects... for whatever the end means.
I apologize for letting this get to an argument of open-source versus intellectual property... but the transcript made mention of open-source, and I had to make the point:
The JCP is not independent. JDO is not open-source. To say that something is 'mostly' open, or 'quasi-open' doesn't cut it.
There are degrees of openness in developing standards, and publishing implementations.
Sun's JCP defines how standards are developed, but it doesn't prescribe how the implementations are done. But my understanding of Sun's policy on reference implementations where Sun is the specification lead is that the reference implementations be made available under the Sun Community Source License (SCSL).
This license allows anyone to download the code, review, and comment on it in public. Many of the benefits of open source obtain, in terms of peer review, quality, and open feedback. But Sun preserves its intellectual property rights in the code, so it can be improved and developed commercially.
Another option, which in many ways is a more expensive development process, is open source, or in Sun's terminology, Sun Public License. This is the license that Netbeans uses, and it is very similar to the Mozilla license, allowing commercial implementations based on the source without any royalties.
The reason I say it's more expensive is that the management of an open source project has more overhead, especially if multiple contributions need to be coordinated. And at the risk of sounding like a broken record, we are considering to continue development of JDO as an open source project.
Just a note about the JCP process. Once a standard is published, the work of the expert group and implementation team is finished, except for interpreting the specification and maintaining the reference implementation and test suite.
The only way to continue development of the standard is to propose another JSR, or to turn the reference implementation over to an outside process (like open source under the Netbeans model).
Until we have a successful JDO 1.0 adopted by the community, it's jumping the gun to talk about the successor.
I appreciate your elaboration on the terms of the SCSL.
I want to be clear, I have no issue with JDO. I think JDO is a *vast* improvement over entity beans in general. IMHO, JDO is much more in line with what most people are actively doing using JSP/Session Beans/JDBC... only better.
I only wanted to impart that JDO is not open-source. The JCP is not run by an independent standards body. I felt that you eluded to JDO and JCP being open and independent... when neither are. With Java and its related frameworks, Sun has rejected the ECMA. Sun has rejected the ISO. Sun has rejected the GPL.
It frustrates me, because I feel that Sun and Microsoft are trying to seriously cloud what the terms 'open-source' or 'free software' mean. These terms are very well-defined on opensource.org and fsf.org.
Again, I do _sincerely_ apologize for getting off on this thread. Again, I think the JDO is a wonderful improvement. I think it will be a good product. But I was really responding to the comments made about the open-source/standardization questions, and what I felt those inferred.