|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 87
Messages: 87
Messages: 87
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Featured Article: Persisting Problems
Geir Magnusson Jr. and Jeremy Boynes, wrote a joint letter on the "big problem in the Java persistence community". They discuss their views on persistence within Java and J2EE, and where they see it fitting. Their solution asks for a transparent persistence model to finally be placed in J2EE, and that people start to work together, on our common goal.
Read Geir and Jeremy in Persisting Problems
|
|
|
Message #125150
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Unified persistence pathways == a Good Thing
This is a great article. Thanks, guys, for taking the time to put together an objective analysis of the persistence debates that have been going on.
The discussion of providing a compatibility path is particularly valuable. In addition to just feeling like the right solution, this is critical in light of Microsoft's recent intimations that ObjectSpaces is becoming the across-the-board API for object storage in .NET. Microsoft is playing catch-up with the Java community right now; pushing for a Grand Unified Theory of persistence in Java will help raise the bar even more.
-Patrick
--
Patrick Linskey
SolarMetric Inc.
http://solarmetric.com
|
|
|
Message #125161
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Featured Article: Persisting Problems
Thanks for this article. I hope it will clear the waters in the Java Persistence arena.
Best Regards,
Antonio Gallardo
|
|
|
Message #125165
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Featured Article: Persisting Problems
I strongly support this idea. Its a shame that the few politically inclined are ruining an excellent opportunity that lay ahead for solving this problem. Hopefully such letters will change their minds and lead to a colaboration.
|
|
|
Message #125173
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
not quite different problems
I do not quite agree that pojos and ejb solve different problems. They solve the same problem, that is persistence. Transactions, security, etc... are additional concerns that today we would call aspects and that can be successfully addressed also by pojos, as jbossaop, spring and other frameworks are teaching us.
Carlo.
|
|
|
Message #125176
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO can't be fixed
The authors state that any problems with JDO 2.0 can be fixed. But the main deficiency of JDO 2 is that it allows applications to function *without* websphere or weblogic, and I don't think much can be done about that.
|
|
|
Message #125177
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Featured Article: Persisting Problems
Thanks Geir and Jeremy.
For reference work on JDO 2.0 started in August 2003, although the submission of the JSR was delayed within Sun until only very recently.
An early draft of the JDO 2.0 specification will be published for community review in about 5 days time. The early draft has been the result of substantial effort by the JDO 2.0 EG members, and in particular it has substantial coverage of:
- object/relational mapping standard metadata
- JDOQL named queries and support for projections and aggregation
- SQL queries (the RDMBS user's fallback position!)
- domain object detachment
- named fetch groups (for detachment demarcation and performance tuning)
- relaxation of the binary-compatibility (PersistenceCapable) requirement - we might even use reflective techniques to build a reference implementation, proving the implementability of this approach.
Naturally we remain very open to community input, and one of the reasons for the early draft is to solicit this input.
Kind regards, Robin.
|
|
|
Message #125178
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
not quite different problems
I do not quite agree that pojos and ejb solve different problems. They solve the same problem, that is persistence. They are very different problems, the main reason for EJB is to simplify RMI, only one of the four types of beans is related to persistence. If distribution isn't an issue (perhaps you're only using local interfaces), then there is little reason to use EJB over a portable framework like Spring.
I've got to say that I bemused by the constant wrangling over persistence. We are in a very comfortable position of have many high quality persistence mechanisms to choose from depending on the (political) situation where you work. Meanwhile Java is still dragging behind the competition (.net specifically) in many areas!
|
|
|
Message #125179
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO can't be fixed
Tom Davies :The authors state that any problems with JDO 2.0 can be fixed. Our intention is really not to push JDO here specifically. What we said about JDO 2 is :
From the blog : JDO 2.0 just got started. Any of the supposed deficiencies in JDO can be addressed. If, in the opinion of the J2EE EG, that JDO's model is inappropriate - that recent work in open-source or commercial solutions offer compelling alternatives - start a new EG and include members from JDO as well as EJB. In other words - "Give it a shot. If it doesn't fly, start a new EG." Personally speaking, hard to believe that the problems people have with JDO aren't resolvable.
Further, you said : But the main deficiency of JDO 2 is that it allows applications to function *without* websphere or weblogic, and I don't think much can be done about that. How can that be a *deficiency*? We think that is a good thing because not only does it allow one of the goals of EJB3's POJO work, namely testing outside of the container, but it allows J2SE applications to migrate easily into a JDO-supporting WebSphere or Weblogic. That's a compelling argument for the Java platform as a whole, isn't it?
-geir
|
|
|
Message #125182
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO can't be fixed
How can that be a *deficiency*? We think that is a good thing because not only does it allow one of the goals of EJB3's POJO work, namely testing outside of the container, but it allows J2SE applications to migrate easily into a JDO-supporting WebSphere or Weblogic. That's a compelling argument for the Java platform as a whole, isn't it? Yes, it is. Geir, I think you perhaps missed the irony in Tom Davies' words.
Kind regards, Robin.
|
|
|
Message #125187
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Persisting Problems
I can only repeat what others said on this thread before: thanks for putting in the effort. I believe that Geir and Jeremy have spelled out in this great what many others have been thinking and trying to say before.
I know that many people in the JDO community (and the JDO 2 expert group) can't wait to engage in a serious discussion about what makes JDO difficult or impossible to use in the EJB 3 context. I'm confident the JDO 2 expert group will try hard to understand and, if possible, address any such concerns.
Note: The above is my personal opinion. I happen to be a member of the JDO 2 expert group, but I do not speak on its behalf.
|
|
|
Message #125188
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO can't be fixed
Geir, I think that that more of a "deficiency" than a deficiency.
In other words, the comment was sarcastic. JDO works without having to pay for weblogic or websphere, therefore it's faulted, we can't have that no sir.
Radu.
|
|
|
Message #125190
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Featured Article: Persisting Problems
1:Full Disclosure from Geir : I'm the Apache EC rep and voted yes because I think that despite assertions to the contrary, there is no overlap with existing technology, and if there *is* overlap, competition is good - let the market decide. 2:The obvious solution - "Well, you've had a JSR for POJO persistence for some years now... JDO - why not add it to J2EE?" - is an answer that no one seems to want to hear because there appears to be a war going on between the JDO and EJB communities. Technology battles aren't new, but this one is astounding in it's irony. The EJB3 group, by adding POJO persistence, is validating the whole argument for JDO or a JDO-like technology in J2EE. There will be arguments about technical details such as choice of query language, approaches to detaching object graphs, etc but at the end of the day, the EJB EG is advocating the addition of a technology approach that already exists in the "Java ecosystem" - JDO - into J2EE. I think that the overlap is plain to see but I agree with Geir -- let the market decide.
"Funny" thing is that standards like ejb, j2ee are still so unstable these days that "write once run everywhere" works much better if those standartds are ignored.
Wasn't hibernate promoting itslef as extermly portable as apps which are using it can be deployed to any app server without any changes in the code :). Even Geir's pet - veociity is still usable and shining after few years since when it has become usable and during that time we had jsp 1.2, 2.0 and JSF and many other things which are still sucking and are incompatible with each previous versions...
I know more and more people which are prefering not to use anything which is known as a standard :).
I guess that we need still many years until this will change ... simply becouse good standards are devloped interativly and there will be always a place for competing standards but first of all becouse standards are not convinent for big software makers as what they are doing can be replace by the solution provided by other software maker.
Michal
|
|
|
Message #125191
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO can't be fixed
Geir, I think that that more of a "deficiency" than a deficiency.In other words, the comment was sarcastic. JDO works without having to pay for weblogic or websphere, therefore it's faulted, we can't have that no sir.Radu. Erm. Yep. Sorry. Teaches me to post pre-coffee. :)
I'd like to make sure that this discussion isn't only about JDO. (Although the JDO wars are worrysome.) The bigger issue for me is J2EE as a platform, and ensuring that EJB doesn't become compromised through kitchen-sink-itis and scope creep.
As noted before, I think *everyone* agrees that having some kind of POJO persistence mechanism available in J2EE is a Good Thing(tm). What we don't agree on (or are challenging the conventional wisdom, actually) is where in the specification suite it should be, and think we should discuss it before we get too far down the road we're currently on.
geir
|
|
|
Message #125192
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO can't be fixed
I'd like to stress Geir's earlier point: the article which has been published is not expressly pro-JDO, but is pro-Collaboration between the EJB and JDO Expert Groups on the theme of persistence. (My own words).
I believe the JDO Expert Group (of which I am a member) has done must in order to facilitate this cooperation.
Well articulated technical objections to JDO as a persistence solution for EJB are few and far between. The political objections have their own threads for discussion. Where the JDO Expert Group has been notified of specific technical issues we have and are addressing these:
Bytecode Enhancement
The JDO 1.0 spec did not mandate bytecode enhancement (it mandated PersistenceCapable) but few people took note of that. As the most efficient and transparent (to the developer) means of implementing the PersistenceCapable interface, bytecode enhancement was almost universally chosen by JDO 1.0 implementations.
In response to comments, particularly from Oracle who addressed the JDO 2.0 kick-off meeting in DC and was directly involved in JDO 2.0 until recently, the requirement for persistent classes to implement PersistenceCapable has been removed. A few other semantics in JDO had to change, since without PersistenceCapable it is difficult for non binary-compatible implementations to detach field modifications as they occur. For example, detached instances in JDO 2.0 are by default expected to have all primitive fields populated, since reflective implementations cannot discern between primitives with default values and primitives whose values have not been loaded from the database.
Indeed, it is possible that the JDO Expert Group will pursue a reflective reference implementation. Naturally many existing JDO vendors will support the now optional binary-compatibility feature, and will continue to utilise enhancement as an efficient means of data management. But the requirement to do so has been removed.
Persistence-by-Reachability
At the time of the TSS Symposium announcements it became apparent that JDO's "Persistence-by-Reachability" was a "problem". [Naturally "cascading updates", the Hibernate-style capability, is OK. ;-) ]
In response to this criticism I expect that the second draft JDO specification (the first will be available in a few days) will add a new metadata capability to turn off persistence-by-reachability over individual relations. No promises, as with Oliver I do not speak on behalf of the expert group, but this seems likely to happen. Of course I would be surprised to see this feature used particularly much.
By default, if a (perhaps newly) persistent instance of a persistence-capable (lowercase!) class holds a reference to a transient instance of a persistence-capable class, then on commit() the transient instance is made persistent.
If persistence-by-reachability is disabled on that association, however, the same situation would cause a "ReferencedInstanceIsNotPersistent" exception (my own name for now). It would only be legitimate for such a reference to be made to point to an already-persistent instance.
Others?
The above two points are the only ones which occur to me as being the basis of well articulated technology-based objections to JDO becoming the preferred persistence abstraction for EJB and J2EE. I would be extremely happy to hear of others; if objections are based on technology and are well articulated then they can be debated within and between the expert groups and the community, and potentially addressed.
Conclusion
Oliver commented:I'm confident the JDO 2 expert group will try hard to understand and, if possible, address any such concerns. +1
Kind regards, Robin.
|
|
|
Message #125194
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Errata - JDO can't be fixed
I made two misleading mistakes in typing my previous post - applogies
"I believe the JDO Expert Group (of which I am a member) has done much in order to facilitate this cooperation."
"A few other semantics in JDO had to change, since without PersistenceCapable it is difficult for non binary-compatible implementations to detect field modifications as they occur. "
|
|
|
Message #125199
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Featured Article: Persisting Problems
As an ISV, having one persistence solution will enable us to focus on that one solution. And reduces cost. But I seriously doubt the EJB EG will understand.
Pratheep P
|
|
|
Message #125201
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Yes, 'deficiency'
Geir,
I should have added a smiley. I really enjoy using JDO.
I was just trying to find an explanation for BEA and IBM's no votes.
Tom
|
|
|
Message #125209
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Featured Article: Persisting Problems
Pratheep P :As an ISV, having one persistence solution will enable us to focus on that one solution. And reduces cost. To be clear, we are talking about two persistence solutions, or at least APIs. One would be the POJO persistence API (like JDO or Hibernate or something new combining the best of both and other implementations of the idea), and the other would be the existing persistence capabilities of EJB. EJB isn't only a persistence framework. It's a component model that has persistence as part of the spec. I'm *not* an EJB expert by any stretch of the imagination, but two of the three main objects in the spec (session beans and message-driven beans) are not persistence technology. Only entity beans are designed to be a persistence technology, and even then, architectural style allows a wide variance in approach.
So for an ISV, this proposal doesn't necessarily make it cheaper, but it doesn't necessarily make it more expensive. The current path of EJB3 appears to be that an ISV could have to implement EJB2.1+changes as well as this new POJO persistence thing. All we're saying is move the POJO persistence thing out of EJB to separate the concerns.But I seriously doubt the EJB EG will understand. I'm not sure - we'll have to see. Besides Jeremy, Richard and David have also indicated support (RMH's is a comment to the blog - I added it as an update).
I think that the EJB EG is made up of people who have been around the block once or twice and can spot a crufty API when they see one. All seem committed to the "ease of use" proposition of J2EE 1.5, and I'd expect that moving this out of EJB3 would make their job easier as as an expert group and allow them to focus on evolutionary improvements to the existing EJB 2.1 spec while being assured that POJO persistence will be a part of J2EE.
- geir
|
|
|
Message #125212
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Collaboration is King
Geir and Jeremy have expressed a growing concern from within the J2EE community very nicely and I applaud their effort. Being one of the newest members to the JDO 2.0 EG, part of my interest in joining was to try to facilitate communication between the JDO 2.0 EG, the EJB 3.0 EG and the community as a whole.
I'm not part of the EJB 3.0 EG, but I have three friends who are. My hope is that our friendship will work to facilitate communication between the two camps so that we can work together rather than working apart.
I think that the first step is for the community and the EJB 3.0 EG to review the draft when it becomes available. As Robin has already pointed out, the first early draft of the JDO 2.0 spec will be available in a few days. Once this takes place I believe that we can then begin talking about how to work together, identify some goals and begin execute a plan.
Nice job Jeremy and Geir!
|
|
|
Message #125219
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Featured Article: Persisting Problems
JDBC is part of J2SE - I haven't heard of any J2EE guy complaining about this.
So let's include JDO in J2SE too - then even the simple-minded would see that
EJB3 doesn't need to reinvent the wheel.
svenmeier
|
|
|
Message #125220
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Featured Article: Persisting Problems
So let's include JDO in J2SE too - then even the simple-minded would see that
EJB3 doesn't need to reinvent the wheel. Judging from the way I have seen JDO take shape currently:
+1
|
|
|
Message #125221
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO and Java 2 Standard Edition
JDO is a Standard Extension of J2SE. As far as the JCP is concerned it is already as much part of J2SE as is necessary.
JDO is not part of the JDK download. I would love to change this but I actually don't know how to. It might need to wait until the JDO 2.0 Reference Implementation is available, but technically JDO could be bundled with the JDO 1.0 RI today.
If anyone can put me in touch with the right people with whom to discuss the inclusion of the javax.jdo package in the JDK distribution I would be most appreciative.
Kind regards, Robin.
|
|
|
Message #125223
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Featured Article: Persisting Problems
All we're saying is move the POJO persistence thing out of EJB to separate the concerns. +10! I've actually been advocating this myself since Linda's talk at the TSS Symposium. Keep compatibility to EJB 2.1 Entity Beans if necessary for migration path reasons, but don't introduce a new model within the EJB spec.
IMO, the main reason for making Hibernate-style persistence part of EJB 3 is to have a credible successor to EJB 2 Entity Beans under the EJB umbrella - obviously a political reason, not a technical one.
My main concern is that the only vendors who will be able to provide EJB 3 Entity Beans implementations are J2EE server vendors. Why require a single vendor to provide everything, from the web server to the O/R mapping tool?
I'd like to see broad competition of standalone O/R mapping products that can be combined with any environment in a flexible fashion. Such products should also be allowed to be certified on their own, like current JDO implementations.
Juergen
|
|
|
Message #125230
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO and Java 2 Standard Edition
>>JDO is not part of the JDK download. I would love to change this but I
>>actually don't know how to
I don't agree. Even the jdk itself should be split and a clearer and more solid mechanism than the endorsed dir should be provided. Otherwise as the jdk covers more and more apis (from xml, to xslt, to web services, etc...) alternative implementations will be demaged.
Carlo.
|
|
|
Message #125231
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
not quite different problems
The EJB specification was not designed to solved persistence or simplfy RMI. It was designed to specify the building of distributed components. The problem comes with the fact that very few people are building distributed components using J2EE. Instead most people are using it to build local components. By doing this we are trying to fit a square peg in the a round hole and hence all the issues we have today.
|
|
|
Message #125238
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO can't be fixed
To a neutral observer it seems that the JDO people have been bending over backwards to accommodate the criticism raised against JDO. Time and again they remain on topic with technical arguments even in the face of obviously groundless attacks from prominent persons from the EJB expert group. Hell, who am I kidding, I am talking about Gavin King and his emotional outlashes.
With all the writing back and forth the impression remains that the resistance against JDO from the EJB expert group is squarely political for reasons all too plain for all to see.
Here's hoping that the differences will be resolved, but with this kind of politicising and partisanship coming from the EJB expert group it doesn't look too good from where I am. I think it's time for the benevolent dictator to take the wheel and steer J2EE in the right direction. Isn't that what Sun is there for anyway?
|
|
|
Message #125239
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I support Geir and Jeremy
I support Geir and Jeremy's position. While I was initially excited about a POJO persistence model for EJB, I now believe that the community is best served by having the EJB 3.0 and JDO 2.0 expert groups collaborate. These two groups should be working together for the common good of the Java community.
|
|
|
Message #125240
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO and Java 2 Standard Edition
>>JDO is not part of the JDK download. I would love to change this ...
>I don't agree. Even the jdk itself should be split ...
>Otherwise as the jdk covers more and more apis ... alternative
>implementations will be demaged
Agreed, but since javax.naming, javax.sql, javax.transaction and javax.xml are
already included, why not javax.jdo ??
Note that jdo is only an API (as JDBC), so including this should not damage anything.
svenmeier
|
|
|
Message #125242
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Community is moving on without waiting for standards
I think that the arguments between EJB and JDO are fairly pointless when you consider that both technologies left the gate as insufficient solutions for a lot if not most developers. If you look at the larger Java community, you see a wealth of very focused, highly popular projects that are obsoleteing these standars. Take a look at Hibernate, Spring, all the aspect frameworks... these are things that people are putting to use right now. In many cases people have been using them succesfully for quite sometime. Sure it's not always a standard spec, but it's all still java and all highly portable. We have real defacto standards out there and a wealth of frameworks desinged in the real world. I'm not sure who is going to wait around for EJB 3 and JDO 2 when the current codebase and the market are changing at a rate that outpaces the expert groups.
|
|
|
Message #125251
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
dirt-slinging from both sides
the JDO guys certainly have contributed their share of FUD and false claims, that much is true. If you read the latest article by David Jordan on jdocentral, you find him sayingIBM and Oracle are two major players in the EJB app server space that one would expect to be at least leery of the EJB 3.0 expert group's choice. However, as database vendors also, they probably prefer Hibernate to JDO because it uses the SQL syntax of the underlying RDBMS--which allows applications to be locked in to a specific database vendor. That is about as much FUD as you can put into one sentence. He even goes on to sayIf this truly is their plan, it could really backfire. Many developers who use open source software like Hibernate and JBoss are also using the MySQL open source database. Many companies are starting their new, more risky application projects with MySQL to minimize costs during these projects' trial phases. Many plan to then migrate the projects to name brand databases like Oracle 9i once they prove successful. But by using Hibernate, these companies are locking their applications in to MySQL. In which case, enterprise solution vendors such as IBM and Oracle will lose market share in both the application server and database markets. If JDO were used, the applications could migrate from MySQL to Oracle or DB2. I, being a JDO sympathizer, am dumbfounded by public statements like that one. I hope we can all leave this level of discussion and meet on factual, technical grounds to find a good solution in everybody's interest.
Christian
|
|
|
Message #125252
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB 3.0 will give the J2EE market to .NET
Wery good article.
I regard myself as part of both the JDO and EJB community. In this perspective, when it comes to EntityBeans in the EJB specification I sincerely think that it just blocks the further development of EJB as I would like to use it in the enterprise. For the record I can honestly state that I am not a stakeholder neither for any product, nor open source projects. I am a user of the J2EE platform and has used EJB in large projects since 1998, both as an system architect and developer in large scale financial soultions.
My biggest problem is that I think the EJB is a very good standard for distributed components and to orchestrate transactions. But when it comes to persistence, the EJB-EG seems to have got into a hybis mode rigth from the start. This would be ok, if only users of J2EE products could avoid parts of the EJB-standard (in my case the EntityBeans) and use another techniques instead. However, my experience of this urge of the EJB specification camp to present a persistence soulution instead of just make a good integration framework for other persistent techniques, is that the EntityBeans are acutally hurting the whole J2EE-specification and their products. I argue that the requirement of the EntityBeans:
- makes it much more expensive to create and maintain an EJB-server product
- steals valuable time from other more important things to solve in the EJB specification. The whole J2EE platform development is slowing down significantly
- makes false illusions for many people that uses/should use J2EE that you must use EntityBeans as a persistent mechanism in J2EE solutions
Also there is another big problem to contain both distributed components and persistence in one specification. The innovation/maturing cycles on these two very difficult mechanisms are not the same. Separating the persistence from distribution will make both mechaisms to evolve faster in the J2EE community as a whole. Just use JDO as a demarcation line in order to make both flourish!
The above problem is a huge threat to the Java community as a whole. All this three harmful things about EntityBeans serves only one; Microsoft with their .NET framework. We have to realise that the big three (IBM, Oracle and BEA) will actually hurt themselfs by having a short term desire to avoid the JDO as an all tier (desktop app, servlet and EJB) persistent mechanism. This due to their paranoia that other Java-companies will "steal" their customers. With the avoidance of the JDO they will perhaps win the battle but loose the war - to Microsoft – and all of them. The only gain is for Microsoft who once again can watch how different vendors kill themselfes in the standard/product arena, just as they did in the "open platform/UNIX/POSIX" war in the late 80:s. Remember that it wasn’t a long time ago IBM fought the J2EE specification with all means available.
So why not go productive in J2EE: Let the JDO become a part of the J2EE as the authors in the feature article suggest, and also make it the split between the EJB specification and a perstistence API i J2EE. I mean; Hibernate would not be hurt by this; it can be JDO compatible. This without harming the Hibernate fan club out there. Just use an API standard that exist instead of making yet another API standard from a single product. (And as we all know who has been working even a tiny bit in the development area, making an API from one single product always leads to a flawed API, even if the procuct is a good one). Remember that Java has to be and keep competitive against the .NET technology. For my part the best of worlds is when J2EE and .NET have 50/50 market share. Now I am worried that the EJB 3.0 specification will ensure the .NET to have much more than 50% in the future.
This is not only a .NET vs. J2EE competition issue. We really do need a J2EE API for persistence that can be used either directly by an desktop app, a servlet or in a EJB. This because business to be successful must start small and grow their costume depending on how the business turns out. By having a unified persistence mechanism for all tiers will indeed make the object domain protable to more scalable systems.
Sorry for the long an tedious statement. Hope it was worth the read.
|
|
|
Message #125253
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
They're right
Everything they say is technically right, but it seems to me that all they're really doing is whining about JDO being less popular than Hibernate. They'd be saying the exact opposite if they could take it's place in EJB3, which I don't agree with.
I like the idea of transparent persistence (without transactions, etc.) in J2EE, but I still have hope that someday someone will actually write a real EJB engine with decent activation/passivation and searching/indexing and not just a hacked together copy of the *Reference Implementation* using existing technology.
The java community has a habit of copying Sun's prototypes blindly without putting any real R&D into their own design. I imagine if Sun concieved of a relational database and implemented it using flat files for every record and directories as table names and indexes as xml files then all the ISVs would race to compete creating modular file format plugins, meta-index xml files, and bad Swing based file creation wizards, instead of improving the underlying engine.
For the same reason I think JDO's binary compatibility is brain-dead, though it seems to me (having not used JDO myself) to be more versatile than Hibernate.
|
|
|
Message #125255
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Different thread?
I thought there was a different thread for this discussion? Many things have been said about the article you quote in that other TSS thread and by now I believe it's quite dead. That's not a bad thing.
This very thread started with a very good letter and was followed up by many matter-of-fact style posts: I think we should try to keep it this way and no engage in detailed discussions on who said what, where, and when.
Let's work on the technical problems.
|
|
|
Message #125257
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB 3.0 will give the J2EE market to .NET
So why not go productive in J2EE: Let the JDO become a part of the J2EE as the authors in the feature article suggest, and also make it the split between the EJB specification and a perstistence API i J2EE. With the prevailing (and understandable from a business perspective) attitude of the big server vendors, that would require an act of Sun.I mean; Hibernate would not be hurt by this; it can be JDO compatible. This without harming the Hibernate fan club out there. Just use an API standard that exist instead of making yet another API standard from a single product. I agree wholeheartedly. That is why it was particularly disheartening to see Gavin King's inflammatory remarks against JDO followed by a refusal to back them up with anything substantial, in the recent debate here on TSS. I even believe Gavin has rejected the idea of making Hibernate JDO compliant, so not really much hope of reconciliation from that side.
|
|
|
Message #125258
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Different thread?
granted. Nonetheless I hope Mr. Jordan joins you in this attitude, and proves this by removing the article in question
|
|
|
Message #125260
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB 3.0 will give the J2EE market to .NET
To extend, I don't mean to point fingers and I agree with the spirit of moving on from the original post. My comment should be read as an expression of hope that Sun will use it's position to counter political infighting in the shaping of the J2EE future.
|
|
|
Message #125262
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Community is moving on without waiting for standards
I disagree with the argument that Hibernate, Spring and other successful projects can be taken as de facto standards _today_. De facto standards exist when we can safely ignore competing technologies, since they would be very marginal. This is not the case here, we can not assume Hibernate is a de facto standard and just ignore JDO, Entity Beans, Ibatis and other persistence APIs out there.
Despite market velocity and rate of code change, there is a need for standards, else we should have fragmentation and lock-in. For example, people who are using AOP today are somewhat locked into a specific AOP framework, it wouldn't be easy to switch to another one without major reworking of code, annotations and configuration files. If these should be standardized, this kind of change would be made much easier, and would foster competition between different implementations of such standards.
The good thing we are having here is the creation of a standard on something that exists and works, and not for something that is just an unproven concept. Both hibernate and JDO have proven themselves already, now we need to standardize this specific area, so our projects would be more easily ported between different persistence technologies, avoid lock-in and be future proof. JDO may have an advantage here: imagine if OODBMS become viable in the future (it is not impossible), would we want to be tied to RDBMS, if we had the choice?
BTW, what happened to the decision of making hibernate JDO 2.0 compliant? The fact that this solution was evaluated means that JDO 2.0 can be applied to EJB3 persistence. Wouldn't that solve all the problems, for both camps?
I don't agree also with the idea of leaving persistence services completely out of EJB3 specification, be it JDO or any other. IHMO, a distributed component framework should define all the services such a component could use, and persistence should be one of them. Not forgeting also the issues regarding interdependencies between services themselves and everything else that comes with it.
Regards,
Henrique Steckelberg
|
|
|
Message #125263
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO can't be fixed
I think *everyone* agrees that having some kind of POJO persistence mechanism available in J2EE is a Good Thing(tm). As one who tends to operate on the J2SE side of the J2EE/J2EE divide, I think this should be looked at a little thing. I've always avoided full-frontal J2EE primarily for lock-in reasons, both vendor and architectural, where EJB is the biggest lock of all. Servlet, jms, and jndi (to some extent) can be used both standalone and without completely locking in to a J2EE container. IoC (and Spring in particular, in my view) and POJO persistence (I lean toward Hibernate even though most work I've done has Oracle on the back end. Nya-nya OJB FUD-ers!) allowed enterprise-style deployment for the higher complexity end of the J2SE spectrum. Throw in smart use of junit, ant, et. al. (Gratuitous pitch for XOM as an XML object model here too ;-) and you have quite a powerful development suite easily tailored to the complexity needs of the project.
In short, I like having a persistence solution available in J2SE! Standardized by committee or the market, I think this is a *good thing*.
An alternative overall platform "architecture", ie: what goes in J2SE, J2EE, standards, norms, etc. could go against this consensus and conclude J2SE is POJO's, scaling in complexity with the DAO pattern (et al), while J2EE persistence is container-centric and adds enterprise features like transactions, distribution, etc. What will be clamored for is an "upgrade path", but I'm not convinced this would really be desirable in the end. The big fear is that true enterprise-demanding projects would start J2SE-style and not be able to "upgrade". But this is just the first architectural rock that will be hit by a ship that wasn't built to the right scale in the first place...
This is more than I can chew on right now, but my point is that it shouldn't be so obvious where POJO-oriented persistence belongs.
mike
btw - perhaps the best and "real" way to resolve my point would be to ease the lock-in of J2EE/EJB to start with...let it become a true pick-and-choose building-block platform like J2SE! Maybe the current persistence tension is what will force that point?
|
|
|
Message #125264
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Binary compatibility
For the same reason I think JDO's binary compatibility is brain-dead, though it seems to me (having not used JDO myself) to be more versatile than Hibernate. FTR, JDO2 will not require that an implementation use the javax.jdo.spi.PersistenceCapable interface. That interface is still present as a suggestion for how one might achieve the goals required by the spec, and an implementation can designate if it takes advantage of the PersistenceCapable interface.
-Patrick
--
Patrick Linskey
SolarMetric Inc.
http://solarmetric.com
|
|
|
Message #125265
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
They're right
Aaron Evans :Everything they say is technically right, but it seems to me that all they're really doing is whining about JDO being less popular than Hibernate. They'd be saying the exact opposite if they could take it's place in EJB3, which I don't agree with. I'm assuming that you are responding to the main article, and not a discussion thread.
We're really not interested in JDO vs Hibernate, and I'm sorry that it wasn't clearer in the article. (Personally, I'm a Hibernate user.) It's not about pushing the "JDO Agenda" but rather recognizing that POJO persistence is on it's way into J2EE 1.5, and questioning if the EJB 3 spec is the right place for it.
We just suggested that JDO could (and should) be considered because of it's current status as a completed JSR with a vendor and user community, but please note that we also say, in the blog :If, in the opinion of the J2EE EG, that JDO's model is inappropriate - that recent work in open-source or commercial solutions offer compelling alternatives - start a new EG and include members from JDO as well as EJB. And we really mean it.
- geir
|
|
|
Message #125266
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AMEN
Great article guys,
Personally I would prefer to see JDO subsume the roll that JDBC plays, than become "complexified" by J2EE. If javax.jdo was part of J2SE in the same way that java.sql is, it would be a huge win for developers. With O/R mapping standardized by JDO 2.0 it will be as easy to switch JDO drivers as it is to switch JDBC drivers. Actually, pro'ly easier because if you use JDOQL you will not be locked into proprietary SQL.
-geoff
|
|
|
Message #125268
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Yes, Please Make POJO Persistence A Seperate J2EE Spec from EJB
Not adding much here, other than a vote, so that the right JCP members will hopefully take note of what the developer community is saying. EJB has been wrongly positioned from day one as "how you code all the biz logic of your enterprise application." As most of know, this proved to NOT work well. But EJB (surely due to Vendor agendas), keeps trying to adjust itself to be THE solution for all business logic (e.g. local interfaces). God KNOWS how many corporate dollars have been wasted in unnecessary, high-end application server license fees. Even with open source EJB containers, how much unnecessary complexity has been coded into applications because of misleading marketing.
I like to view EJB as "bundling" a bunch of middleware services - transactions, remoteness, persistence, etc. If I need many of them at once, then I look at EJB. If I need only one, I don't look at EJB. I think it's really dishonest of the EJB server vendors to say that JDO (a single middleware service - persistence) overlaps with EJB (the bundle of many services). If that's the case, why don't we throw out JTA - since it "overlaps" with (transactions in) EJB?
|
|
|
Message #125269
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AMEN
Geir comments:We're really not interested in JDO vs Hibernate, and I'm sorry that it wasn't clearer in the article. It was clear. It happend that the first few people to congratulate you on the article, which steps back and looks at the broader picture, were recognised JDO advocates. Readers quickly jumped to the conclusion that you must have been promoting JDO.
Kind regards, Robin.
|
|
|
Message #125272
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Maybe a new name for a standard?
I completely agree with the article! It is very difficult now to "sell" a persistance technology (EB, JDO, Hibernate, etc.), because nobody knows where the direction is going to...
Maybe there should be a new name for the persistance technology standard (not JDO, not POJO EB, something else...) so that all parties will be satisfied. Believe me, it could help a lot, if you use a name where everybody have the feeling, that they "belong" to that name ;-)
One persistance technology and standard, that's it. No JDO, no POJO EB, no Hibernate, ... but something "new".
Cheers,
Lofi.
|
|
|
Message #125273
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still waiting...
Good article.
I am still waiting for someone to explain why JDO 2 is not sufficient for EJB 3 persistence needs. I asked this question more than once in a recent thread and nobody stepped up to the plate. All I got was a little bit of hand waving.
I am not hung up on JDO (I have mostly used Hibernate), but I do recognize it as a well established persistence standard for Java objects. The next version addresses some important issues (standardized OR mapping and access to the relational model when necessary - among other things - that I find attractive). Can someone please explain at an acceptable level of detail why the EJB EG chooses to not use the JDO spec? Perhaps there is a very good technical reason, or perhaps egos are simply getting in the way on one or both sides. Could someone please enlighten us? Pretty please with a cherry on top?
Regards,
Bill
|
|
|
Message #125274
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Community is moving on without waiting for standards
I think that the arguments between EJB and JDO are fairly pointless when you consider that both technologies left the gate as insufficient solutions for a lot if not most developers. If you look at the larger Java community, you see a wealth of very focused, highly popular projects that are obsoleteing these standars. Take a look at Hibernate, Spring, all the aspect frameworks... these are things that people are putting to use right now. In many cases people have been using them succesfully for quite sometime. Sure it's not always a standard spec, but it's all still java and all highly portable. We have real defacto standards out there and a wealth of frameworks desinged in the real world. I'm not sure who is going to wait around for EJB 3 and JDO 2 when the current codebase and the market are changing at a rate that outpaces the expert groups. I completely agree with you. In fact, with open-source code you don't _need_ standards except for purposes of interoperability, e.g. TCP/IP. The other kind of standard, such as JDO or EJB, is there to mitigate risk. But another way to mitigate risk is to use an open-source project with a critical mass.
|
|
|
Message #125277
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Binary compatibility: not just an implementation detail
Binary compatibility is not just an implementation detail of JDO, but has some genuine uses. And again, byte-code enhancement is not mandated by the JDO spec and is not required to achieve binary compatibility.
Binary compatibility allows me to instantiate instances of the same class from different datastores managed by different JDO implementations in the same application. For example, I can get my residential customers (and related objects) from one datastore, and my business customers (and related objects) from another. (I'm not saying this is separation of datastores is desirable, but maybe this data is maintained by or sourced from different legacy applications.)
Another example is datastore migration: binary compatibility allows me load my objects (sub-graphs of my persistent object model) from one datastore, make them transient (i.e. disconnect them from the source PersistentManager), and make them persistent again with a PersistentManager backed by a different datastore and, possibly, managed by another JDO implementation.
In short: binary compatibility can be extremely useful in integration and migration scenarios.
This is certainly not the primary use case for JDO, but similar problems keep popping up when developing or integrating large enterprise applications: it's often one problem in a thousand, but it's nice if there's an easy way to solve this.
Again, this is one (i.e. not the only) solution for a very specific problem. JDO is targeted at and designed for more more common and wide-spread problems. To solve these problems, binary compatibility is often not required.
Kind regards,
Oliver Kamps
fiftybar.com
|
|
|
Message #125285
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Community is moving on without waiting for standards
I've reached the conculsion that standards really are not needed for web frameworks and application frameworks. Learning an API like Echo for building a web based app is cake. A standard would simply make it more difficult to do the job in some cases. But for core services like database access, it's tough to argue against a standard. Where would you be without SQL, and JDBC on top of that. My hope is that in a few years JDO will happily be perceived as simply a core plumbing standard, much to your point, like TCP/IP (and to that list I'd add SQL and JDBC).
|
|
|
Message #125291
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Community is moving on without waiting for standards
I've reached the conculsion that standards really are not needed for web frameworks and application frameworks. Learning an API like Echo for building a web based app is cake. A standard would simply make it more difficult to do the job in some cases. But for core services like database access, it's tough to argue against a standard. Where would you be without SQL, and JDBC on top of that. My hope is that in a few years JDO will happily be perceived as simply a core plumbing standard, much to your point, like TCP/IP (and to that list I'd add SQL and JDBC). We could perceive web frameworks as a blumbing standard too, one that connects the client side UI code to the server side business code. Standardizing it would give us some benefits: increase the shared knowledge (since there would be a single common API to learn, instead of a different one for each existing framework), focused development, lower risk, higher competition, componetization, lower fragmentation, lower lock-in, and many others. Of course to achieve this, we would need a good standard. In this case specifically, JSF still has to prove itself against existing solutions.
So I would disagree that specifications are not needed. There are good and timely specifications and bad or late specifications, but leaving the market for itself would create fragmentation, lock-in, and complexity as we see now in web frameworks.
It is nice to have differents APIs, technologies and approaches, but once a dominant solution is found, it is better to standardize on it, or on a mix of best practices, than to expect the market to reach a de facto standard by itself in the long run. The risk of this not happening is great, and we end up with 100s of different solutions to the same problem. We should have a kind of "controlled darwinism" in Java, to help fight .Net competition.
Regards,
Henrique Steckelberg
|
|
|
Message #125293
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
standard vs standard
IMHO it looks like it is going to be standard vs standard war.
My questions are (they are more or less same):
1. What we as developers gain if JDO becomes a part of J2EE?
2. Why JDO should become another mechanism for persistance within J2EE while we have entity beans (of course, EB simplification is a part of J2EE warranty as the technology matures?)
3. What EB3.0 will not give that JDO2.0 will give?
4. Why JDO2.0 replace EB? What happens to people already using EB?
Better would be to make JDO2.0 to be part part of J2SE rather then J2EE, just as JDBC and OMG's CORBA have been. See, nobody is complaining about them!
Just to clarify, so far I have not have any big issue with EB.
Thanks,
-Abhijit
|
|
|
Message #125314
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Still waiting...
Bill,
I have answered in the recent thread with some details. I am a member of the EJB3 expert group, and I cannot answer "why the EJB EG chooses..." since I am only one of many individuals. I can answer for myself.
My #1 answer is: JDO is overly complex.
My #2 answer is: if you can't do everything (including advanced features) in the JDO spec without bytecode enhancement, then I have a problem with that. It complicates debugging, it complicates usage by remote clients using EJB interoperability (serialization of persistent objects to clients who don't have the modified bytecodes available), and it overly constrains implementors.
For "an acceptable level of detail", please refer to my message on the (other thread.Good article.I am still waiting for someone to explain why JDO 2 is not sufficient for EJB 3 persistence needs. I asked this question more than once in a recent thread and nobody stepped up to the plate. All I got was a little bit of hand waving.I am not hung up on JDO (I have mostly used Hibernate), but I do recognize it as a well established persistence standard for Java objects. The next version addresses some important issues (standardized OR mapping and access to the relational model when necessary - among other things - that I find attractive). Can someone please explain at an acceptable level of detail why the EJB EG chooses to not use the JDO spec? Perhaps there is a very good technical reason, or perhaps egos are simply getting in the way on one or both sides. Could someone please enlighten us? Pretty please with a cherry on top?Regards,Bill
|
|
|
Message #125325
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO and bytecode enhancement
Evan,
Thanks for taking the time to post some of your issues with JDO. A couple of the statements you made have been made obsolete with the developments over the last nine months within the JDO expert group:if you can't do everything (including advanced features) in the JDO spec without bytecode enhancement, then I have a problem with that. FTR, JDO has never required bytecode enhancement as such -- rather, it has required that the domain classes implement the javax.jdo.spi.PersistenceCapable interface and abide by the contracts defined therein.
Additionally, JDO2 relaxes this restriction, allowing implementations to use approaches other than the PersistenceCapable interface to achieve the needs of the JDO spec.It complicates debugging I don't understand this point -- how have you experienced the PersistenceCapable interface / bytecode enhancement to complicate debugging? Debuggers such as JDB and IDEA's remote debugger interface work exactly as expected in my experience, and line numbers / stack traces look right too. Maybe there was a bug in the implementation that you were using?it complicates usage by remote clients using EJB interoperability (serialization of persistent objects to clients who don't have the modified bytecodes available) Nothing in the JDO spec requires that the client tiers have bytecodes that correspond to the server's bytecodes available. In fact, the JDO spec requires that if a source or bytecode enhancer is used for implementing the PersistenceCapable interface, it must be possible to serialize an instance whose class implements PersistenceCapable and deserialize it into the non-PersistenceCapable class version, and vice versa.and it overly constrains implementors Obviously, given my above statement that the JDO2 spec does not require the PersistenceCapable interface, this is not an issue in JDO2 either.
-Patrick
--
Patrick Linskey
SolarMetric Inc.
http://solarmetric.com
|
|
|
Message #125327
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Still waiting...
Evan,
Thanks for responding. We are getting somewhere now (albeit with small baby steps).My #1 answer is: JDO is overly complex. I would suggest that you back up this overly general statement with specific examples. Exactly what is it that you find too complex? I don't see how it is any more complex than Hibernate (honestly).My #2 answer is: if you can't do everything (including advanced features) in the JDO spec without bytecode enhancement, then I have a problem with that. It complicates debugging, it complicates usage by remote clients using EJB interoperability (serialization of persistent objects to clients who don't have the modified bytecodes available), and it overly constrains implementors. Perhaps I am misinformed, but JDO never required bytecode enhancement. It did require implementation of the PersistenceCapable interface, but this is no longer required. Perhaps you meant to say that without bytecode enhancement in JDO 1, transparent persistence would not be possible? Has your objection been adequately addressed with Robin's explanation of JDO 2? If not, perhaps Robin and others can further enlighten us.
IMHO, only items 1 and 2 from your posting in the previous thread look interesting. Perhaps someone from the JDO EG can address each of these concerns.
Thanks again for responding.
Regards,
Bill
|
|
|
Message #125329
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO and Java 2 Standard Edition
Robin,
I think this is one of the obstacles why JDO was slowly adapted.
If standard J2SE had had this "javax.jdo" package preloaded it would get much wider acceptance today.
I guess some developers have an unconscious stereotype that is some technology is not bundled with JDK (e.g. in one download) that they better not to use it...
Therefore this is very important aspect for JDO in order to gain even more popularity
I truly hope that EJB3.0 persistence will be based on "javax.jdo" from J2SE with its own extensions (e.g. security, distributed transactions...)
Kind regards,
Ruslan
|
|
|
Message #125330
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO and bytecode enhancement
Hi Patrick,
If you have the time, could you please respond to Evan's numbered concerns in the previous thread (some of which now appear to be obsolete with JDO 2)?
Regards,
Bill
|
|
|
Message #125331
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Still waiting...
Bill,I have answered in the recent thread with some details. I am a member of the EJB3 expert group, and I cannot answer "why the EJB EG chooses..." since I am only one of many individuals. I can answer for myself.My #1 answer is: JDO is overly complex.My #2 answer is: if you can't do everything (including advanced features) in the JDO spec without bytecode enhancement, then I have a problem with that. I'm not sure if this is the correct forum to get into technical arguments once again, but I'd like to address some of the points you raise and hopefully clarify things a bit. Before I do, though, let me say that I enjoyed the article, and would love to see a single persistence standard that can be used both within and outside of a container. This has been the goal of JDO all along, after all. Hopefully all parties will be willing to compromise sufficiently to achieve it.
Now, on to the tech stuff.My #1 answer is: JDO is overly complex. There is a huge difference between something that is well-specified and something that is overly complex. I have taken the liberty of quoting your enumeration of the supposed complexities below, and responding to them. First, though: My #2 answer is: if you can't do everything (including advanced features) in the JDO spec without bytecode enhancement, then I have a problem with that. It complicates debugging, it complicates usage by remote clients using EJB interoperability (serialization of persistent objects to clients who don't have the modified bytecodes available), and it overly constrains implementors. First of all, no features require bytecode enhancement. In JDO 1, some required implementation of the PersistenceCapable interface (by enhancement or any other means), but that requirement has been lifted in JDO 2, precisely to allow for different implementation strategies. I hope this addresses your concern.
While I'm at it, however, let me point out that enhancement does not complicate debugging. Exception line numbers remain the same. The changes made to bytecode are trivial to follow in a debugger (equivalent to calling a getter method rather than accessing a field directly). And if we're talking about an EJB context, the enhancement would probably be done by the container's classloader, so there wouldn't even be an extra build step.
Furthermore, the concerns about remote clients apply equally well to proxy-based solutions. If detached instances are supposed to throw exceptions when users try to navigate to fields that have not been loaded, then the implementation needs some way to hook into the class. Whether this is through enhancement or proxy generation, the result is that the client needs access to the modified/proxied class.
To address your concerns from the other thread you quoted:(1) Only one kind of primary key. While this would be nice, users really require two kinds: ones represented by one or more fields in their class, and hidden ones managed by the persistence solution. The need for the former type should be obvious. The second type is essential too, however, because often classes don't have any fields unique across all instances. If you start requiring extra fields in the class to be unique primary keys, then you're breaking transparency; the persistence solution should not put these types of constraints on the object model, IMO.
These are the two identity types supported by JDO and pretty much every other decent persistence solution out there. JDO does include one additional type of identity for objects that don't require unique identifiers at all (persistent log messages, for example), but it's an optional part of the spec, and is invisible to users who choose not to use it.(2) Very few possible instance states. There seems to be massive confusion surrounding the fact that JDO uses instance "states" in the spec. Let me try to clarify things: the spec's "states" are just ways of describing how an instance responds to certain questions, such as "have you been changed in this transaction?", "were you deleted in this transaction?", etc. The utility of users being able to ask their objects these questions should be obvious. (By the way, by "asking questions", I mean using the JDOHelper.isDirty(Object), JDOHelper.isDeleted(Object), etc methods).
The transitions between these states in the spec are just descriptions of when an object is allowed to answer "yes" to these questions. I.e. an object cannot tell the user that it is dirty if it hasn't been changed, and can't tell the user it's deleted if it hasn't been. The transitions also serve to show when objects reload their state from the DB; specifying this well is essential to making sure users don't switch implementations and suddenly start getting stale data.
And that's all the states and transitions are. So long as objects can answer the questions correctly, it doesn't matter how things are implemented. And I contend that any good persistence solution allows questions like these. So once again, it's just a matter of things been well-specified, and that is very different from being overly complex. (3) SQL-ish query language, i.e. EJB-QL, and direct SQL access. JDO 2 includes direct access to the java.sql.Connection, and SQL queries (and many relational JDO 1 implementations do already). Whether a SQL-like query language is also warranted in addition to JDOQL is debatable. Suffice it to say that if it came down to it, EJB-QL could easily be added to JDO.(4) Ability to call from EJB session beans, web tier and remote clients with a minimum of fuss, factories, initial contexts etc. You can initialize JDO from Properties, File, InputStream, etc. It can integrate with the Connector system in an appserver. You can bind it to JNDI. It is very flexible, so I don't understand this point. Sorry. (5) Enhancements to EJB 2.1 style entity beans, e.g. dynamic queries, extended EJB-QL. Dynamic queries and query language consistent between EJB 2.X entity beans and 3.X POJO entity beans.
(6) No fancy features that can only be supported by bytecode enhancement.
The FULL "transparent persistence spec" should be implementable without
bytecode enhancement. Already addressed.
I hope this clarifies things a little. I've honestly never heard a user say that JDO is too complex. In fact, most users who give it a shot really like it.
|
|
|
Message #125335
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
-1
Sorry to break this little lovefest.
The premises of this article is patently flawed to me:
1) The EJB3 spec should not implement POJO persistence because
this belongs in a separate spec that applies to both j2se and j2ee.
2) That spec may or may not be JDO
3) POJO persistence in EJB3 breaks backwards compatibilty
Flaws:
1a) Persistence has always been part of the EJB spec in J2EE.
If EJB3 is to define POJOs inside a j2ee container why shouldn't it describe
their persistence?
1b) The EJB spec, despite failed attempts to define it in this thread
applies to ENTERPRISE java beans. What good is POJO persistence in EJB3
without ENTERPRISE features.
2a) If the spec is JDO what are you arguing about? You can download JDO
now and include it in j2se or j2ee. Why haven't people done it?
2b) If it is NOT jdo are you telling me the JDO expert group members
will swallow their pride and join a different expert group for
POJO persistence?
2c) If a separate expert group is formed do you really think it will
manage to produce anything before j2ee1.6? It is certainly too late
for j2se1.5!
3) This is just FUD. Where has anybody said there will be no
backwards compatibilty for CMP2.1 or that the migration path to CMP3.0
is not being considered?
Disclosures:
My name is Adrian Brock (an employee of JBoss Inc).
I do not speak for JBoss Inc in this post.
I am NOT a member of any JCP expert group, which obviously
means I am NOT a member of the EJB3 or JDO2 expert groups.
|
|
|
Message #125342
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
We need a project to put a JDO face on Hibernate
Lets put some simple facade classes and map Hibernate to JDO. That will squish the politics away
|
|
|
Message #125352
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Putting the ENTERPRISE in EJB
Adrian -
I quite agree that we should be putting the enterprise in EJB.
I think that we often get confused with "I write applications in an enterprise" (as in, I work for a Wells Fargo and I write departmental apps) and "I write enterprise applications" (as in, I work for a company which develops ATM software that we sell to Wells Fargo).
I think we need to seperate these two out.
In a truly enterprise application, I often need a real security model (role-based is just not enough folks). I also may need a way to muck with threads in a nice way (let me ask for one from the app server... and not have to muck with J2EE CA), and the list goes on and on.
Let's get on that road and give enterprise developers tools that they have been crying out for.
Transparent persistence has NOTHING to do with the enterprise. It is a cross-cutting concern in many areas. I want to use a transparent persistence API in my mobile phone, my simple swing app, my web site, and my enterprise app. If I need enterprise services above and beyond let the transparent persistence play nice with the enterprise services specs.
Transparent persistence should be in J2SE as much as it should be in J2EE. Let's get past the politics and do it right.
Dion
|
|
|
Message #125353
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
feel better now?
I considered if I should try to be funny by suggesting to standardize the thickness of paper or the use of semicolon but I gave it up as I realized that no matter what it would always be taken dead seriously by this forum.
Regards
Rolf Tollerud
|
|
|
Message #125354
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
-1
Adrian Brock :Sorry to break this little lovefest.The premises of this article is patently flawed to me:
1) The EJB3 spec should not implement POJO persistence because this belongs in a separate spec that applies to both j2se and j2ee.
2) That spec may or may not be JDO
3) POJO persistence in EJB3 breaks backwards compatibilty These aren't the premises of our argument. Rather than rebut directly, lets discuss the claimed flaws.1a) Persistence has always been part of the EJB spec in J2EE. If EJB3 is to define POJOs inside a j2ee container why shouldn't it describe their persistence? You make the assumption that EJB3 is to "define POJOs inside a J2EE container". It isn't. In fact, EJB3 is really about simplifying EJB, which is a component architecture for the development and deployment of component-based business applications (according to the EJB3 JSR). A POJO isn't a component.1b) The EJB spec, despite failed attempts to define it in this thread applies to ENTERPRISE java beans. What good is POJO persistence in EJB3 without ENTERPRISE features. We are advocating that POJO persistence should be available across J2EE and not just in EJB3.
POJO persistence is a "programming style" rather than a specific technology. Generally speaking, it's an API. You can use the approach in any Java application, on any platform, from J2ME to J2EE. (Hibernate is darn popular on J2SE). The enterprise features that EJB are concerned with - scalability, transactionality and isolation - are general concerns that apply to all J2EE techologies, not just EJB. So yes, an implementation of POJO persistence in J2EE would certainly need to incorporate those enterprise features.
For those applications of POJO persistence outside of J2EE, those implementations of the standard API would incorporate those features applicable to their target environement.2a) If the spec is JDO what are you arguing about? You can download JDO now and include it in j2se or j2ee. Why haven't people done it? We've never argued that the spec must be JDO. We've suggested that JDO is a candidate, but we state that the community should decide on the solution. Clearly there is a demand for this - why else is the EJB3 expert group working on it?2b) If it is NOT jdo are you telling me the JDO expert group members will swallow their pride and join a different expert group for POJO persistence? We hope so and from the tone of this thread, they certainly appear to be willing.2c) If a separate expert group is formed do you really think it will manage to produce anything before j2ee 1.6? It is certainly too late for j2se 1.5! Yes, because we aren't advocating tossing everything that the EJB3 group has done, but rather just decoupling it from EJB. We hope it can go fast. Further, by combining the expertise of the JDO and EJB3 expert groups, it should go faster.
One of the changes we're seeing in the JCP is that instead of new technology being developed by EGs from scratch, existing proven solutions are being brought to the JCP to create a specification. JSR-235, SDO, is an example. There's no reason to believe that we couldn't do the same thing here, with Hibernate or the like as a starting point.3) This is just FUD. Where has anybody said there will be nobackwards compatibilty for CMP2.1 or that the migration path to CMP3.0 is not being considered? That really is not what we said. What we said was that there was a continuation of 2.1 and the addition of a new and incompatible POJO model.
- geir
|
|
|
Message #125355
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
We need a project to put a JDO face on Hibernate
Hibernate and JDO have absolutely different goals.
JDO goal is ***transparent persistence***.
Hibernate goal is ***easy persistence***.
These 2 goals are not necessarily the same.
Transparent persistence is actually one of the biggest hypes in J2EE.
I do not want transparent persistence because this idea is plain broken. It does not work and actually was proven wrong by another attempt to implement transparent persistence - entity beans.
I want to see persistence in my code and deal with it.
That's why I use Hibernate and will never use JDO.
If you need JDO, there's plenty of JDO implementations. Do not try to make Hibernate yet another JDO tool.
|
|
|
Message #125356
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
We need a project to put a JDO face on Hibernate
Hibernate and JDO have absolutely different goals.JDO goal is ***transparent persistence***.Hibernate goal is ***easy persistence***.These 2 goals are not necessarily the same.Transparent persistence is actually one of the biggest hypes in J2EE.I do not want transparent persistence because this idea is plain broken. It does not work and actually was proven wrong by another attempt to implement transparent persistence - entity beans. Considering that Hibernate has "Transparent Object Persistence" in the title of the hibernate.org main page, I think you might be mistaken :)
Seriously, JDO and Hibernate are much more alike than different, and neither is anything like entity beans in their current incarnation. Anyone who has used both JDO and Hibernate can attest to their overall similarities, though details might be different.
|
|
|
Message #125357
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO and Java 2 Standard Edition
It would damage all jdo implementations except the
one that is included in the jdk.
|
|
|
Message #125358
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO and Java 2 Standard Edition
I had this stereotype too, but I'm changing my mind
and so I think most people.
|
|
|
Message #125366
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Unified persistence pathways == a Good Thing
The problem, as always, is performance. All O/R mapping tools prevent you from denormalize in a sensible way.
The only solution is to use object oriented databases.
|
|
|
Message #125368
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The next move
Let me predict the next move by the EJB3 expert group:
Because of huge demand for decoupling the persistence mechanism of EJB3 from J2EE we decided to decouple it from J2EE and make it run on J2SE too, but to make it more compeling for big J2EE vendors to sell you J2EE server we also defined some great J2EE addons/extentions to tempt you to tie yourself to J2EE :-)
We of course couldn't even imagine to work with the JDO kiddies, after all we have a clash of cultures/mindsets with them and if we really want to use JDO as the spec we have to rewrite it all to make ourselves comfortable with it :-)
Ara.
|
|
|
Message #125372
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
standard vs standard
3. What EB3.0 will not give that JDO2.0 will give? Hi Abhijit,
You can used JDO today, it's ready.
On the other side you must wait almost 2 years to use the first EJB 3.0 implementation.
|
|
|
Message #125375
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB 3.0 will give the J2EE market to .NET
First, sorry for the bad spelling in my first post, have got a bunch of remarks from my colleagues. I guess it was an unintentional intent to show that I don't speak English every day. :-)With the prevailing (and understandable from a business perspective) attitude of the big server vendors, that would require an act of Sun. I guess you are right. Sun didn't seem to keen on JDO in the beginning, but now it seems that they acutally have accepted the idea. So, there might be hope...I agree wholeheartedly. That is why it was particularly disheartening to see Gavin King's inflammatory remarks against JDO followed by a refusal to back them up with anything substantial, in the recent debate here on TSS. I even believe Gavin has rejected the idea of making Hibernate JDO compliant, so not really much hope of reconciliation from that side. Yes, I also think it was an unpleasant experience. As for Hibernate it seems to be a very good thing, but what I want is an API specification that allows me to use different products as well. The choice of JDO is strategic, whilst the choice of Hibernate or another JDO product is tactical. This debate of Hibernate vs. JDO really puzzles me. Why does it exist at all? What is the problem for the Hibernate guys to make the final adjustments to make Hibernate JDO compatible? Pride in an odd way?
|
|
|
Message #125382
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
-1
You make the assumption that EJB3 is to "define POJOs inside a J2EE container". It isn't. In fact, EJB3 is really about simplifying EJB, which is a component architecture for the development and deployment of component-based business applications (according to the EJB3 JSR). A POJO isn't a component. This is a false conclusion. EJB3 is to define how to build an
ENTERPRISE component from a POJO through the use of "markup".
That is *my* concrete interpretation of the woolly "simplifying" charter.We are advocating that POJO persistence should be available across J2EE and not just in EJB3. POJO persistence is a "programming style" rather than a specific technology. Generally speaking, it's an API. You can use the approach in any Java application, on any platform, from J2ME to J2EE. (Hibernate is darn popular on J2SE). The enterprise features that EJB are concerned with - scalability, transactionality and isolation - are general concerns that apply to all J2EE techologies, not just EJB. So yes, an implementation of POJO persistence in J2EE would certainly need to incorporate those enterprise features.For those applications of POJO persistence outside of J2EE, those implementations of the standard API would incorporate those features applicable to their target environement. I do agree that persistence is a cross cutting concern that applies
outside an EJB container, I don't really see it is an API
except at the query and session management level.
Are you arguing EJB3 should not be allowed to continue its
work because you want the features elsewhere?
It was you who accussed EJB3 of "Mission Creep" when its mission is to 'componentize' POJOs as EJBs and EJB already has persistence in its brief.
Why not also a new spec for state combinding SFSB and web sessions to
create a thirdparty market?
Laudable as these aims might be, we also want j2ee1.5 out in a reasonable
timeframe, something that would be made much harder if EJB3 must wait
for as yet unstarted specs.We've never argued that the spec must be JDO. We've suggested that JDO is a candidate, but we state that the community should decide on the solution. Clearly there is a demand for this - why else is the EJB3 expert group working on it? I know you didn't argue for JDO (only suggested it). That is why I prefixed
the sentence with "If" and then considered the alternate.
I also admit there are other alternates you or I did not consider.Yes, because we aren't advocating tossing everything that the EJB3 group has done, but rather just decoupling it from EJB. We hope it can go fast. Further, by combining the expertise of the JDO and EJB3 expert groups, it should go faster.One of the changes we're seeing in the JCP is that instead of new technology being developed by EGs from scratch, existing proven solutions are being brought to the JCP to create a specification. JSR-235, SDO, is an example. There's no reason to believe that we couldn't do the same thing here, with Hibernate or the like as a starting point. Again, to avoid overlap you have to consider the JDO EG dropping JDO2
in favour any new JSR that meets the needs of everybody.
I am not privy to JDO2 so I can't comment on whether it meets the needs
of the EJB3 EG.
We can assume EJB3 considered JDO, and I know at least one member was
privy to JDO2 :-)That really is not what we said. What we said was that there was a continuation of 2.1 and the addition of a new and incompatible. You assert this without any evidence, a common characteristic of FUD.
"They don't talk about it like this, but it's a reasonable interpretation"
In conclusion, I am not dismissing your proposal, only that the
premises of your argument and in some places the way you reach your
conclusions are flawed.
I also admit that my critique is largely procedural rather than technical.
Regards,
Adrian
|
|
|
Message #125386
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB 3.0 will give the J2EE market to .NET
Johan:Sun didn't seem to keen on JDO in the beginning, but now it seems that they actually have accepted the idea. That is because JDO didn't take of, so they do not fear it anymore.
The whole idea with EJB 3.0 is really only to save the Java Server vendors from going out of business, every time they publish a new EJB version they bash the old version, and the next year they bash this years version and so on. Now a new version is expected to come out in two years but until then it will be too late.
Look, BEA stock drops 23% in spite of having a new product (WebLogic 8.1) on the market,
EJB 3.0 tries to incorporate ideas from Hibernate & Spring, but why not use the real thing? Everywhere there are reports that developing in Spring/Velocity/Hibernate is a breeze, with happy customers. Add JSF to the mix (once they work without JSP), and you have a clear winner. Can't wait until the C# version!
The Big EJB Servers can be regarded as legacy systems that are to expensive to replace. Cornelius Willis, BEA. "The customers are so much less interested in deploying new applications or coding new apps."
http://www.idevnews.com/IntegrationNews.asp?ID=118
So no is the question how to integrate with SOA/Web Services etc.
BTW, one of the best tools for doing this is Mainsofts Visual MainWin for the J2EE platform. Either Java to Java or .NET to Java. It is an eerie feeling to able to reference Java libraries inside Visual Studio (even EJBs), and to see Tomcat appear in IIS!
Regards
Rolf Tollerud
|
|
|
Message #125389
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
OJB Pojo Persistence
Hey all,
Check out the Apache Object Relational Bridge project. I think it accomplished the goal.
http://db.apache.org/ojb/
As a side note, there have been some discussions with the Springframework folks about a OBJ / Spring integration.
|
|
|
Message #125391
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
"High Complexity is sign of technical imaturity"
I could not get over the part that complexity was not the main problem.
It is a culture probelm for Java that writing complex solutions is pride.
Reducing complexity for complex applications should be the goal.
As far as persistance, why help Sun w/ JDO/EJB? Why not fix JSF? We still have sql.Date and util.Date and Calendar, many ways of doing a date, and we pick a chose. This to me are JCP propriatery standards, only JBoss is helping Sun, we have open stanards where popluatiry voting implementation wins out. (None of this an apointed King, we elect a a defacto standard).
We can use Hibrenate and I think iBatis is simple.
Simple to me means powerfull.
I hope Tate,Johnson and others would agree that complexity= bad (and that Sun will just go out of business, and we can't help them for sentimental reasons)
.V
|
|
|
Message #125398
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
"High Complexity is sign of technical imaturity"
Well said Vic. The proliferating number of API is making the Java platform pretty daunting. And the proliferating number of frameworks (Struts, Tapestry, WebWorks.. you name it) is fragmenting the community. Instead of making it easy for Java developers and tough for the competition (M$), we've made it tough for the developers (no one can develop deep expertise in all the frameworks; no one can go beyond the frameworks (higher up the food chain)because its a 24x7 job to just keep up with the latest in all these frameworks). Microsoft is having a ball because now its .NET vs a whole bunch of me-too frameworks with their cohorts following with religious fervor.
I wish the JCP stopped developing API and instead Sun for once took on the task of comming up with a unified IDE spec. Eclipse is good, but I'm talking about specs for API + IDE components. This way, people will have a plug-n-play mechanism for development tools (so we don't have Oracle JDeveloper, Eclipse, Weblogic Workshop and another 100 me-too IDEs). It would be great to be able to select API spec and IDE components that make life easy and use those to build apps. The learning curve will be reduced and my ratio of writing core business logic vs. interfaces and methods to comply with the spec will increase.
|
|
|
Message #125404
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Huh?
The problem, as always, is performance. All O/R mapping tools prevent you from denormalize in a sensible way.The only solution is to use object oriented databases. I didn't see any winking smiley faces, so I assume this is a serious post. So let me ask...are you SERIOUS?
|
|
|
Message #125406
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
how bout freedom of choice?
I do not quite agree that pojos and ejb solve different problems. They solve the same problem, that is persistence. They are very different problems, the main reason for EJB is to simplify RMI, only one of the four types of beans is related to persistence. If distribution isn't an issue (perhaps you're only using local interfaces), then there is little reason to use EJB over a portable framework like Spring.
Yeah, but these days the remoting capability of entity beans has become recognized as a distinct anti-pattern. It was a bad idea.
I'd prefer that J2EE strive to go in a direction of persistence neutrality and instead define a basis as to how persistence components can be integrated. Then specs like JDO 2.0 or "defacto standards" like Hibernate could be used alike from J2EE - and still be usable standalone, of course.
To a degree this has already been done and would be a modest work for EJB 3.0 folks to finish formalizing this approach.
But ever notice how folks are reluctant to permit others to have freedom of choice, but instead are far more determined to see that others do it their way?
In general that has been a spirit of Java. The J2EE has become an exercise of trying to impose a one-shoe-fits-all "standards" specification.
|
|
|
Message #125418
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
re: how bout freedom of choice?
IMHO, I think J2EE should only specify a minimal interface for all of these declarative crosscutting services (security, persistence, etc.). This would benefit the vendors in allowing them to have more offerings. It would benefit the customer in allowing them to purchase customized services at a higher level of granularity. For example, one customer may develop a persistent J2EE app where they have complete control of the database. They can just do a 1-1 mapping so they only need a very simple persistent service. Another customer may be stuck where they need all the joins and complex mappings, they can buy the more complex persistence service. From the J2EE perspective these services just need to support the same minimal interface. Pluggable services seems to be the key.
|
|
|
Message #125422
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
freedom of choice
Well, at least the J2EE developers have a better understanding of the Microsoft mentality, do it our way, yours is wrong even if it's right.
|
|
|
Message #125430
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
"High Complexity is sign of technical imaturity"
[...]
I wish the JCP stopped developing API and instead Sun for once took on the task of comming up with a unified IDE spec. Eclipse is good, but I'm talking about specs for API + IDE components. This way, people will have a plug-n-play mechanism for development tools (so we don't have Oracle JDeveloper, Eclipse, Weblogic Workshop and another 100 me-too IDEs). It would be great to be able to select API spec and IDE components that make life easy and use those to build apps. The learning curve will be reduced and my ratio of writing core business logic vs. interfaces and methods to comply with the spec will increase. Zero chances for that. Simply becouse components needs container and every major ide uses different container. E.g. Netbeans is using Java Beans, Eclipse is using OSGi. Every container provideds different component ecosytsem, different services etc. Standarization in this area will be really possible only if standarization of container API will occur. And this is unlikly to happen in next few year simply becouse people are afraid of containers and every attempt to standarize something around container spec causes a lot of crying in java community (see opinions of all those people which want to use EJB Session Beans
outside any container!). EJBs failed becouse they were trying to predict many things and design up front distributed component specification while well established methodology for developing distributed components in Java was not existing. Nor were methods for enabling "transparent persistance".
And premature standarization is scary. I wonder how people can participate in EJB JCP an try to find standard ways for using annotations (aka metadata). Nobody in Java community have rich experince with them and the proper usage patterns are yet to be discoverd. The same aplays to "lightweight containers", AOP and many other things. Any attempts to standarize it now are simply not wise IMO and chances that they will do it right and their choice will be valid in few years are closer to 0% then 100%
Microsoft did a good job to catching up with Java and not repeating the same errors. But when you inovate things are getting harder and error are inevitable
Michal
|
|
|
Message #125436
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Still waiting...
Abe,
You wrote:First of all, no features require bytecode enhancement. In JDO 1, some required implementation of the PersistenceCapable interface (by enhancement or any other means), but that requirement has been lifted in JDO 2, precisely to allow for different implementation strategies. I hope this addresses your concern. Now section 20.13 "Modified field access" in the JDO 1.0 spec reads:The enhancer modifies field accesses to guarantee that the values of fields are retrieved from the data store prior to application usage. For any field access that reads the value of a field, the getfield byte code is replaced with a call to a generated local method, jdoGetXXX, which determines based on the kind of field (default fetch group or not) and the state of the jdoFlags whether to call the StateManager with the field number needed. Is JDO 2.o proposing to "obsolete" this guarantee? If not, please explain how it can be achieved without bytecode enhancement.
|
|
|
Message #125444
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Still waiting...
The enhancer modifies field accesses to guarantee that the values of fields are retrieved from the data store prior to application usage. ... Is JDO 2.o proposing to "obsolete" this guarantee? If not, please explain how it can be achieved without bytecode enhancement.
How is this guarantee achieved in Hibernate? How is it achieved is persistence framework X? That's how it will be achieved in JDO 2.
Different products have different ways of handling state loading. For example, one strategy is to always load all fields when an object is retrieved. Primitives and simple types are loaded with their database values. Relations and container types might be loaded with proxies that only read their state when they are accessed.
Different strategies involve different compromises. The compromise involved in the strategy named above is that you can't lazy-load primitives and simple types. Enhancement can lazy-load all types (among other advantages), but the tradeoff is having to use a custom classloader or extra build step to process the bytecode. In either case, though, the user-visible behavior is the same.
I hope that answers your question.
|
|
|
Message #125451
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Putting the ENTERPRISE in EJB
Transparent persistence should be in J2SE as much as it should be in J2EE. 100%.
I think, it must have been made a part of J2SE long ago...
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
