Home

News: Politically Charged EJB Decision Hands a Victory to JBoss

  1. The EJB expert group's decision to use Hibernate as the persistence mechanism in EJB 3.0 gives JBoss all the power. David Jordan, a member of the JDO expert group, explains why the JDO community is not just disappointed—but concerned—about a power shift in the app server market.

    Excerpt:JDO Isn't Just for Object Databases
    Since the JDO 1.0 release, JDO has gained about 20 relational and three object database implementations. Most of the JDO applications being developed today are targeted for use with a relational database. However, the EJB community is trying to marginalize JDO by associating it with object databases:

    • Ed Cobb, VP of Architecture & Standards at BEA, voted against JDO, saying its "market acceptance is essentially constrained to use with object databases."
    • Oracle also has been telling everyone that JDO is only for object databases. During last year's JavaOne conference, I attended a presentation titled "Container Managed Persistence: Beyond the Specification" in which Oracle's Sastry Malladi told his audience the same thing.
    • At the recent May meeting of the Triangle Java User's Group in Research Triangle Park, N.C., Gavin King, the architect of Hibernate, stated that JDO is "a solution for flat files and object databases—and, oh yes, there are a few relational implementations too." As a participant in the JDO 2.0 expert group, King knows there are many relational JDO implementations.
    • At this same meeting, Marc Fleury presented a slide stating "Hibernate is focused on ORDBMS, unlike JDO."
    The full article: Politically Charged EJB Decision Hands a Victory to JBoss

    Editorial Note: The purpose of pointing to articles is to give us a place to discuss the content. When we post an article the views are that of the author and not of TheServerSide.com.

    From talking to some of the EJB expert group, EJB 3.0 isn't going to just be a spec based on Hibernate. They will of course take good ideas from leading implementations.

    Threaded Messages (107)

  2. Am I being thick?

    Surely EJB3 is a spec and Hibernate an implementation.

    Please could someone explain what the EJB group are doing specifying the persistence implementation that all compliant app servers must use. It must be up to the developer, surely? What if my entities aren't DB-based?

    Regards
    Kit
  3. JDO the good guys[ Go to top ]

    Despite what have really been unfair and extreme statements from prominent members of the EJB group (like calling JDOQL an "abomination"), the talk from the JDO group continues to be of inclusion and cooperation. JDO has apparently been weathering political storms its entire life, but it has great stewarship. I think JDO's greatest strength is that it is *not* being pushed by entrenched players, but by clear thinkers who have had time to reflect on both the strengths and weaknesses of existing technologies. I believe JDO to be a true reflection of what can be accomplished through the JCP.

    -geoff
  4. I personally think this is a good decision considering the success of hibernate. Surely saves me a lot of time trying to see what the new EJB3.0 spec states and what to do with the old code. We standardized on hibernate after learning our lessons the hard way(CMP anyone?)... and this one I will take home to get some extra sleep anytime!

    No wonder the second highest rated plugin for eclipse happens to a plugin called the hibernate synchronizer- which shows a lot of people are actually using hibernate already.
    http://www.eclipse-plugins.info/eclipse/index.jsp

    Nice work JCP! Big win for the java open source community.
  5. I would just like to see the Enterprise Java Bean container and its principals drive the development of new persistence O/R or O/O mapping specs and not
    the database vendors. We are buying J2EE application servers, not databases.
    A clean seperation is needed here, with specs complying to database independance and source portability.
  6. I programme critical systems with EntityBeans against AS/400 from 1999.
    The choose for EntityBeans in that epoch was because it was
    the only standar for object persistence in the moment.

    I have used neither Hibernate nor JDO ever, so I believe that I am more
    impartial that others. It's fantastic that there is a new standard of persistence in Java,
     but not more. There are reasonable solutions to this problem, for example:
    - To use JDO2 as standard of persistence of EJB3.
    - And if Hibernate is so good to make that JDO2 seems to Hibernate.
    Another solution would be:
    - Not to define any standard of persistence for EJB3.
    - To define in EJB3 the integration with JDO and Hibernate.

    As for JBoss's interest of using Hibernate for EJB3 is obvious:
    Time to market for JBoss 5.0 with EJB3 support very short.

    If a standard of persistence is created for EJB at margin of JDO is easy a war, and the war is bad for all.
    And If Apache OJB or Speedo start to produce good results... A hard war.

    Peace

    Javier Paniza
  7. More FUD Slinging[ Go to top ]

    I find it humorous that David Jordan complains left and right about Gavin King, Marc Fleury, and others spreading FUD on JDO... yet he then drops these choice statements:
    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.
    and
    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.
    Anyone who has ever used Hibernate can tell you that those statements are just plain BS. It certainly possible, and without much work, to write Hibernate code that is portable across databases.

    It would be nice if all of the these Hibernate FUDers and JDO FUDers would actually use the competing product before making false technical criticisms about them.
  8. More FUD Slinging[ Go to top ]

    Chris, we post our replies at the same time :))

    I totally agree with you:

    Look like big guys - Fleury and overs start play typical marketing
    things! JBoss guys say FUD, JDO guys say fud. Everybody!

    I want to say - if they all will talk the same style, they very quickly loose all there respect. We are developers, not housewifes.
  9. More FUD Slinging[ Go to top ]

    ... We are developers, not housewifes.
    What is wrong with being a housewife?
  10. back from vacation[ Go to top ]

    I just got back from vacation, I have been away from the Internet for over a week. I'd like to clear up some confusion I have caused.

    When I attended the presentation given by Gavin King and Marc Fleury in Raleigh on May 17, I did not know anything about Hibernate. I arrived at King's talk about 10 minutes after he began speaking, so I missed his introductory statements. The message King presented while I was there included the following points:
    1. HQL looks like SQL.
    2. It should look like SQL, so the developer knows exactly what SQL is being executed against the database.
    3. He also criticized JDOQL for being different from SQL.
    His presentation seemed to really emphasize that the query language of Hibernate is SQL. Since I had never used Hibernate, I assumed he was describing the current Hibernate interface.

    Unfortunately, Gavin King's presentation is not available at the trijug.org web site, but Marc Fleury's subsequent presentation is provided. There are a few items in Fleury's presentation that hint of things that Gavin presented. You can download Fleury's talk.

    On Fleury's Slide 16: EJB 3.0 Transparent Programming
    It says the following:

    Simple and Powerful QL:
    * from EJBQL to HQL back to EJBQL again
    * Support for group-by, explicit inner and outer join, projections,
       bulk update and delete, dynamic queries, SQL queries
    * Close to HQL, SQL focus, ORDBMS focus unlike JDO

    On slide 44: JBoss Hibernate
    Hibernate IS EJB 3.0 CMP
    Hibernate is the actual persistence engine

    So the query language presented as being used for EJB 3.0 is "close to HQL, but with a SQL focus". Again, Gavin King really emphasized the SQL nature of Hibernate in his talk. Now, in hindsight, it seems to me that Gavin was NOT presenting the current Hibernate interface, but was presenting the future EJB 3.0 query language. Having his original slides from May 17 posted on the trijug web site would help clear this up.

    Before my article got published, I left for vacation. I had been very surprised at the SQL emphasis in Gavin's talk. So I got the new O'Reilly book on Hibernate to read while on vacation. I got really confused when I read the book. The Hibernate that Gavin presented did not seem to match the Hibernate described in the book, specifically relative to the query language.

    All I can guess is that the very SQL-oriented Hibernate that Gavin presented is part of the EJB 3.0 plans, but not part of the current Hibernate interface. The fact that he was presenting the philosophy that queries should be SQL based gave me the understanding that applications written to Hibernate would tie them to a particular DBMS. That's why I gave the example of being locked into MySQL, with the assumption that the developer was issuing MySQL-specific SQL.

    Now that I have read the Hibernate book, Gavin King must have been presenting plans for a new Hibernate that will be part of EJB 3.0. But I really don't know for sure.

    I had absolutely no intention of misleading the market about the current Hibernate interface. I assumed that Gavin was presenting the Hibernate of today when I wrote the article. I have no intentions of misleading the market or spreading FUD about Hibernate. I mistakenly based my understanding of Hibernate on Gavin's presentation on May 17.

    My apologies to the current Hibernate community for any misleading information.
    I was warned not to read this thread, apparently some people said some very bad things about me. I have not read any commentary after "More FUD Slinging", nor will I read it.

    I have also heard from many parties this week that prominent folks in the EJB community are stating that Hibernate is not the basis of EJB 3.0. Until we get a definitive specification from the EJB 3.0 expert group, I guess none of us will know for sure.
  11. in my opinion, this was the worst thing one could do for the future of J2EE, I like Hibernate, that is not the point, but Fleuruy is in charge of it now, it could became a big thing for Bil Gates team.
    and no one who voted against JDO used any truth thing as an argument, most of the JDO implementations use an RDBMS backend, and the Expert Group is commited to suport it bether in the 2.0 version of the spec.
  12. in my opinion, this was the worst thing one could do for the future of J2EE, I like Hibernate, that is not the point, but Fleuruy is in charge of it now,
    In case you weren't aware of it, J2EE is far larger than EJB which is (IMO) the part that's least useful...
    Personally I'd not mind much loosing it in its current form.

    I DO agree leaving a single appserver vendor (JBoss Inc, who are not known for their sound business practices) in charge of the future of a core platform of another vendor (Sun Microsystems) which is supposed to be an open platform is a proverbial Bad Thing.

    Nothing against or for Hibernate, I've not used it so can't form an opinion.
  13. Very strange article[ Go to top ]

    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.
    Aren't article writer ever see Hibernate?
  14. Very strange article[ Go to top ]

    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.
    Aren't article writer ever see Hibernate?
    Must not have. At my last project (where I introduced Hibernate) we had DB2 on our desktops for development and Sybase on servers for Test/QA/PROD using the same codebase and only making a few line change in the properties file. We also were able to test against MySQL by changing the properties file. Then we switched to DB2 Mainframe from Sybase. We had to change the mappings because the table, column names were not allowed on the Mainframe. Took very little time (the time to type it all in).
  15. article is OK[ Go to top ]

    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.
    Aren't article writer ever see Hibernate?
    Must not have.
    You are reading these lines out of context. Author's point is that you can lock easily Hibernate into specific DB.
  16. article is OK[ Go to top ]

    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.
    Aren't article writer ever see Hibernate?
    Must not have.
    You are reading these lines out of context. Author's point is that you can lock easily Hibernate into specific DB.
    Nope. It is in context. I just re-read it. He talks about vendor lock-in throughout and that use of Hibernate. I think he is confused, misinformed and/or really upset (He provides JDO consulting services).
  17. article is OK[ Go to top ]

    oops. Cut and paste error. Ingnore the last half of the unfinished sentence.
  18. article is OK[ Go to top ]

    I guess now you'll have to get down on your knees and apologize in front of the entire JDO community ^^

    Peace (dans un violon)
  19. article is OK[ Go to top ]

    You are reading these lines out of context. Author's point is that you can lock easily Hibernate into specific DB.
    No, you can't. Well, it's no so easy at least :). On the other hand, You can 'easy' hook to your favourite EJB container, so for me Author's point is weak.

    Artur
  20. article is OK[ Go to top ]

    If you can't lock easily into using a specific DB with JDO, then I won't use it. It has to be an option. Although I said that about pointers too. Maybe someday query optimization won't matter. But for the 10% of the time that still needs it, there has to be the option.
  21. Article !OK[ Go to top ]

    The analisys and conclusions from the article author David Jordan is of no value, as he demonstrates little understanding about how Hibernate works.

    Maybe he does not know Marc Fleury, but this man enjoyes provoking. David Jordan has responded just like he wanted, and given JBoss a lot of free PR. Is the editor of DevX at a holiday? Jordan is just a bull chasing a red cloth.

    I will be very surprised if EJB 3.0 is locked to a implemention with Hibernate, but because this O-R tool is very widespread and proven already it may be the most used implementation.
  22. This is a post to declare this site is no longer worthy of posts. The headlines and news items are cheap and worthless.
  23. I didn't think that the EJB 3 announcement said that they were going to "use Hibernate" (which would be impossible for most of those vendors due to the LGPL license anyway) but that they were taking a whole bunch of ideas from Hibernate. In other words, they saw the growing popularity of Hibernate and decided to learn something from it, which I see as a very positive thing.

    Anyway, a couple of quick points:

    1. Don't buy the marketing. Use Hibernate or EJB or JDO because it helps to solves your specific problems, not because you saw it on PowerPoint. Each has their uses, even Entity EJBs ;-)

    2. Hibernate evolved well because Gavin was determined to solve real world problems that he had personally suffered through. While it isn't "standardized," I think it's earning a different set of stripes. Hibernate _does_ have traction in the marketplace, and even though Gavin did a good job marketing it, it helps that it works pretty well.

    3. We're seeing a good number of successful JDO projects, and quite a few in development. While there's a bunch of political nonsense going on, companies are using JDO, and most that I've talked to quite like it.

    It appears that JDO will have the first true ORM standard for Java and J2EE developers, and that EJB will not be far behind with a different ORM standard for J2EE developers. Maybe that will be very redundant in the end, or maybe they can leverage each the other. Either way, it's long been a sore spot that there was no ORM standard for Java, so I see it as "better late than never."

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  24. Very Disappointed[ Go to top ]

    It appears that JDO will have the first true ORM standard for Java and J2EE developers, and that EJB will not be far behind with a different ORM standard for J2EE developers. Maybe that will be very redundant in the end, or maybe they can leverage each the other. Either way, it's long been a sore spot that there was no ORM standard for Java, so I see it as "better late than never
    Cameron - Please don't take my comments below as an attack on you personally. I need to blow some steam off...

    I find your comments here a bit odd. Whether you like JDO or not, it is the first true ORM standard for Java AFAIK - there is no appearance here. Furthermore, EJB entity beans are *way* behind and have been marginalized for the most part by excellent frameworks like Hibernate, Toplink, various JDO implementations, etc. It appears now that the EJB expert group has decided to create a competing ORM standard for Java (with the annoying limitation of requiring an EJB container and being tied only to relational databases). To date, I haven't seen a convincing argument for why JDO is not being leveraged (especially version 2) and further improved. But then again, I don't think the principles involved could actually have a serious discussion without their egos and resulting FUD getting in the way.

    Frankly, I am beyond annoyed and extremely disappointed. Thanks a lot folks - so much for standards. Let's keep playing the "mine is bigger and better than yours" game while the Java community suffers. There is definately redundancy and it is definately not welcome! I think I'll try submitting a proposal for a new JSR entitled "Bigger and Better ORM for Java." We could use BABOF for short.

    Am I the only one that feels this way?

    Best regards,
    Bill Willis (dazed and confused)
  25. Bill - Agreed...[ Go to top ]

    I can't help but think that Anti-JDO movements are being pushed by the monolithic RDBMS players - it puts an artificial barrier to entry for using an OODBMS. The I-mismatch between powerful object graphs for modeling complex problems and the storage mechanism(s) (currently RDBMS-dominated) doesn't make my job as a developer any easier.

    Best,

    John Dale
    MS MIS, December 2005
    The Eller College of Management
    The University of Arizona
    Tucson, Arizona
  26. Hibernate Technology[ Go to top ]

    Hello Everyone

    People who are tuned in to the JDO "versus" EJB 3.0 debate will no doubt have noticed an abject lack of statements from recognized JDO experts and proponents in support of David Jordan's article. There is good reason for this.

    Until today the JDO community has been the target of FUD, but generally not a source of it. We have fought political battles with carefully studied and researched technical argument. As an independent (i.e. not vendor-aligned) member of both JSR-12 (JDO 1.0) and JSR-243 (JDO 2.0) I have endeavoured to evangelise JDO's cause to the community. I was certainly forceful in my arguments on the three JDO/EJB threads at the time of the TSS Symposium, but even then I tried to be as technically accurate and personally inoffensive in my remarks as possible (which was hard given that most of the available material on EJB 3.0 could best be construed as "marketing" material). Since that time the JDO expert group has been galvanized into action. We hope to publish the minutes from our recent Cannes meeting soon with the draft specification to follow before JavaOne.

    I fear that David Jordan, in his article, has gone a step too far. Some carefully placed adjectives could have mitigated the FUD accusations which are now being aimed at the JDO community, but David's language really was quite black and white.

    Some things are clear. Hibernate targets jdbc-compliant datastores (which realistically means relational databases in most cases). Hibernate does NOT inherently lock a user into one SQL dialect. Certainly the user has access to low-level features which could be database-specific, but the user has the choice to use such features. And anyway, similar capabilities have been engineered into the JDO 2.0 spec through a standard mechanism by which the underlying datastore connection can be exposed to the user if required. It is unfortunate that David made these statements in such strong language.

    From reading the blogs from the TSS Symposium it is also evident that the message received by many delegates (if not the message intended by Linda) was that the similarities between EJB 3.0 POJO-Entity Beans and Hibernate were astonishing.

    Other things are less clear. How much influence do JBoss and Marc Fleury / Gavin King actually have on JSR-220, an expert group into which the key JDO players have no insight? How does JSR-220 as a group react to comments by JBoss that moving to JBoss/Hibernate today eases the transition to EJB 3.0 POJO-Entity Beans? How does JSR-220 reconcile the perception, albeit incorrect, that they are dropping datastore paradigm independence and moving towards a persistence model that appears tied to the relational model, when early EJB versions spoke of "legacy data access", "EAI" and "pluggable persistence managers"? All these questions are valid. In due course they may be answered as Scott Crawford and others within JSR-220 facilitate the dissemination of technically sound material.

    It is my hope that the specification leads of JDO and EJB will find ways to exploit synergies between the technologies. JDO is certainly not about to go away. Only the specification leads (or others authorised thereby) can officially speak on behalf of the respective expert groups. However I know that many in the JDO community will agree with me when I personally state that I am troubled by the apparently unfounded accusations levelled at Hibernate's technology here today.

    Kind regards, Robin.
  27. Long live the relational database[ Go to top ]

    For 20 years besserwissers have been pushing the lame idea of Objectdatabases which is good only for picking one (1) object from the database and that breaks down immediately in any kind of joins scenario.

    Today, even to be slightly associated with OODBMS (you know somebody which sisters second cousin's x-husband is working with it) is enough to shunned by everybody like a pariah. ;)

    Regards
    Rolf Tollerud
  28. Very Disappointed? Why?[ Go to top ]

    Bill: Cameron - Please don't take my comments below as an attack on you personally.

    I don't take much of anything personally. This is an excellent forum for stating opinions and discussing what's going on with these technologies.

    Bill: I find your comments here a bit odd. Whether you like JDO or not, it is the first true ORM standard for Java AFAIK - there is no appearance here.

    I do like JDO. (As an aside, I also like Hibernate, and [at times] I even like entity EJBs.)

    However, JDO is not an ORM standard. The ORM portion of JDO got booted out of the JDO 1.0 effort for a variety of reasons, some of which were possibly "political."

    JDO 2.0 will include the standardization of ORM for JDO.

    So, while JDO (even 1.0) is a natural place for ORM to be standardized, the actual ORM approaches -- while similar across multiple JDO products -- are not based on a standard.

    Bill: Furthermore, EJB entity beans are *way* behind and have been marginalized for the most part by excellent frameworks like Hibernate, Toplink, various JDO implementations, etc.

    The "marginal" accounts that we see EJB entity beans being used in are often referred to as "the Fortune 1000" etc. They may be overkill for some apps, and they may not be the simplest way to work with databases, but they are definitely widely used.

    Bill: Frankly, I am beyond annoyed and extremely disappointed. [..] Am I the only one that feels this way?

    Based on the article that started this thread, no I do not think that you are the only one that is annoyed.

    However, I don't think that we need one uber-standard for data access and ORM (look at the mess that Microsoft is making with .NET data access to understand what I mean.) Entity EJB serves a particular (albeit lucrative) niche -- and being applicable to maybe 5% of apps out there, it is definitely a niche. JDO and Hibernate serve a much larger portion of the market -- basically starting at the J2ME level (for some JDO implementations) and going well up into the J2EE level. And of course an amazing number of apps just use JDBC directly ;-).

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  29. Spin, Spin, Spin...[ Go to top ]

    I do like JDO. (As an aside, I also like Hibernate, and [at times] I even like entity EJBs.)However, JDO is not an ORM standard. The ORM portion of JDO got booted out of the JDO 1.0 effort for a variety of reasons, some of which were possibly "political." JDO 2.0 will include the standardization of ORM for JDO. So, while JDO (even 1.0) is a natural place for ORM to be standardized, the actual ORM approaches -- while similar across multiple JDO products -- are not based on a standard.
    Well said. I used entity beans initially, but I got tired of flattening and gutting my domain models to make them work. If a domain model was not really appropriate, entity beans were overkill - simpler (more easily tested) methods existed. EJB entity beans quickly became a solution looking for a problem.
    Bill: Furthermore, EJB entity beans are *way* behind and have been marginalized for the most part by excellent frameworks like Hibernate, Toplink, various JDO implementations, etc.

    Cameron: The "marginal" accounts that we see EJB entity beans being used in are often referred to as "the Fortune 1000" etc. They may be overkill for some apps, and they may not be the simplest way to work with databases, but they are definitely widely used.
    Entity beans were certainly all the rage recently (ages ago in software terms). Even so, I doubt entity beans were ever more popular than straight JDBC. Enter Hibernate and the ever-increasing realization that EJB entity beans were overkill for most (not some) applications. Where entity beans were (and still are) used in practice, they merely reflect the underlying relational model (usually one entity bean mapped to a table). Entity beans were sold as something entirely different. This bad practice has been encouraged by J2EE app server vendors for a while now, and it will take time to undo the damage. Now we are faced with competing object mapping standards, so it looks to me like the Java community is being mislead again.

    And remember, marginalization is not just in terms of usage. I was actually speaking in terms of object mapping technology. Here entity beans are a dismal failure (unfortunately). They can't even support the simplest of domain models.
    Based on the article that started this thread, no I do not think that you are the only one that is annoyed. However, I don't think that we need one uber-standard for data access and ORM (look at the mess that Microsoft is making with .NET data access to understand what I mean.)
    Just to be clear, I was annoyed before this article came to be. I am disappointed the same is not true of you and others. But back to my main point here (that you never addressed). Why do we need two JCP-endorsed standards for ORM? The "uber-standard argument is a cop out. We all know there will be major overlap between them.

    Not only do I have to worry about lock-in at the implementation level, but now I have the same concern at the spec level. Yikes!
  30. It appears now that the EJB expert group has decided to create a competing ORM standard for Java (with the annoying limitation of requiring an EJB container and being tied only to relational databases).
    Actually you can make Hibernate or EJBx work with OODBs too. In case of Hibernate for example, you only need a JDBC driver for the OODB and a dialect class. Most OODB vendors provide JDBC and even ODBC drivers! Besides I myself once wrote a simple JDBC driver for flat files! So it's quite doable though you won't have full OODB functionality (you won't with JDO too).

    So imho this "EJB3 is tied to RDBs" argument is false.

    Ara.
  31. Sorry Ara, but I disagree. The JDBC abstraction level is inappropriate for object databases. JDBC support can be provided, but it is unlikely to be complete or efficient against non-relational back ends.

    JDO defines the behaviour of Java objects which have persistent state that lives beyond the lifetime of the JVM in which they were created. Such state is called "persistent" state, and the term we use to describe this management of persistent state in Java objects is "object persistence". Note that "object persistence" does not necessarily mean "to an ODBMS".

    JDO's definition of lifecycle transitions and queries was done in such a way that the result could be efficiently implemented in both the relational database space and the object database space. Hibernate, however, was designed above the JDBC abstraction in order to facilitate the management of Java objects against relational databases, and I do not think an efficient Hibernate implementation could be easily achieved against complex but non-relational databases.

    Kind regards, Robin.
  32. Paris and the Java community[ Go to top ]

    Robin: Hibernate however, was designed above the JDBC abstraction in order to facilitate the management of Java objects against relational databases. (Which is a thousands times more common. My comment.)

    And that is the reason why Hibernate won out. I doesn't always pays to overcomplicate things.

    Or to quote Honoré de Balsac,

    "Paris does not always lift mediocrity to the sky".

    Regards
    Rolf Tollerud
  33. Paris and the Java community[ Go to top ]

    Hi Rolf,
    Robin: Hibernate however, was designed above the JDBC abstraction in order to facilitate the management of Java objects against relational databases. (Which is a thousands times more common. My comment.)And that is the reason why Hibernate won out.
    Of course not. Hibernate's success #1 reason is because it is free. Today there's no usable free JDO implementation. The only JDO implementations used in production today are non-free.
    I doesn't always pays to overcomplicate things.
    I would be curious about the "overcomplicate things" you see in JDO, especially when comparing with Hibernate. Maybe are you arguing that the "simple thing" you like is something closer to the relational paradigm you are familiar with (like the "join" syntax in Hibernate queries) ? Is that what you call abstraction ? Let's be serious, this is just reproducing the paradigm you should try to hide.

    In my opinion you should keep in mind that the language your are using is Java, and that overcomplicating things is more likely introducing a new query langage and programming constraints than using a Java predicates-based query langage and a lot more less programming constraints.
  34. something new is needed[ Go to top ]

    Ok, have to apologize. I was not notified that the JCP commitee now is able to produce a specification that is not over-compliated. That certainly is big news!

    Anyhow, will Spring and the other lightweight frameworks save J2EE in time?

    When you search the job-sites you find that Java developer demand is about twice that of .NET developers, but that doesn't take into account maintenance work. (for example there also an horde of programmers working with Cobol).

    If you look only at new projects, you get a different result:

    5/5 2004. According to a study by Forrester, 56% of enterprises surveyed will be using the .NET Framework as their primary development environment in 2005. The remaining enterprises will be using Java as their primary development environment.

    "Nobody using it"

    So, the old Big Java EJB Servers are slowly destroying the market.

    Regards
    Rolf Tollerud
  35. something new is needed[ Go to top ]

    According to a study by Forrester, 56% of enterprises surveyed will be using the .NET Framework as their primary development environment in 2005. [...] So, the old Big Java EJB Servers are slowly destroying the market.
    I tend to agree with it. EJB technology follows Corba path - it is quickly becoming a legacy wieght, that companies either have to carry it or drop it. With tight IT budgets, this over-complicated, difficult to adapt to new requirements legacy is unlikely to be cured by yet another improved version of EJB - V3.0 is going to maintain full compatibility with the failed V2.1, - it has to be dropped out of J2EE specification to keep Java innovative and competitive.

    I realise this will never happen. Over the years I've seen that JCP doesn't listen to developer's community. The primitive logic it follows is "who cares about the army of unknown java monkeys (who write 90% of the java code in the world), if we can just satisfy the needs of a few world's largest corporate players (who simply provides the cash flow)?" But I'm can't blame them, because I don't see a viable alternative that would fully satisfy all parties.
  36. something new is needed[ Go to top ]

    Evrything we are doing today will be a legacy some day. COBOL is a good thing if it lives so long and probably SQL will live longer than JAVA. Does somebody thinks new QL's are going to live as long as SQL ?
  37. you forgot something[ Go to top ]

    "who cares about the army of unknown java monkeys (who write 90% of the java code in the world), if we can just satisfy the needs of a few world's largest corporate players"
    You forgot to add: "and our egos".

    Regards
    Rolf Tollerud
  38. It is very good if OODB provides JDBC and ODBC interfaces. There are a lot of good tools for RDBMS and data binding, reports and forms, there are a lot of good modeling tools too. It helps to reuse tools and to save time. Probably JDO is more cool way to access data, but I think there is nothing wrong to use JDBC for any "parsistent store" too.
  39. Square Peg in a Round Hole[ Go to top ]

    So imho this "EJB3 is tied to RDBs" argument is false.
    I completely disagree. The EJB expert group has apparently decided to optimize EJB 3 for the relational model. This "you can make it work" idea of yours translates to "you can hack around the deficiencies to shoe-horn a square peg in a round hole." Why do that when better alternatives exist?

    Since most people deal with relational databases, I guess this isn't an issue for them. I guess others are left out in the cold. The jury is still out, but it looks like JDO 2 is making an attempt at providing specific support for the relational model while not forsaking others. I have mainly used Hibernate, but I must admit that JDO 2 looks attractive.
  40. Square Peg in a Round Hole[ Go to top ]

    So imho this "EJB3 is tied to RDBs" argument is false.
    I completely disagree. The EJB expert group has apparently decided to optimize EJB 3 for the relational model. This "you can make it work" idea of yours translates to "you can hack around the deficiencies to shoe-horn a square peg in a round hole."
    Yes indeed "the JDBC abstraction level is inappropriate for object databases", but guess what, "and the OODB abstraction level is also inappropriate for relational databases" :-) An ORM solution like Hibernate emphasises the R in th ORM, while something like JDO emphasises the O :-) It's quite evident imho, just look at the query stuff. The pivot point between the O and the R is quite different between the two.

    I can't disagree more with this statement: "Hibernate's success #1 reason is because it is free". Imho Hibernate has won because Hibernate was the only persistence framework which did an awesome balance between the O and the R of ORM. It is "appropriate" in your own words for mapping to relational data and yet it's OO. You may disagree with me on this, but remember a huge number of developers (who are using or admiring Hibernate) and among them some very smart guys agree with me :-)

    Ara.
    Co-author of Java Open Source Programming
  41. Square Peg in a Round Hole[ Go to top ]

    Ok, lets discuss this theme some more.

    Ara claims that the JDO abstraction (which he mistakenly calls the OODB abstraction) is inappropriate for Relational databases.

    Given that (a) we use relational databases, (b) our access to them is from a OO language, and (c) ORM is ll about the management of objects which have persistent state in relational databases, which aspects of JDO's abstraction are believed to be "inappropriate"? This question is probably best split into two:
    • which aspects of JDO's persistent object model are inappropriate for RDBMS?
    • which aspects of JDOQL are inappropriate for the RDBMS?
    This thread is finally cutting to the chase of David Jordan's original article, and the "pivot point" would appear to be whether or nor JDO is Just for Object Databases. The members of the JDO expert group, and many JDO implementers or proponents, believe that JDO is NOT just for object databases, whilst others in the community insist that it IS just for object databases.

    So perhaps someone will be kind enough to tell me where our abstraction level falls short?

    Kind regards, Robin.
  42. Square Peg in a Round Hole[ Go to top ]

    The members of the JDO expert group, and many JDO implementers or proponents, believe that JDO is NOT just for object databases, whilst others in the community insist that it IS just for object databases.So perhaps someone will be kind enough to tell me where our abstraction level falls short?Kind regards, Robin.
    I hope evrybody believes the same, nobody will discuss about JDO if it will become for object databases only.
    The main feature I need in persistence framework a is full SQL support and I need to update and delete data without loading garbage to client memory.
    This is not JDO specific problem, all O/R tools hide too many RDBMS features. I understand, it is not trivial to solve, but new QL is a workaround not a solution, it adds limitation and I do not believe tool will generate SQL I want and for all databases, It just not realistic.
    If there is no way to solve this then I will stop to talk about JDO and it will mean object persistence is just not for me.
  43. Thanks Juozas. It's much easier to talk about specific technical points than to talk in broad generalizations. At least, if it's not "easier" it's certainly more productive!

    JDO works at a higher abstraction level than JDBC. We hope that is a benefit in most cases. However we recognise the needs of developers to "update and delete data without loading garbage into client memory".

    JDO 1.0 did not address these concerns, but two features new to JDO 2.0 will hopefully go along way.

    1. Deletion by Query

    It JDO 2.0 you can define a JDOQL query which would usually select a set of persistent instances from the database. You can then "execute the query for deletion", which causes the SQL emitted from the query engine to be a DELETE statement instead of a SELECT statement. Thus the instances whih would have been retrieved by executing the query would instead be deleted. In most cases this takes the form of a single DELETE statement executed by the database engine - so no "garbage" in the client memory!

    So your code might end up looking something like this: (please excuse any minor errors - it's the concepts that count)

    // pm is a PersistenceManager
    Query q = pm.newQuery(Employee.class, "country == 'UK'");
    q.deletePersistentAll();

    Note that this is only efficient if Employee does not implement the DeleteCallback interface. If it does implement this interface, then each employee must be instantiated in memory, have its jdoPreDelete() method invoked, and then be deleted. Given the advent of "dependent" relations for all datastores and cascade-delete foreign-key semantics for relational datastore schema creation in JDO 2.0, DeleteCallback is unlikely to be used particularly much.

    2. DataStoreConnection

    JDO 2.0 acknowledges that you may want to do things which JDO cannot do (or cannot do efficiently), but which you could do efficiently with access to the native datastore connection. The bulk updates is an excellent example. Call getDataStoreConnection() on the PersistenceManager to get a proxy to the connection which JDO is using. In the Relational case this will be a java.sql.Connection instance. Play with SQL as much as you wish, but close() the connection before doing anything in JDO land which might require use of the connection. Your SQL work forms part of the current transaction presuming a datastore transaction is active when you get the connection.

    The proxy you get to the undelying connection protects you from invoking transaction demarcation methods, by throwing a JDOException if you invoke commit((), etc. But sometimes a user wants to get the real thing, perhaps so it can be cast to a particular driver class name in order to invoke proprietary features of the driver which are not exposed through java.sql.Connection. For this purpose you can use getNativeConnection(). This is a method of the DataStoreConnection proxy, and it returns the actual (un-proxied) connection which JDO is using. You can now cast the result to be an instance of your driver's ConnectionImpl and do what you want, including - of course - shooting yourself in the foot!

    So, you got the connection and you updated some instances of, lets say, Employee objects. you did this efficiently by executing a SQL UPDATE statement direct to the database. Now you want to use the updated objects in JDO land, but you aren't sure whether JDO has dirty instances in memory. In particular, you aren't sure if other instances of PersistenceManagers have those instances in memory either (e.g. the clustered case). What you need to do is evict any such instances from the cache, but not just the local PersistenceManager cache but also any distributed level-2 caches.

    For this purpose we provide an abstraction called CacheManager. Call getCacheManager() to get an instance of CacheManager through which you can programatically evict individual instances, collections/arrays of instances, or entire extents. (An extent is all instance of a particular persistence-capable class, optionally including all subclasses).

    So your code might end up looking something like this: (please excuse any minor errors - it's the concepts that count)

    // pm is a PersistenceManager
    JDOConnection jdocon = pm.getDataStoreConnection();
    Connection sqlcon = (Connection) jdocon;
    Statement st = sqlcon.prepareStatement("UPDATE EMP SET SALARY = SALARY * 1.1 WHERE CNTRY = 'UK'");
    st.execute();
    sqlcon.close();
    CacheManager cm = pm.getCacheManager(); // see note below
    cm.evictAll(Employee.class, true);
    // now do other stuff - JDO knows to reload any required Employees from the datastore

    Note: the getCacheManager() level is presently defined on PersistenceManagerFactory but I expect it to be available on the PersistenceManager as well before the JDO 2.0 draft spec is published. Otherwise the call should be pm.getPersistenceManagerFactory().getCacheManager();

    How does that match up to your requirements?

    Kind regards, Robin.
  44. Yes, it is very good JDO2 is going to be more pragmatic. It must be possible to implement update queries too. As I understand the main problem is cache, implementation needs to update it too. I see a few ways to implement it:
    1. interpret query and update in memory objects. It will not work with database triggers, but the same problem exists with property update.
    2. Invalidate objects and force lazy reload after update.
    3. User must evict cache before to execute update query and it will throw exeption if cache is not empty.

    I prefer 3, specification can let all ways to implement this feature, but 3 and 1,2 conflicts.
  45. Hi Juozas

    There are no plans for JDO to support bulk updates through its Query mechanism. This isn't even on the list of items defered beyond JDO 2.0.

    Bulk updates through JDOQL would enable a schema-independent (and therefore datastore-portable) mechanism. Bulk updates through JDOQL might also facilitate automatic eviction of the necessary extents. This in itself has associated difficulties, particularly where the db schema uses triggers to propagate changes beyond the entities touched by the update - JDO would not know to evict those from the cache. But the principle that cache eviction be automatic for the majority of cases makes me prefer that approach (not that it is even planned at present).

    Another problem with bulk updates is that of breaching encapsulation. Bulk updates would facilitate he SETTING of fields which were private and which had no public mutator methods exposed in the Java world. This might present conceptual difficulties.

    The alterbative to bulk updates through JDOQL, using the DataStoreConnection, requires intimate knowledge of the relational schema (as per my example).

    If the community requires bulk updates they should let us know, either informally on places like TSS or formally through teh JSR 243 comments alias. Either way, I doubt this would be considered for the 2.0 release.

    Cheers, Robin.
  46. Memory state must not be a vey big problem. Transaction with bulk update does not need something more than bulk update in practice and it is possible throw some exeption if it conflicts with cached operations. But it is not common to use objects for bulk update, scripts on crontab to it in most of cases. It is more common to update/delete persistent state "by id" without object materialization:

    boolen updated = pm.update( MyClass.class,oid,"email", "baliuka at domain dot lt" );
    or
    pm.update( trancientObject );

    It is very common use case for web applications:
    1. Start transaction.
    2. Load data and populate fields.
    3. End transaction.
    4. Clear resources.

    5. Start transaction.
    6. handle form, check version, load/update.
    7. End transaction.
    8. Clear resources.

    I wan to eliminate "load" in 6, because I never keep diconnected objects loaded at 2 (it can cause scalability problems).
  47. Square Peg in a Round Hole[ Go to top ]

    So perhaps someone will be kind enough to tell me where our abstraction level falls short?Kind regards, Robin.
    Gavin and the members of the EJB3 spec are the people who could do this, in public and in a detailed and technical way :-)

    Ara.
  48. Ara....[ Go to top ]

    So perhaps someone will be kind enough to tell me where our abstraction level falls short?Kind regards, Robin.
    Gavin and the members of the EJB3 spec are the people who could do this, in public and in a detailed and technical way :-)Ara.
    No way Ara, I won't make anymore statements in public. Every time I say anything here or on my blog, I am the subject of personal attacks and smears, lies and misquotes, the works. I won't respond to this ridiculous horsehit article or any others which follow. :-)

    I'm focused on technology, developing Hibernate and working with the other great people on the expert group to write a truly /good/ standard. Clowns can play politics. I don't.

    peace!
  49. Ara....[ Go to top ]

    No way Ara, I won't make anymore statements in public. Every time I say anything here or on my blog, I am the subject of personal attacks and smears, lies and misquotes, the works. I won't respond to this ridiculous horsehit article or any others which follow. :-)

    I'm focused on technology, developing Hibernate and working with the other great people on the expert group to write a truly /good/ standard. Clowns can play politics. I don't.
    That's too bad. I would like to hear you respond to those people that have put forth reasonable arguments (present article not included). You are right that some people will respond irrationally, but the rest of us still want to know why one standard may be overlapping heavily with another. Still waiting for an explanation...
  50. Ara....[ Go to top ]

    Cedric/Gavin

    Guys. why its so difficult answering Bill Willis question?

    Pratheep P
  51. Such a discussion would not help anything but just boggle down into endless trivial details.
    It should be enough to notice that,

    hibernate.jar is 793Kb,
    kodo.-jdo-runtime.jar is 2828Kb.

    Also be welcome to compare spring.jar (825Kb) with any commercial Java EJB Server :)

    Regards
    Rolf Tollerud
  52. .It should be enough to notice that, hibernate.jar is 793Kb, kodo.-jdo-runtime.jar is 2828Kb.
    JDX OR-Mapper runtime jar is less than 450Kb. JDX may be too simple for many advanced developers:)
  53. Ara....[ Go to top ]

    I'm focused on technology, developing Hibernate and working with the other great people on the expert group to write a truly /good/ standard. Clowns can play politics.This is good, but you need work with JSR-220 and JSR-243 people, if not
    you are in trouble (I think).

    I think that the guys of JSR-220 and JSR-243 must to go to take a beer and talk
    a lot.

    Please...

    Javier Paniza
  54. Free makes a big difference[ Go to top ]

    Ara: I can't disagree more with this statement: "Hibernate's success #1 reason is because it is free".

    The adoption of Hibernate would not have occurred at even 1% of its rate had it been it cost money (either developer and/or production license cost.) So if you measure success by adoption, then Hibernate's success would not have been possible were it not a free download.

    If you disagree with this assertion, consider that Tomcat and JBoss are more widely used than Resin and Orion, both of which (Resin and Orion) are easily affordable for most software projects, and either of which would pay for themselves quite quickly considering the productivity gains, performance gains and lower support costs that would come with them. It's not the souce code thing either, since Resin comes with full source code. In other words, sometimes it is really is just a question of money, because no one would be using Tomcat otherwise. (Sorry, somebody had to say it.)

    OTOH The fact that a piece of software is free and gets wider distribution as a result is neither a good or bad thing in itself -- it's just a natural result. In Hibernate's case, it does seem that it is the best free Java ORM library out there, and that helped its success quite a bit. In other words, just because it's free doesn't mean that it's not good ;-).

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  55. Free makes a big difference[ Go to top ]

    So if you measure success by adoption, then Hibernate's success would not have been possible were it not a free download.
    Yes free download is very important for adoption, I experiment with new technologies at home, It takes a lot of time to experiment before I start to trust it and I need source code for debuging. Sometimes I need to modify code for my deployment for performance or for security reasons. It is very important for runtime libraries like O/R or MVC framework is, but I use modified (stripped) web servers too.
  56. Free makes a big difference[ Go to top ]

    Ara: I can't disagree more with this statement: "Hibernate's success #1 reason is because it is free".The adoption of Hibernate would not have occurred at even 1% of its rate had it been it cost money (either developer and/or production license cost.) So if you measure success by adoption, then Hibernate's success would not have been possible were it not a free download.If you disagree with this assertion, consider that Tomcat and JBoss are more widely used than Resin and Orion, both of which (Resin and Orion) are easily affordable for most software projects, and either of which would pay for themselves quite quickly considering the productivity gains, performance gains and lower support costs that would come with them.
    Yes indeed, no argument here. But the original poster of the "because it is free" argument claimed that if a free and high quality JDO implementation existed JDO would be the dominant ORM rather Hibernate and my responce was specifically to this free-Hibernate-vs-free-JDO argument really. I say even with a high quality and free JDO implementation Hibernate would win anyway because the O and R balance is more appropriate :-)

    Ara.
  57. Free makes a big difference[ Go to top ]

    Yes indeed, no argument here. But the original poster of the "because it is free" argument claimed that if a free and high quality JDO implementation existed JDO would be the dominant ORM rather Hibernate and my responce was specifically to this free-Hibernate-vs-free-JDO argument really. I say even with a high quality and free JDO implementation Hibernate would win anyway because the O and R balance is more appropriate :-)Ara.
    I know hibernate almost from begining and I saw how it was adopted. "Free" is very important, but it is not the main reason hibernate. I am sure the main reason was a very good documentaion and support on forum. A lot of good ideas and feature requests are dicussed on public forum too. There are a few free JDO implementations too, I contributed a few ideas and code myself too. I am 100% sure
    "free" is not the main reason.
  58. Square Peg in a Round Hole[ Go to top ]

    Yes indeed "the JDBC abstraction level is inappropriate for object databases", but guess what, "and the OODB abstraction level is also inappropriate for relational databases" :-) An ORM solution like Hibernate emphasises the R in th ORM, while something like JDO emphasises the O :-) It's quite evident imho, just look at the query stuff. The pivot point between the O and the R is quite different between the two.
    Ara, I respectfully disagree again. The main reason I use a framework like Hibernate or one based on JDO is to abstract away the persistence side and work at the object level. I am not talking about OODB abstraction - I AM talking about OO abstraction! The O in ORM stands for Object, and the mapping to the relational side is ideally transparent. So in regards to JDO's query language, I think it is entirely appropriate. If I want to do my work at the relational level, these frameworks are not appropriate and are overkill. Hibernate took the practical route of offering access to the underlying relational model if you needed it. It looks like JDO 2 will offer this as well. Of course, this gives developers a certain amount of rope to hang themselves with if not careful.

    I agree that Hibernate didn't succeed just because it was free. It was really a balance between free, good quality, practical focus, and a pinch of good timing.

    I am still waiting to hear more about why we need two object mapping standards, especially ones with significant overlap. Having two will only add to the perception that J2EE is too complex. I would like to hear more from the EJB 3.0 folks as to why this is necessary.

    Regards,
    Bill
  59. Re: Square Peg in a Round Hole[ Go to top ]

    Bill,

    You wrote:
    I am still waiting to hear more about why we need two object mapping standards, especially ones with significant overlap. Having two will only add to the perception that J2EE is too complex. I would like to hear more from the EJB 3.0 folks as to why this is necessary.
    Frankly, I believe that JDO is overly complex. Having only one object mapping standard, namely JDO, may itself add to the perception that J2EE is overly complex.

    The #1 issue for EJB 3 is simplification/ease-of-use. I don't believe that
    JDO can achieve this nearly as effectively as the Hibernate-like POJO entity bean model that the EJB3 EG is pursuing.

    What we hope to achieve includes things like:

    (0) No need (or use for, or reason to explain the optional need for) any interfaces to be implemented by a persistent object.
    (1) Only one kind of primary key.
    (2) Very few possible instance states.
    (3) SQL-ish query language, i.e. EJB-QL, and direct SQL access.
    (4) Ability to call from EJB session beans, web tier and remote clients with a minimum of fuss, factories, initial contexts etc.
    (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.

    Someone may answer "JDO can do all that", to which I may respond "yes, but so can something easier to use and learn than JDO".
  60. Re: Square Peg in a Round Hole[ Go to top ]

    (6) No fancy features that can only be supported by bytecode enhancement.The FULL "transparent persistence spec" should be implementable withoutbytecode enhancement.Someone may answer "JDO can do all that", to which I may respond "yes, but so can something easier to use and learn than JDO".
    Which EJB features fall into this category?

    I believe that JDO 2.0 is/was going to make enhancement optional. Which optional features of the spec would implementations which didn't use enhancement be unable to implement?

    Tom
  61. Re: Square Peg in a Round Hole[ Go to top ]

    Arg, that should say 'which *JDO* features...'.
  62. Re: Square Peg in a Round Hole[ Go to top ]

    (Disclaimer: I have experience using EJBs, but not much personal experience using either Hibernate or JDO. I am glad that Hibernate and JDO have finally unjammed the EJB thought train of "We make application development harder." ;-)

    Evan: Frankly, I believe that JDO is overly complex. Having only one object mapping standard, namely JDO, may itself add to the perception that J2EE is overly complex.

    I never thought I'd see the day where someone thought that there was a more complicated spec than EJB for data persistence ;-)

    (I know you're comparing JDO with what you want EJB to become, not what it is, but you have to admit that your comment is totally ironic.)

    (0) No need (or use for, or reason to explain the optional need for) any interfaces to be implemented by a persistent object.

    Here's a great example of what I was talking about! For five years, EJBs have required multiple interfaces to be defined, and they've often been both highly redundant (they are just like your classes, but different) and inapplicable (you don't ever implement some of the interfaces.)

    (1) Only one kind of primary key.
    (2) Very few possible instance states.


    Can you expand on these, please? How does it compare to OIDs in JDO?

    (3) SQL-ish query language, i.e. EJB-QL, and direct SQL access.
    (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.


    These items are certainly worth figuring out if there is a chance to leverage the work that the JDO group and projects like Hibernate have done.

    What are the major differences from HQL and JDOQL? Why are HQL and JDOQL not sufficient? (Or if you are using one of them, why is the other not good?)

    (4) Ability to call from EJB session beans, web tier and remote clients with a minimum of fuss, factories, initial contexts etc.

    This is a noble goal. Of course, calling session EJBs today isn't too hard, albeit significantly more ugly than invoking POJO-style Java.

    (6) No fancy features that can only be supported by bytecode enhancement.
    The FULL "transparent persistence spec" should be implementable without
    bytecode enhancement.


    This one is always thrown out there as a bit of a red herring. EJB (like JSP and other uck-fugly specs) has always had all sorts of byte code generation going on, nice and slowly behind the scenes making messes of hard drives everywhere. Just because most implementations generate loads of ".java" files and use a compiler (System exec JavaC) to do the byte code generation somehow makes it better?

    Personally, I find the concept of being scared of byte code manipulation is like being scared of SQL because it can be used to change tuples. Byte code is so well defined and structured that it is significantly safer and easier to work with byte code than it is to work with XML, for example.

    At any rate, with all the new EJB 3.0 magically-easier stuff that is being discussed, it's just going to be tonnes more ".java" and ".class" files being inefficiently generated, with more ".wldonotdelete" directories that we'll have to delete to get anything to work properly. I'd take an efficient dynamic byte code enhancement (or direct byte code production) route any day of the week over that.

    Any, in conclusion, the EJB expert group and the JDO expert group are both tackling Object/Relational Mapping (ORM). If you're both tackling the same (exact? similar?) problem, isn't it a bit stupid to not at least be talking together? I'm not concerned about the API for JDO not being the same API for EJB, but maybe there's some parts of the work that can be shared or re-used. Isn't that just a logical desire?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  63. Re: Square Peg in a Round Hole[ Go to top ]

    Frankly, I believe that JDO is overly complex. Having only one object mapping standard, namely JDO, may itself add to the perception that J2EE is overly complex.
    Though I hope this thread remains dead, I wanted to note that I posted responses to the specific issues raised by Evan. My responses are in this more recent persistence thread.
  64. Are they really going to make use of Hibernate obligatory ?

    That would go against one of main ideas of J2EE - compatibility.

    No possibility to choose a vendor anymore ? What if you dont want to use Hibernate for some reason (technical, support cost/quality, whatever) ?

    Does it mean that all EJB vendors will have to pay JBoss for including Hibernate in J2EE server ? And who will provide support ? Also this will make all EJB containers at least half open source.

    At the end JCP "experts" will make all J2EE specs. proprietary. Want to use JMS - then use IBM MQ. XML ? BEA XMLBeans !!!
  65. But vendors are represented[ Go to top ]

    At the end JCP "experts" will make all J2EE specs. proprietary. Want to use JMS - then use IBM MQ. XML ? BEA XMLBeans !!!
    The many vendors are fully represented in most of these JSR expert groups. This tends to level out the playing field and ensure that the decisions are fairly neutral as IBM won't give BEA too much of an edge and neither would JBOSS give IBM or BEA or Oracle a huge edge either.

    Of course, deals can be made that hurt "the little guys". But that is true in all group efforts. The JCP, W3C, ITU, ISO and even the IETF have to live in the real world where agendas vary and are usually hidden, compromises get made, deals get struck and in the end, it really ain't so bad. Not perfect mind you, but not horribly broken either.

    And the pundits will wring their hands, spread their FUD and use that to sell more copies of their next book or at least get more lucrative deals for their article, books and speaking engagements.

    Chuck
  66. licensing questions[ Go to top ]

    Are they really going to make use of Hibernate obligatory?
    No. The EJB3 effort will specify interfaces, and the RI might [theoretically] be based on Hibernate.
    No possibility to choose a vendor anymore?
    Um .. same as today .. a dozen J2EE server vendors with a few dominant ones. Hopefully JBoss and Apache joining the list as certified.
    What if you dont want to use Hibernate for some reason
    Probably JBoss will be the only one using Hibernate, due to licensing. So if you don't want to use Hibernate, don't use the JBoss app server.
    Does it mean that all EJB vendors will have to pay JBoss for including Hibernate in J2EE server?
    It is highly unlikely, but not altogether impossible. Part of the "problem" (if you work for JBoss and want to sell software licenses) is that JBoss doesn't own Hibernate (or JBoss for that matter,) it just pays the salary of the main author of Hibernate. Unless they get the copyrights for all code submissions assigned to JBoss Inc., they cannot sell non-LGPL licenses of Hibernate (which is what I think you are referring to, like what MySQL does.)
    At the end JCP "experts" will make all J2EE specs. proprietary. Want to use JMS - then use IBM MQ. XML ? BEA XMLBeans !!!
    That's very unlikely. The trend is toward BSD-licensing (or similar) for all JCP work, even though technically the licenses can be otherwise (as long as they are RAND.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  67. response[ Go to top ]

    Guys,

    Firstly, I doubt that the decision is still final. There are still battles to see.

    Secondly, I doubt that Hibernate will by any means be mentioned in the EJB 3.0 spec. Most probably, in EJB spec 3.0, we will just see a Hibernate-like API and lifecycle recommendations.

    Each specific server provider will have to implement its own specific persistence layer compatible with Hibernate API and extend it the way he wants it. And I am quite confident that such companies as BEA and IBM have enough resources to develop an extended cluster-aware "Hibernate" from scratch in almost no time (let me remind you, that Hibernate sources are available to anyone, so why not to copy-paste and refactor a little bit).

    Alex
  68. response[ Go to top ]

    (let me remind you, that Hibernate sources are available to anyone, so why not to copy-paste and refactor a little bit).
    It is possible to "reuse" any compiled JAVA code this way too, most vendors provide source code too ( see src.jar in JAVA_HOME ), but OSS is more than something about code in the text format file.
  69. response[ Go to top ]

    "It is possible to "reuse" any compiled JAVA code this way too, most vendors provide source code too ( see src.jar in JAVA_HOME ), but OSS is more than something about code in the text format file."

    It's more than that. And that's why I wonder how the EJB guys I going to let the vendors to write their own "Hibernates" without being accused in plagiat.

    Alex
  70. response[ Go to top ]

    I’ve lost track of the JDO Hibernate relationship. Are we going to see a frenzy of JDO and EJB vendors embracing and extending Hibernate? Each one promising to be vastly superior to Hibernate itself in a version that will ship real soon now. I hope not.

    Gary
  71. response[ Go to top ]

    JDO and EJB specifies interfaces, there is no problems to implemt two interfaces in the same class and there is no problems to implement an "abstraction" for all of them JDO, EJB, Hibernate, JDBC. You will need to write adapter for EJB 4 any way ... .
    Hibernate is the real product and it works, JDO 2 and EJB 3 doe's not exist.
    It Looks like there is nothing to discuss about from the technical point of view in this forum, is it ?
  72. Gary,

    The EJB3 POJO entity model may well end up being Hibernate-like in some respects, but that in itself does not mean that EJB3 vendors will use
    Hibernate, embrace Hibernate, or use any Hibernate code at all.

    For example, I believe that it will be possible to implement the EJB3 POJO
    model by delegation to generated EJB 2.1 entity beans that use local
    interfaces together with the well-known value object pattern. I believe this
    because I tried it already and it works.

    (Someone might think this will be slow. The answer would be "maybe, maybe
    not, it depends on how good your EJB 2.1 entity bean container is, and there are some good ones out there".)

    The fact that EJB3 POJO entities and the current EJB 2.1 entity model seem to be so easily mappable in this regard I find comforting (as an implementor), as
    existing EJB 2.1 infrastructure can be reused.

    In summary, this is evolution, not revolution :-)
  73. Evan-"In summary, this is evolution, not revolution :-) "

    +1

    But I must hand it- This spin-factory is just amazing :-) (Flame?)

    Cheers,
    Ramesh
  74. licensing questions[ Go to top ]

    Cameron: "Unless they get the copyrights for all code submissions"

    Anybody that has some idea or can do an estimate of how much work it would be for JBoss to acquire copyrights for the missing code submissions and/or rewrite the rest?
  75. licensing questions[ Go to top ]

    Cameron: "Unless they get the copyrights for all code submissions"Anybody that has some idea or can do an estimate of how much work it would be for JBoss to acquire copyrights for the missing code submissions and/or rewrite the rest?
    Well, I will say this. New contributors and/or patch submitters do NOT have to sign an agreement assigning any copyright over to JBoss Inc although they are required to license anything they submit under LGPL. We have added over 30 new contributors over the past year.
  76. licensing questions[ Go to top ]

    Are they really going to make use of Hibernate obligatory?
    No. The EJB3 effort will specify interfaces, and the RI might [theoretically] be based on Hibernate.
    No possibility to choose a vendor anymore?
    Um .. same as today .. a dozen J2EE server vendors with a few dominant ones. Hopefully JBoss and Apache joining the list as certified.
    What if you dont want to use Hibernate for some reason
    Probably JBoss will be the only one using Hibernate, due to licensing. So if you don't want to use Hibernate, don't use the JBoss app server.
    Does it mean that all EJB vendors will have to pay JBoss for including Hibernate in J2EE server?
    It is highly unlikely, but not altogether impossible. Part of the "problem" (if you work for JBoss and want to sell software licenses) is that JBoss doesn't own Hibernate (or JBoss for that matter,) it just pays the salary of the main author of Hibernate. Unless they get the copyrights for all code submissions assigned to JBoss Inc., they cannot sell non-LGPL licenses of Hibernate (which is what I think you are referring to, like what MySQL does.)
    At the end JCP "experts" will make all J2EE specs. proprietary. Want to use JMS - then use IBM MQ. XML ? BEA XMLBeans !!!
    That's very unlikely. The trend is toward BSD-licensing (or similar) for all JCP work, even though technically the licenses can be otherwise (as long as they are RAND.)Peace,Cameron PurdyTangosol, Inc.Coherence: Clustered JCache for Grid Computing!
    EJB3 is using/borrowing/stealing many ideas from Hibernate as Hibernate has done MANY things right when it comes to persistence. Although JBoss has gained some much-deserved influence on the EJB3 spec committee, this concern of a "power-shift" is much ado about nothing. JBoss Inc. isn't the only vendor that has Hibernate-like technology which is why the expert group has been so receptive of Hibernate APIs.

    On Hibernate(I hope Gavin doesn't mind me speaking on it):
    * Hibernate will always be usable outside of the JBoss Application Server
    * Hibernate is continuing and will continue to evolve beyond any specification efforts.
    * Hibernate will not be dependent on the JBoss Application Server
    * We may make our EJB3 persistence usable in other application servers. It is just a matter of finding the resources for testing and the integration code. Of course, any contributors are most welcome to help out this effort(and you retain any copyright on code you submit).

    On JBoss/Hibernate licensing:
    * Hibernate and JBoss are licensed and will always be licensed under LGPL.
    * JBoss and Hibernate have a very large, diverse user base including ISVs, which embed these projects, IT organizations, and government agencies all around the world. LGPL is is flexible enough to meet the needs of this vast diverse community, yet at the same time protect the open source interests and IP of our company and the large number of independent OSS developers which contribute to our projects.
    * I guess what I'm saying is that there are VERY FEW users of JBoss that would benefit from a proprietary license of JBoss. These subtle FUDs that we want to force users to pay for JBoss is just unfounded, virtually impossible, and we like it that way as believe in many of the ideals of the FSF.

    Bill
  77. I previously stated:
    It is highly unlikely, but not altogether impossible. Part of the "problem" (if you work for JBoss and want to sell software licenses) is that JBoss doesn't own Hibernate (or JBoss for that matter,) it just pays the salary of the main author of Hibernate. Unless they get the copyrights for all code submissions assigned to JBoss Inc., they cannot sell non-LGPL licenses of Hibernate (which is what I think you are referring to, like what MySQL does.)
    I received an email from Bob Bickel at JBoss, concerned that someone might infer (from my comment) that JBoss Inc. plans to try to change the LGPL to something else (a la MySQL with a dual-license model that is designed to force people to pay for the software if they use it for commercial applications.) Just to be perfectly clear on this: I have _absolutely_ no reason to believe that such a thing is a goal of JBoss Inc., and I did not mean to imply that it is a goal or an eventuality. Further, Bob stressed that JBoss Inc. has no plans to change JBoss or Hibernate from LGPL, either now or ever. (Bill Burke posted a similar statement somewhere in this thread, I believe.)

    (I was simply trying to answer the question "Does it mean that all EJB vendors will have to pay JBoss for including Hibernate in J2EE server?" and show how difficult such a thing would be in reality, if that were a goal, which I have no reason to believe that it is. Hopefully, that makes everything perfectly opaque. ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  78. At the end JCP "experts" will make all J2EE specs. proprietary. Want to use JMS - then use IBM MQ. XML ? BEA XMLBeans !!!
    Do you even have a clue about what your talking about? XMLBeans is an Apache Incubator project, and the source is available for use under the standard Apache licensing terms.

    In what way is that proprietary? Please drop the dogma/us-against-them mentality. BEA, IBM, and Sun are all actively contributing to various Open Source initiatives.
  79. Database Lock-in ?[ Go to top ]

    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
    Seems to me that David Jordan does not understand how Hibernate works. Using vendor specific SQL is not required as most people simply use the database independent HQL. Switching database platforms is a matter of deployment descriptors.

    Looks like FUD coming from the JDO department.

     S.
  80. Database Lock-in ? - nonsense[ Go to top ]

    FUD that is an understatement this guy wrote a book called Java Data Objects .. hmm
    I am guessing he is in the JDO camp.
  81. Database Lock-in ? - nonsense[ Go to top ]

    no need to guess.

    "David Jordan, a member of the JDO expert group, explains why the JDO community is not just disappointed—but concerned—about a power shift in the app server market. "

    "Obviously my position is far from neutral ..."

    "David Jordan founded Object Identity, Inc. to provide Java Data Objects (JDO) consulting services. He has been a member of the JDO expert group since its inception and the JDO 1.0 specification has a special recognition of his contributions. He was also recognized for his review services of JDBC 1.0. David has authored the following books: 'Java Data Objects,' O'Reilly, 2003 and 'C++ Object Databases,' Addison-Wesley, 1998"

  82. Specifically, it [the EJB 3.0 EG] decided to use Hibernate as the persistence mechanism in EJB 3.0.


    No, we didn't.

    This article is ridiculous, let's move on, shall we?

    --
    Cedric
  83. Cedric,
    where is the truth? I wish hibernate can make for 3.0
    You as a jcp member, can you please tell us what is the truth on this 3.0 and hibernate? please.
  84. Cedric,where is the truth? I wish hibernate can make for 3.0You as a jcp member, can you please tell us what is the truth on this 3.0 and hibernate? please.
    You may wish to read my summary of the EJB 3 group's decision on this:

       http://www.scottcrawford.com/ejb30entitybeans.html

    But Cedric is right, the level of FUD in this discussion has become ridiculous. Let's move on.
  85. Cedric,where is the truth? I wish hibernate can make for 3.0You as a jcp member, can you please tell us what is the truth on this 3.0 and hibernate? please.
    It's not even about truth, just common sense.

    As somebody pointed earlier in this thread, Hibernate is an implementation, EJB is a specification, so the premise doesn't even make sense from a logical standpoint.

    If you read the article carefully, you will notice it is pretty much exclusiveley about JDO and very little about EJB (or only to disparage it and insult the profesionalism of the EJB Experts Group).

    Personally, I find this article extremely unethical, especially coming from someone who also sits on a JCP Experts Group. You can disagree with your peers but you don't need to question their integrity for that.

    As I said, let's move on.

    --
    Cedric
  86. If you read the article carefully, you will notice it is pretty much exclusiveley about JDO and very little about EJB (or only to disparage it and insult the profesionalism of the EJB Experts Group).Personally, I find this article extremely unethical, especially coming from someone who also sits on a JCP Experts Group. You can disagree with your peers but you don't need to question their integrity for that.As I said, let's move on.-- Cedric
    Cedric,

    I find it interesting that you and the other anti-JDO folks only respond to flawed arguments from the JDO folks and choose to ignore some very relevant and technical questions, comments, and arguments from JDO experts. So far, I haven't seen any credible supporting argument as to why a Hibernate-like approach was chosen over JDO by the EJB3 EG. The only credible reason that has been offered seems to be that JDO can be used with and without an EJB container and this is seen to hurt the interests of major app server vendors. No wonder some people are doubting the ethics and professionalism of some folks in the EJB3 EG. It would help if the EG members explained the rationale behind their choice.

    Can you honestly say that your vote would have been the same if you weren't an employee of BEA? If so, I would prefer if you respond to Robin Roos' arguments as opposed to wasting time on inaccurate statements from Mr Jordan.

    Regards,
    Kalyan (has no connection to JDO and derives no commercial benefit from it)
  87. I find it interesting that you and the other anti-JDO folks only respond to flawed arguments from the JDO folks and choose to ignore some very relevant and technical questions, comments, and arguments from JDO experts.
    I see it on the both sides, most of problems is possible solve or to show the problem doe's not exist in technical dicussion.
  88. If you read the article carefully, you will notice it is pretty much exclusiveley about JDO and very little about EJB (or only to disparage it and insult the profesionalism of the EJB Experts Group).Personally, I find this article extremely unethical, especially coming from someone who also sits on a JCP Experts Group. You can disagree with your peers but you don't need to question their integrity for that.As I said, let's move on.-- Cedric
    Cedric,I find it interesting that you and the other anti-JDO folks only respond to flawed arguments from the JDO folks and choose to ignore some very relevant and technical questions, comments, and arguments from JDO experts. So far, I haven't seen any credible supporting argument as to why a Hibernate-like approach was chosen over JDO by the EJB3 EG.
    Here is one for starters: Hibernate is very popular and plebiscited by the community. This fact alone shows that Hibernate is filling a need, so it was only natural that we would take a closer look at it and reuse its best features.
    Can you honestly say that your vote would have been the same if you weren't an employee of BEA?
    Absolutely, definitely, 100% yes.

    --
    Cedric
  89. mark the article as noisy[ Go to top ]

    I notice that toplevel postings don't have a button to mark as noisy. But this link seems to work. However, the noisy score probably get honored.

    http://www.theserverside.com/common/marknoisy.tss?message_id=124496

    Ben
  90. mark the article as noisy[ Go to top ]

    Not sure why you said the article is noisy. The article never will be released or published if the JCP will be truly open and we can be able to see what is going inside (ie: reading the mail lists). But we cannot do that. So we need to read each article to have a glimpse of what is going on and make our own opinion of that.

    I believe people in TSS has a certain level of comprehension and is able to know what is good or not. and this mainly why I posted the link. I just wanted to discuss it.

    Currently, is a fact the confrontation about 2 JCP committes and the communities behind each one of them. We can see this kind of materials on both sides. I thought it is important to know about both sides. I try to read both sides to give an idea of what happens.

    The database field is a very important field in the application arena (no matter if it is a J2EE, .Net or whatever). In that way, I think is important to discuss the article, but comments as your really leave me without words. The opinion censure never left nothing good to the humanity.

    BTW, carefully reading drive us to (in italics):

    "Editorial Note: The purpose of pointing to articles is to give us a place to discuss the content. When we post an article the views are that of the author and not of TheServerSide.com."

    I think this tell all.

    Best Regards,
  91. EJB 3 and persistence[ Go to top ]

    I'd like to know from members of the EJB 3 Expert Group if they intend to specify a clear interface between the container and the persistence layer (EJB 3, JDO 2 or whatever else).
    Most J2EE users are really expecting this from a new EJB standard.
    The possibility to plug any data access layer (including home-made frameworks) seems to be very important for them.

    Best Regards, Eric.
  92. Well what do you expect when u see so many greedy vendors gathered at on eplace. they r going to make sure their own profits are covered. So there is no point in us developers talking about this whole mess, we cant do anything much. It is as ugly as national politics, as ugly as monkeys running a hospital.

    And after all this - whatever decison is made 50% will like it 50% wont. so why creat all this chaos - just make a decision and keep fixing bugs later on - as they do anyway ...
  93. Just wanted to provide this link:
    http://www.freeroller.net/page/fate/?anchor=jboss_panties_around_ankles_again

    Nice read :)
  94. I can not understand all the fuss. JCP is just doing what they should have done all along! Not sitting behind their desks constructing large systems but wait until the right winner emerge from competing products. Then make a standard out of it.

    Regards
    Rolf Tollerud
  95. I see a lot of posts spculating about politics and the intentions of people only a few of us really know better.
    Fact is that Hibernate is one of the most astonishing open-source projects and it got popular only because of it's excellence. Not because of marketing-hype or political games! There have been a lot of people screaming for an open-source Java and Hibernate's promotion to become EJB-standard is one important step into this direction.

    Congratulations Gavin and the rest of the Hibernate-Team!
  96. Finally![ Go to top ]

    As someone entering late into Hibernate / JDO debate, I had been very undecided for long time. Being a standards freak, JDO held me glued to it, but even before EJB expert commitee decision, Hibernate was starting to look better. Not requiring post-processing, true POJO usage, SQL like querying with all bells and whistles, and the rest... And this decision by EJB commitee looks like the final nail in JDO's coffin, also EJB Entity Beans. EJB entity beans sucked and people who tried to get this point accross now have a proof to point to (sadly, in IT world unlike mathematics, this is most *proofy* you'll ever get). This is great great news. I congradulate all who was involved in the decision.
  97. Pure Politics[ Go to top ]

    I have always had a good opinion of Hibernate, because it's so focused on performance, and because it's not a committee effort. However, I am surprised that Sun is killing off JDO. From out here, it looks like pure politics. JDO and Hibernate, and your own persistence mechanism that you wrote in your last job, all do the same thing. It's annoying to have competing JCP's and Sun taking so long to pick one. It just increases costs in the long run.
  98. Pure Politics[ Go to top ]

    Guglielmo: I have always had a good opinion of Hibernate, because it's so focused on performance, and because it's not a committee effort. However, I am surprised that Sun is killing off JDO.

    Actually, now (and for the first time) Sun is supporting JDO.

    The "opposition" to the JDO 2.0 JSR (which is not necessarily opposition to JDO, but perhaps to the scope of the 2.0 effort) came from BEA, Oracle and IBM. Conspiracy theorists were quick to point out that Oracle and IBM are RDBMS vendors, and all three are "EJB vendors" (WTF that means ;-) which could mean that they view JDO as competition.

    OTOH, it could be that they see overlap between two JSRs and are truly concerned about it [the overlap] for technical reasons.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  99. Overlap[ Go to top ]

    I'm going to leave out concerns about JDO vs. SDO overlap for now (there is very little) and look at the whole persistence thing.

    Before the announcements at the TSS Symposium the persistence world was coming together nicely. Entity beans had been eclipsed. The most widely-used open source persistence framework (Hibernate) was publicly planning to implement the JDO api, joining the stable of existing JDO implementations but giving users the benefits that Hibernate brought to market, including the credibility it had gained and its proprietary feature-set targetting relational datastores.

    That would have given the community JDO for high-level usage of datastores, and JDBC for low-level relational database access. Hibernate would have competed very effectively in the persistence sector.

    Then the EJB 3.0 announcements were made. Instead of JDO as the high-level abstraction of choice, people now have to bet their businesses on one of JDO (the JCP standard), Hibernate (the Open Source de facto standard), or EJB 3.0 (which might or might not be to an extent similar to or pluggable with Hibernate, but we just don't know yet).

    I don't think the JSR-220 group has done the community a service by announcing their third alternative, and indeed a third alternative "standard" if EJB 2.1 is included. And we still have not heard substantiated reasons for why JSR-220 were not prepared to "adopt" JDO as the persistence API. As far as I know all of the technical reasons that were given by the JSR-220 leadership have been shown to be invalid, and rumour has it that after further consideration some now believe that JDO adoption would have been the better approach as well as the most expediant.
  100. Overlap[ Go to top ]

    And we still have not heard substantiated reasons for why JSR-220 were not prepared to "adopt" JDO as the persistence API. As far as I know all of the technical reasons that were given by the JSR-220 leadership have been shown to be invalid, and rumour has it that after further consideration some now believe that JDO adoption would have been the better approach as well as the most expediant.
    I understand how it can help for JDO, but
    how this "adoption" can be usefull for me as developer ?
    If this standard will be pragmatic then I will use it (JSR version nubers are not interesting for me), I do not need just a standard API, I need SQL and RDBMS in practice (it is a standard de facto and de jure), if standard is more about transparence than about proven ways for data access and to transaction processing then is it not a very big problem, I have solutions myself too.
  101. Pure Politics[ Go to top ]

    Actually, now (and for the first time) Sun is supporting JDO.The "opposition" to the JDO 2.0 JSR (which is not necessarily opposition to JDO, but perhaps to the scope of the 2.0 effort) came from BEA, Oracle and IBM. Conspiracy theorists were quick to point out that Oracle and IBM are RDBMS vendors, and all three are "EJB vendors" (WTF that means ;-) which could mean that they view JDO as competition.OTOH, it could be that they see overlap between two JSRs and are truly concerned about it [the overlap] for technical reasons.
    I admit that I am not taking the time to do my homework here, and I guess the opposition does come from the major vendors. However, without looking up exactly how JCPs work, I am inclined to guess that the ultimate control of the J2EE spec is up to Sun. After all, Sun owns the J2EE trademark.

    I am not discussing the merits of Entity Beans vs. JDO. Since both specs are being revised, those are just names. What Sun could have done is change JDO to address the concerns of the big vendors, and then replaced Entity Beans with "JDO". The fact that they didn't do that, or even attempt to present it that way, just shows that JDO and EJB are totally different camps, and that the latter has a lot more power.
  102. Nice article[ Go to top ]

    That's very interesting article! As for me it's not about Hibernate vs JDO and not about JBoss vs Other J2EE vendors. IMHO it's about dissapointed person who really understood that Hibernate has nothing to do with JBoss but writing it because he want's to blame someone in JDO unsuccess. Or, I shouldn't call it unscucess because JDO is very popular, but the problem is in whole idea of trully "transparent" and truly "portable" and idialistic solution.
  103. Sorry for being harsh, but have not seen an utterly misleading article like this one for a long time.

    J2EE as a whole is only spec. May be sun will give a RI.But it no means, they are forcing everybody to use Hibernate.

    Vendors are still free to implement the spec in whatever way they want. Why this simple think did not occur to Gordon?

    And the title starts with "Politically Charged".
    At the end of the page, reads like this,
    "David Jordan founded Object Identity, Inc. to provide Java Data Objects (JDO) consulting services"

    Now, do i have a reason to believe David Gordon is politically charged?

    For heaven sake, stop spreading FUD. It's just annoying to read plain lies.
  104. There are some inaccurate statements in this article, I will address 2 of them.

    1. The persistence aspect of EJB 3.0 is not based solely on Hibernate. Contribution is coming from many different sources that bring vast experience to the table. This includes among others Oracle, BEA, IBM, Sun and JBoss/Hibernate. There are members of the EJB 3.0 expert group whose primary area of expertise is object-relational persistence and this includes the Oracle rep, Mike Keith, who is a senior member of the TopLink team. The views of the group members reflect the diverse customer bases they represent and the J2EE community is well-represented by the members of this group.

    2. The following statement is completely inaccurate from Oracle's perspective and I obviously don't speak for IBM but likely for them as well: "Members of the JDO community suspect that JDO's portability across databases—preventing vendor lock-in—is a primary reason for IBM and Oracle opposing JDO."

    Oracle AS TopLink supports all the major database vendors including Oracle, DB2, Sybase, and SQL Server via JDBC and will continue to. This holds true for the entire Oracle application server, not just the TopLink component as heterogenous environments are a reality of today's IT environments. Not all databases are alike and we also support vendor-specific features for ALL database vendors, not just Oracle, so that customers have the OPTION to leverage powerful proprietary database features. Applications can be built in a database vendor neutral fashion using TopLink as has been done by numerous ISV's.

    Database portability is not the primary or even a minor reason for Oracle opposing JDO because database portability is not unique to JDO. We've publicly stated our reason for opposing JDO in our JCP vote.

    Dennis Leung
    Oracle Corp.
  105. Clarifying Inaccurate Statements[ Go to top ]

    Hello Dennis

    Thank you for joining the discussion, although I wish it was in happier circumstances.

    The comment alongside Oracle's vote against JSR-243 at the JCP Approval Ballot commences
    JDO 2.0 overlaps with the work being done by the EJB 3.0 expert group to provide a lightweight persistence model.
    and continues in that vein. What we in the JDO community found so surprising about this vote was that JDO 1.0.1 already existed at the time JSR-220 was formed, serving precisely the needs mentioned in Oracle's comment.

    What is more relevant, therefore, than the reasons Oracle voted against JSR-243 (which is their prerogative) is the reasons why JSR-220 embarked upon the definition of lightweight persistence at all in the light of (a) the existing JDO standards and (b) the insight into JDO 2.0 (including the formulation of the O/R Mapping sub-standard) which Oracle and other JCP members had.

    Kind regards, Robin.
  106. "Members of the JDO community suspect that JDO's portability across databases—preventing vendor lock-in—is a primary reason for IBM and Oracle opposing JDO."
    I think the main reason IBM, Oracle and Bea are opposing JDO is that it can run outside the application server. JDO and lighweight containers clear shows that in most of times application servers are overkill to the budget and development process.

    Developers should stop reading marketing articles from big vendors and use real value frameworks.

    JSF is another big vendor way to earn money. In longhorn, Microsoft will come with XAML (a Mozilla XUL copy) to provide rich and light web applications and the objectspaces O/R mapping (a JDO copy).

    I'm wondering who are in the "dark side of the force": microsoft or java big vendors?

    Let developers guide the technology and not big vendors
  107. Erik: "Wondering who are in the "dark side of the force": Microsoft or java big vendors?"

    Jason Carreira: "If you can run your app in Tomcat for $0 in licensing (or in Resin for a $500 site license) then your management will be VERY happy to hear that they don't need to shell out $10 - $17K / CPU in licensing.

    Let's face it, with Spring / Hibernate / WebWork most apps don't need a full stack. I'm not talking 51% here, either, probably more like 85%-90%. Once there's good JMS support in Spring and other lightweight containers to make JMS development as easy as MDB's that number will go up to 95+%. Most of us are just using EJBs for transactional boundaries anyway"


    That has been obvious for a long time now and you may think that the main reason that the whole industry desperately try to cling on to the big and expensive J2EE Server with EJB is the fault of the "dark side of the force java big vendors" but that is not the case. The reason is an idea, better expressed as an ideal or longing, to have something better "and more scientific" than Microsoft.

    As a way of getting back for all these years when 95 % of all development was done in Windows. There you have the reason for all this insane bashing of Microsoft.

    Unfortunately it was built on clay. So will all development return to be done 95 % with MS tools? It may very well happen. Then you can speak of "Done in by own hands" or "Sawing of the branch you are sitting on".

    If the Sun/Java/Oracle camp had tried to compete with honest means, maybe they would have succeeded.

    Regards
    Rolf Tollerud
  108. There is one easy remedy against this boring people that try to predict the future, namely going back in time and mock all wrong predictions from the past. TSS is ideal for this, because all post are cast in stone and are persistent (sorry) until the end of time.

    May 02, 2001. Roger Sessions on .Net vs J2EE

    Unfortunately I can not see otherwise than that the good Roger was right in everything.

    But read the thread, it is entertaining and fascinating to read the old opinions while having the facit. This was before the TSS Petshop Benchmarks.
    "If the current ECPerf project goes live, I can only imagine low integrity guys like Roger Session laughing in our face".

    "More, it (ECPerf) is commercially flawed because it is a safe-heaven for EJB technology to avoid competition".

    We were like BMW technicians while MS developers were like Ford technicians and we had our pride for that.
    Now imagine that the old Crown Victoria suddenly runs faster than the Z8. And worse, BMW drops out of competition under the pretext:
     - "No, we are not talking performance here,we're not that interested in raw performance, we sell BMWs for leather quality and interior comfort, we'll create a separate competition for cars that have to have leather and look exactly like BMWs and have BMW engines under the hood."

    “you can't have scalability without performance”
    Regards
    Rolf Tollerud