This post originated from an RSS feed registered with Java Buzz
by Brian McCallister.
Original Post: Getting Rolling on Native JDO in OJB
Feed Title: Waste of Time
Feed URL: http://kasparov.skife.org/blog/index.rss
Feed Description: A simple waste of time and weblog experiment
I have recently been reminded of the importance of standards, and it has had a nice effect -- I got off my high horse and started implementing a real JDO interface to OJB. The core of it is in place now -- actually, has been for a while as Matt, Raghu, and Oleg did all the heavy lifting for the object transaction stuff in the OTM -- all I am doing is wiring it up, and adding a JDOQL interpreter, to work in a JDO compliant manner. It isn't actually very useful yet as filters on queries are ignored, though. Still need to do the fun part of efficiently translating JDOQL to OJB's query by criteria api. Should be pretty straightforward, I hope =)
The initial design, and I intend to try had to keep it this way, is to make the client side independent of the spi interfaces. You should be able to use OJB JDO without bytecode enhancement -- as long as you don't try to access the SPI directly (which you are not supposed to do anyway). If you do use a bytecode enhancer OJB will certainly take advantage of it for state management, etc, but then again, this will be equally usable by clients of any of the interfaces. It just means using different EditingContext and FieldAccessStrategy implementations in the OJB config.
Native JDO won't be in 1.0, but will be there for 1.1, and may make it into 1.0.x -- though don't hold your breath on 1.0.x. If 1.1 takes half as long as 1.0 has (I think we are approaching the Struts release schedule at this point, if we aren't slower already) I will definately backport the code though, if only as a download here or on SF.net.
The reason for finally getting off my butt to work on it ties directly to a conversation with Thomas Risberg, Dmitriy Kopylenko, and Bill Thompson after the most recent PhillyJUG meeting. We discussed data access in 10+ or 20+ year lifespan applications (ie, Java as Cobol). At that point any proprietary api for data access needs to go right out the window -- sure, I expect OJB to be around in ten years (community > code at Apache is for a reason), but I don't expect the interfaces to be compatible. I expect JDO to remain pretty compatible -- Sun and the JCP have shown excellent restraint in that regard (notice that Entity Beans aren't even deprecated yet!)
Previous Topic
