667476 members! Sign up to stay informed.

Sponsored Links


Resources

Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts

News News News Messages: 172 Messages: 172 Messages: 172 Printer friendly Printer friendly Printer friendly Post reply Post reply Post reply XML XML XML

JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle

Posted by: Dion Almaer on May 04, 2004 DIGG
There has been an interesting twist to the JDO story. IBM, BEA, and Oracle all voted against the new JSR, while Sun and Macromedia supported it in their comments. The battle-ground seems to be that JDO overlaps with "other JSRs". Namely EJB 3.

The comments tell the story:

Sun: Yes
This is in response to some of the comments on JSR 243 "JDO 2.0".

If JDO did not exist, it might be a worthy topic for debate as to whether the Java community should invest in this area. I can see pros and cons on both sides. But JDO does exist, and it has a loyal user community who want to see it continued and extended. Sun, as specification lead for JDO, is responding to what we perceive as legitimate community demand for evolving JDO.

Sun believes that there is space for both JDO and EJB. I hope the expert groups can cooperate to minimize any unnecessary differences in areas where they overlap. Whether or not JDO should be included in J2EE is an issue for a future J2EE expert group to debate.

Given that JDO exists and has attracted significant interest from the Java community, I think it is appropriate to allow it to continue to evolve, based on the feedback and requirements from its users.
Macromedia: Yes
While undesirable overlap does appear to exist between JDO and other JSRs, the feedback we have long heard on this particular subject is that Java application developers prefer to adjudicate the overlap themselves rather than have the decision enforced for them by platform vendors. The community appears to desire a choice between persistence technologies even at the expense of the additional platform complexity and fragmentation that the overlaps between those technologies can cause. We consider our vote in favor of this JSR to reflect not an architectural platform aesthetic, but instead to reflect the more practical majority sentiment long and loudly expressed by customers and others in the community.
BEA: No
JDO is one of many different persistence solutions in server-side Java today. With J2EE 1.5 emphasis on simplification and ease of use, we don't see how having another release of JDO, whose market acceptance is essentially constrained to use with object databases, can be explained in conjunction to similar enhancements being made in the EJB3 expert group. We are also concerned about taking JDO into new areas such as disconnected data set support until we better understand how ball of these solutions fit together. Unless the submitters can explain how all of this fits together, we believe the Java community would be better served with fewer apparently competing alternatives.
IBM: No
This JSR proposes to develop extensions to JDO that apparently overlap with existing Java technologies and with other JSRs that are already in-progress. In a context where the Java community is working to simplify J2EE, it is undesirable to produce multiple overlapping ways of programming the same function.
Oracle: No
JDO 2.0 overlaps with the work being done by the EJB 3.0 expert group to provide a lightweight persistence model. Having 2 specifications address the same problem space with different APIs, persistence and transaction semantics, mapping definitions and query mechanisms does not contribute to the effort of simplifying J2EE and making it easier to use. The direction of lightweight persistence being taken by the EJB 3.0 group will have tremendous appeal to mainstream enterprise Java developers, even those who are critical of the current Entity Bean model. Given the evolution of EJB 3.0 persistence, another independent standard for persistence is unnecessary and will add confusion to those looking to adopt J2EE technology.
What are your thoughts? Do you want JDO to die? Or is there a place for a spec on a persistence model, not tied to the enterprise?

View the ballot results for: JSR #243 Java Data Objects 2.0

Threaded replies

·  JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle by Dion Almaer on Tue May 04 06:37:36 EDT 2004
  ·  No surprise that EJB vendors don't like JDO by David Tinker on Tue May 04 06:53:00 EDT 2004
    ·  No surprise that EJB vendors don't like JDO by Steve Lewis on Tue May 04 07:05:49 EDT 2004
    ·  No surprise that EJB vendors don't like JDO by Michael Davidovich on Tue May 04 07:20:06 EDT 2004
      ·  No surprise that EJB vendors don't like JDO by Robin Roos on Tue May 04 07:28:45 EDT 2004
      ·  No surprise that EJB vendors don't like JDO by Konstantin Ignatyev on Tue May 04 09:55:30 EDT 2004
    ·  No surprise that EJB vendors don't like JDO by David Jones on Tue May 04 10:55:47 EDT 2004
      ·  No surprise that EJB vendors don't like JDO by Eric Ma on Tue May 04 11:46:48 EDT 2004
        ·  No surprise that EJB vendors don't like JDO by Robin Roos on Tue May 04 11:55:44 EDT 2004
          ·  No surprise that EJB vendors don't like JDO by Erik Bengtson on Tue May 04 12:02:29 EDT 2004
          ·  No surprise that EJB vendors don't like JDO by rory Winston on Tue May 04 12:05:30 EDT 2004
          ·  No surprise that EJB vendors don't like JDO by Eric Ma on Tue May 04 12:22:17 EDT 2004
          ·  Appreciation to Robin Roos by Igor Shabalov on Tue May 04 13:02:15 EDT 2004
            ·  Appreciation to Robin Roos by Robin Roos on Tue May 04 13:09:14 EDT 2004
        ·  What to do with EJB 3.0 by Igor Shabalov on Tue May 04 12:45:16 EDT 2004
          ·  What to do with EJB 3.0 by Tom Crosman on Tue May 04 12:53:52 EDT 2004
          ·  What to do with EJB 3.0 by Robin Roos on Tue May 04 13:00:29 EDT 2004
          ·  What to do with EJB 3.0 by Matthew Adams on Wed May 05 10:33:53 EDT 2004
        ·  No surprise that EJB vendors don't like JDO by Juozas Baliuka on Tue May 04 12:56:20 EDT 2004
          ·  No surprise that EJB vendors don't like JDO by Robin Roos on Tue May 04 13:03:17 EDT 2004
            ·  No surprise that EJB vendors don't like JDO by Juozas Baliuka on Tue May 04 13:17:28 EDT 2004
      ·  No surprise that EJB vendors don't like JDO by Jerome Beau on Wed May 05 18:02:22 EDT 2004
    ·  Anything new here ? by Andy Jefferson on Tue May 04 12:29:23 EDT 2004
    ·  Another performance question by Gary Struthers on Tue May 04 17:10:53 EDT 2004
      ·  Another performance question by Igor Shabalov on Tue May 04 18:46:28 EDT 2004
      ·  Another performance question by Steve Lee on Tue May 04 19:48:16 EDT 2004
  ·  JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle by Robin Roos on Tue May 04 07:03:36 EDT 2004
    ·  JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle by johnyzee on Tue May 04 07:16:07 EDT 2004
  ·  JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle by Rod Johnson on Tue May 04 07:56:08 EDT 2004
    ·  JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle by Kris Schneider on Tue May 04 08:04:44 EDT 2004
      ·  On simplifying the programming model by Robin Roos on Tue May 04 08:13:11 EDT 2004
        ·  On simplifying the programming model by Rod Johnson on Tue May 04 09:36:15 EDT 2004
          ·  On simplifying the programming model by rory Winston on Tue May 04 09:41:59 EDT 2004
        ·  On simplifying the programming model by Cedric Beust on Tue May 04 10:11:53 EDT 2004
          ·  On simplifying the programming model by rory Winston on Tue May 04 10:15:19 EDT 2004
            ·  On simplifying the programming model by Scott Crawford on Tue May 04 10:38:53 EDT 2004
              ·  On simplifying the programming model by rory Winston on Tue May 04 11:28:51 EDT 2004
                ·  Let's keep J2EE Simple with one persistence model by Debu Panda on Tue May 04 12:07:51 EDT 2004
                  ·  Model and technology are orthogonal by me havename on Tue May 04 12:13:55 EDT 2004
                    ·  Model and technology are orthogonal by Mileta Cekovic on Tue May 04 12:34:42 EDT 2004
                    ·  Model and technology are orthogonal by Robin Roos on Tue May 04 12:54:38 EDT 2004
                      ·  Model and technology are orthogonal by Cedric Beust on Tue May 04 13:09:20 EDT 2004
                        ·  Model and technology are orthogonal by Robin Roos on Tue May 04 13:11:53 EDT 2004
                          ·  Model and technology are orthogonal by Cedric Beust on Tue May 04 14:11:34 EDT 2004
                            ·  JDO is a standard extension of J2SE by Robin Roos on Tue May 04 14:24:30 EDT 2004
                            ·  Political? by Ara Abrahamian on Wed May 05 03:23:43 EDT 2004
                    ·  Model and technology are orthogonal by Andy Grove on Wed May 05 07:52:26 EDT 2004
                      ·  Model and technology are orthogonal by Robin Roos on Wed May 05 08:17:50 EDT 2004
                      ·  Model and technology are orthogonal by Robin Roos on Wed May 05 08:32:40 EDT 2004
                        ·  Model and technology are orthogonal by Andy Grove on Wed May 05 08:41:13 EDT 2004
                          ·  Model and technology are orthogonal by Robin Roos on Wed May 05 08:46:49 EDT 2004
                      ·  DAO design pattern isn't by Jochen Bedersdorfer on Wed May 05 13:18:50 EDT 2004
                        ·  DAO design pattern isn't by Andy Stefancik on Wed May 19 10:43:23 EDT 2004
                    ·  Model and technology are orthogonal by Philip Murray on Wed May 05 10:29:30 EDT 2004
          ·  On simplifying the programming model by Robin Roos on Tue May 04 10:34:45 EDT 2004
            ·  On simplifying the programming model by Scott Crawford on Tue May 04 10:43:00 EDT 2004
        ·  JDO for Standalone & CMP for EJBs by ramesh loganathan on Wed May 05 00:30:18 EDT 2004
          ·  JDO for Standalone & CMP for EJBs by Robin Roos on Wed May 05 02:50:12 EDT 2004
          ·  JDO for Standalone & CMP for EJBs by David Tinker on Wed May 05 03:02:10 EDT 2004
            ·  JDO for Standalone & CMP for EJBs by ramesh loganathan on Wed May 05 09:00:18 EDT 2004
              ·  JDO for Standalone & CMP for EJBs by Robin Roos on Wed May 05 09:15:32 EDT 2004
          ·  Polymorphism and EJBs by Thomas Whitmore on Fri Jun 25 00:53:36 EDT 2004
        ·  Both have merits by peter lin on Wed May 05 10:10:29 EDT 2004
          ·  Both have merits by Robin Roos on Wed May 05 10:33:08 EDT 2004
            ·  me being unclear, duh! by peter lin on Thu May 06 09:55:24 EDT 2004
              ·  me being unclear, duh! by rory Winston on Thu May 06 12:00:37 EDT 2004
                ·  Mostly by peter lin on Thu May 06 13:09:17 EDT 2004
                  ·  Mostly by Abe White on Thu May 06 13:44:13 EDT 2004
                    ·  I would agree in limited cases by peter lin on Thu May 06 14:19:30 EDT 2004
                      ·  I would agree in limited cases by Robin Roos on Thu May 06 15:33:24 EDT 2004
                        ·  Politics vs common sense by peter lin on Thu May 06 16:38:21 EDT 2004
                          ·  EJB 3.0 at TSS Symposium, Las Vegas by Robin Roos on Thu May 06 19:56:44 EDT 2004
                            ·  EJB 3.0 at TSS Symposium, Las Vegas by Robin Roos on Thu May 06 20:15:04 EDT 2004
                            ·  EJB 3.0 at TSS Symposium, Las Vegas by Eric Ma on Thu May 06 21:55:35 EDT 2004
                              ·  EJB 3.0 at TSS Symposium, Las Vegas by Robin Roos on Thu May 06 22:09:52 EDT 2004
                                ·  EJB 3.0 at TSS Symposium, Las Vegas by Eric Ma on Fri May 07 08:49:54 EDT 2004
                                  ·  EJB 3.0 at TSS Symposium, Las Vegas by David Tinker on Fri May 07 09:31:48 EDT 2004
                                    ·  EJB 3.0 at TSS Symposium, Las Vegas by Eric Ma on Fri May 07 09:57:30 EDT 2004
                                      ·  EJB 3.0 at TSS Symposium, Las Vegas by Robin Roos on Fri May 07 10:19:18 EDT 2004
                                        ·  EJB 3.0 at TSS Symposium, Las Vegas by Eric Ma on Fri May 07 10:47:02 EDT 2004
                                          ·  EJB 3.0 at TSS Symposium, Las Vegas by David Tinker on Fri May 07 11:03:54 EDT 2004
                                            ·  EJB 3.0 at TSS Symposium, Las Vegas by Eric Ma on Fri May 07 13:33:56 EDT 2004
                                              ·  EJB 3.0 at TSS Symposium, Las Vegas by Robin Roos on Sat May 08 20:34:01 EDT 2004
                              ·  EJB 3.0 at TSS Symposium, Las Vegas by G Hermitage on Fri May 07 02:41:02 EDT 2004
          ·  But when you really need distributed objects by Mileta Cekovic on Wed May 05 10:43:16 EDT 2004
    ·  JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle by Marc Logemann on Tue May 04 08:09:23 EDT 2004
  ·  The dinosaurs don't want change by artful dodger on Tue May 04 08:03:25 EDT 2004
  ·  JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle by Cameron Purdy on Tue May 04 08:04:00 EDT 2004
  ·  And what is TopLink ? by sf fgdf on Tue May 04 08:09:43 EDT 2004
    ·  Ditto About IBM by John Watts on Tue May 04 09:31:11 EDT 2004
      ·  Ditto About IBM by Ruslan Zenin on Wed May 05 04:23:32 EDT 2004
        ·  Ditto About IBM by Robin Roos on Wed May 05 05:29:46 EDT 2004
          ·  Ditto About IBM by rory Winston on Wed May 05 05:38:52 EDT 2004
            ·  Ditto About IBM by Robin Roos on Wed May 05 05:43:55 EDT 2004
        ·  SDO, not redundant by l p on Wed May 05 09:47:32 EDT 2004
          ·  SDO, not redundant by Roland Barcia on Wed May 05 11:47:56 EDT 2004
  ·  JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle by rory Winston on Tue May 04 08:19:00 EDT 2004
    ·  JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle by Jean-claude bellando on Tue May 04 09:10:51 EDT 2004
  ·  JDO 2 Ballot Results: 3 no votes, 12 yes votes by Vilya Harvey on Tue May 04 08:58:22 EDT 2004
    ·  Pulp fiction.... by Alex V on Tue May 04 09:14:29 EDT 2004
    ·  JDO 2 Ballot Results: 3 no votes, 12 yes votes by Robin Roos on Tue May 04 09:21:25 EDT 2004
  ·  JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle by Rick Poole on Tue May 04 09:51:17 EDT 2004
  ·  What do you expect? by geoff hendrey on Tue May 04 13:26:34 EDT 2004
    ·  What do you expect? by rory Winston on Tue May 04 13:33:31 EDT 2004
    ·  Irony - JDO 1 vs EJB 3 by Robin Roos on Tue May 04 14:03:21 EDT 2004
      ·  Irony - JDO 1 vs EJB 3 by Rob Kischuk on Tue May 04 14:37:44 EDT 2004
        ·  Irony - JDO 1 vs EJB 3 by Robin Roos on Tue May 04 14:47:49 EDT 2004
        ·  is that a double irony? by geoff hendrey on Tue May 04 17:11:48 EDT 2004
          ·  is that a double irony? by Rolf Tollerud on Tue May 04 18:54:19 EDT 2004
  ·  Hibernate will take over by Michael Mattox on Tue May 04 13:59:53 EDT 2004
    ·  Hibernate won't take over by Robin Roos on Tue May 04 14:17:37 EDT 2004
      ·  Who said Hibernate won't take over? by Eric Ma on Tue May 04 14:41:38 EDT 2004
        ·  What Rally? by Michael Mattox on Wed May 05 03:44:38 EDT 2004
          ·  Question for Robin (Was: What Rally?) by rory Winston on Wed May 05 05:34:23 EDT 2004
            ·  Question for Robin by Robin Roos on Wed May 05 06:25:25 EDT 2004
              ·  Question for Robin by rory Winston on Wed May 05 07:04:57 EDT 2004
                ·  Question for Robin by Robin Roos on Wed May 05 07:50:04 EDT 2004
                  ·  JSR 220 by G Hermitage on Wed May 05 21:21:19 EDT 2004
                    ·  Transparent Persistence not in EJB? by ramesh loganathan on Wed May 05 23:20:22 EDT 2004
                      ·  Transparent Persistence by G Hermitage on Thu May 06 00:31:13 EDT 2004
                        ·  Transparent Persistence by ramesh loganathan on Thu May 06 06:58:09 EDT 2004
                          ·  Transparent Persistence by ramesh loganathan on Thu May 06 07:05:46 EDT 2004
                          ·  Transparent Persistence by G Hermitage on Thu May 06 08:29:29 EDT 2004
                            ·  Transparent Persistence by Michal Maczka on Thu May 06 09:04:00 EDT 2004
                      ·  Transparent Persistence not in EJB? by rory Winston on Thu May 06 05:21:26 EDT 2004
                        ·  Transparent Persistence not in EJB? by Michal Maczka on Thu May 06 07:36:18 EDT 2004
                          ·  Transparent Persistence not in EJB? by Michal Maczka on Thu May 06 07:39:26 EDT 2004
                          ·  Transparent Persistence not in EJB? by johnyzee on Thu May 06 08:35:19 EDT 2004
                            ·  Transparent Persistence not in EJB? by G Hermitage on Thu May 06 09:00:44 EDT 2004
                          ·  Transparent Persistence not in EJB? by G Hermitage on Thu May 06 08:37:16 EDT 2004
                            ·  Transparent Persistence not in EJB? by Michal Maczka on Thu May 06 09:11:10 EDT 2004
                              ·  Transparent Persistence not in EJB? by Henrique Steckelberg on Thu May 06 09:53:54 EDT 2004
                                ·  Transparent Persistence not in EJB? by Michal Maczka on Thu May 06 10:39:48 EDT 2004
                                  ·  Transparent Persistence not in EJB? by Michal Maczka on Thu May 06 10:46:10 EDT 2004
                                    ·  Transparent Persistence not in EJB? by G Hermitage on Fri May 07 02:51:15 EDT 2004
                                  ·  Transparent Persistence not in EJB? by Henrique Steckelberg on Thu May 06 11:22:12 EDT 2004
                                    ·  Transparent Persistence not in EJB? by Michal Maczka on Thu May 06 14:27:36 EDT 2004
                                      ·  Transparent Persistence not in EJB? by Henrique Steckelberg on Thu May 06 15:43:12 EDT 2004
                          ·  Transparent Persistence Showdown by Robin Roos on Thu May 06 08:37:29 EDT 2004
                            ·  Transparent Persistence Showdown by Robin Roos on Thu May 06 09:55:43 EDT 2004
                            ·  Transparent Persistence Showdown by Michal Maczka on Thu May 06 09:56:23 EDT 2004
                            ·  Transparent Persistence Showdown: JDX Equivalent by Damodar Periwal on Thu May 06 15:36:42 EDT 2004
                          ·  Transparent Persistence not in EJB? by Juozas Baliuka on Thu May 06 11:13:34 EDT 2004
      ·  Hibernate won't take over by Michael Mattox on Wed May 05 03:03:08 EDT 2004
        ·  Hibernate won't take over by Geni Lavalle on Wed May 05 03:45:40 EDT 2004
        ·  Hibernate won't take over by Robin Roos on Wed May 05 04:23:37 EDT 2004
    ·  Hibernate is just Hype-rnate by Hans Marggraff on Thu Sep 16 09:45:03 EDT 2004
  ·  Message to Oracle, IBM, and BEA from a Pragmatic Viewpoint by David McCuistion on Tue May 04 14:31:57 EDT 2004
    ·  Message to Oracle, IBM, and BEA from a Pragmatic Viewpoint by Erik Bengtson on Tue May 04 15:53:13 EDT 2004
      ·  Message to Oracle, IBM, and BEA from a Pragmatic Viewpoint by Robin Roos on Tue May 04 17:14:51 EDT 2004
        ·  Message to Oracle, IBM, and BEA from a Pragmatic Viewpoint by Igor Shabalov on Tue May 04 18:57:49 EDT 2004
          ·  Best DAO is... by Vic Cekvenich on Tue May 04 19:51:27 EDT 2004
            ·  Remember the result of the case study .NET vs. J2EE by Lofi Dewanto on Tue May 04 21:01:11 EDT 2004
              ·  Remember the result of the case study .NET vs. J2EE by Juozas Baliuka on Wed May 05 03:47:02 EDT 2004
                ·  JDO today by Marc Logemann on Wed May 05 04:01:11 EDT 2004
                ·  Oracle showed .NET Petstore wasn't that fast by peter lin on Wed May 05 10:30:58 EDT 2004
                  ·  Oracle showed .NET Petstore wasn't that fast by Juozas Baliuka on Wed May 05 12:29:29 EDT 2004
          ·  Message to Oracle, IBM, and BEA from a Pragmatic Viewpoint by George de la Torre on Tue May 04 22:06:18 EDT 2004
            ·  Message to Oracle, IBM, and BEA from a Pragmatic Viewpoint by Eric Ma on Tue May 04 23:47:10 EDT 2004
      ·  Message to Oracle, IBM, and BEA from a Pragmatic Viewpoint by Rasmus Lund on Tue May 04 18:51:12 EDT 2004
  ·  Sun YES, SAP YES, IONA YES, NOKIA YES, APACHE YES, FUJITSU YES, by geoff hendrey on Tue May 04 21:28:50 EDT 2004
    ·  jdo spec by hichem hassania on Wed May 05 06:44:00 EDT 2004
  ·  Go JDO! by Tom Davies on Tue May 04 22:11:19 EDT 2004
  ·  And the winner is... by Gregory Chazalon on Wed May 05 03:39:15 EDT 2004
  ·  Let's not mess up this one! by Yagiz Erkan on Wed May 05 06:43:21 EDT 2004
  ·  Consider vendors' motivations by Matthew Adams on Wed May 05 11:42:37 EDT 2004
  ·  why 4 ejb vendors? by Amin Mansuri on Wed May 05 15:47:35 EDT 2004
    ·  why 4 ejb vendors? by Robin Roos on Wed May 05 16:08:42 EDT 2004
      ·  why 4 ejb vendors? by Robin Roos on Wed May 05 16:52:53 EDT 2004
        ·  Comparing SDO to Detachment in JDO 2.0 by Robin Roos on Fri May 07 03:23:18 EDT 2004
  ·  Interpretation of what each vendor is saying by Seong-yong Kim on Wed May 05 18:51:40 EDT 2004
    ·  Object and Relational don't compete by Cedric ROUVRAIS on Fri Dec 24 10:16:46 EST 2004
  ·  I don't know what is JDO..... by Yimin Shi on Fri Aug 27 01:01:24 EDT 2004
  Message #120527 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: David Tinker on May 04, 2004 in response to Message #120524
Hi All

Its hardly surprising that 3 EJB vendors do not like JDO, especially since two of them are also database vendors. A database and runtime environment independent standard for Java persistence is the last thing they want.

"JDO, whose market acceptance is essentially constrained to use with object databases"

This is plain FUD. There are many JDO implementations available with many customers and nearly all of them are aimed at relational databases.

Cheers
David
www.jdogenie.com - High performance JDO for relational databases

  Message #120528 Post reply Post reply Post reply Go to top Go to top Go to top

JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle

Posted by: Robin Roos on May 04, 2004 in response to Message #120524
So it is perceived legitimate to argue against JDO on the grounds that attempts to simplify a component-based model for persistent data (Entity Beans) in JSR-220, which might hit the streats in a year or more, somehow obviates the need for furthering an EXISTING standard for transparent persistence of POJOs?

I'm rather amused, but the fact that BEA, IBM and Oracle forgot to put smiley faces after their comments makes me wonder if they're actually serious after all!?

I'd like to thank those members of the Executive Committee who voted in favour of JDO 2.0 (including Macromedia).

Kind regards, Robin.

  Message #120529 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: Steve Lewis on May 04, 2004 in response to Message #120527
Yeah, this just in: the Pope is Catholic. But seriously, why can't these guys talk about synergy? In any other context they'd be tripping over themselves to pontificate about the big changes ahead.

Now when there's a chance to actually deliver something to developers that they want, other interests come first. That's okay. The market will take their actions into account in the long run.

It's obvious now why JDO it took forever to get a basic JDO spec out the door in the first place: from what it sounds like these guys have been against it from day 1.

Steve

  Message #120530 Post reply Post reply Post reply Go to top Go to top Go to top

JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle

Posted by: johnyzee on May 04, 2004 in response to Message #120528
What BEA, Oracle and IBM fail to understand is that we don't want no stinkin' entity beans, even if they chop off a heel and a toe to make it less of a pain than it is now. Or perhaps it is just not in their best interests to support the adoption of lightweight solutions that don't tie us down to application server and/or tools vendors.

  Message #120531 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: Michael Davidovich on May 04, 2004 in response to Message #120527
too late, Hibernate already crushing these EJB conspiracy!

Michael

  Message #120532 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: Robin Roos on May 04, 2004 in response to Message #120531
I believe the EJB 2.0 / J2EE 1.5 specification leads have an obligation to listen to the community. The current specifications result in J2EE application servers having an exceptionally high cost of development, resulting in a pretty closed shop. The spec leads have a duty of care to make their specifications more widely implementable, and the best route is to make Entity Beans OPTIONAL in the EJB 3.0 spec. The application server market could be opened up to organizations who might like to build a compliant server but see no point in implementing Entity Beans or CMR.

Then the light-weight containers so popular on TSS might engineer themselves to become J2EE-compliant, and people will use them with JDO or Hibernate.

  Message #120536 Post reply Post reply Post reply Go to top Go to top Go to top

JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle

Posted by: Rod Johnson on May 04, 2004 in response to Message #120524
But why should persistence be tied to the EJB specification? What about web applications running in web containers? What about standalone apps?

I see a real value for JDO, not only in the context of J2EE applications using EJB, but in a wider range of contexts.

Regards,
Rod

  Message #120539 Post reply Post reply Post reply Go to top Go to top Go to top

The dinosaurs don't want change

Posted by: artful dodger on May 04, 2004 in response to Message #120524
Of cource the dinosaurs don't want this? It would make their bulky, hard to use, unflexible object modeling systems irrelevant. What I don't like is the fact that not only do they not support jdo2 but they want to impede it.

Be happy, use Hibernate.

 -Peace

  Message #120540 Post reply Post reply Post reply Go to top Go to top Go to top

JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle

Posted by: Cameron Purdy on May 04, 2004 in response to Message #120524
I'm just curious: What other standardized Java object/relational persistence specifications are available for J2SE? I don't see how JDO overlaps anything in that arena.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

  Message #120541 Post reply Post reply Post reply Go to top Go to top Go to top

JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle

Posted by: Kris Schneider on May 04, 2004 in response to Message #120536
What about standalone apps?
Exactly. How is EJB 3.0 supposed to help with a two-tiered desktop app?
I see a real value for JDO, not only in the context of J2EE applications using EJB, but in a wider range of contexts.
JSR 243 also includes this:

A subset of functionality would be appropriate for J2ME but this will require a separate JSR.

Kris

  Message #120542 Post reply Post reply Post reply Go to top Go to top Go to top

JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle

Posted by: Marc Logemann on May 04, 2004 in response to Message #120536
Totally agree with Rod on this one. A lot of people need J2SE persistence mechanisms and people want alternatives to proprietary ORM mapping tools like toplink or cocobase. JDO provides just that. Besides that many J2EE developers dont want to fiddle around with Entity Beans and we all like alternatives. Thats the way the java community works, having alternatives. The market will decide what technology will win.

A really poor decission that the application server vendors voted with "no". But we can all do our work and say to the said companies and their representatives that we dont appreciate that.

  Message #120543 Post reply Post reply Post reply Go to top Go to top Go to top

And what is TopLink ?

Posted by: sf fgdf on May 04, 2004 in response to Message #120524
"Having 2 specifications address the same problem space with different APIs, persistence and transaction semantics, mapping definitions and query mechanisms does not contribute to the effort of simplifying J2EE and making it easier to use." ... "another independent standard for persistence is unnecessary and will add confusion to those looking to adopt J2EE technology." (Oracle)

If they only want *one* technology for persistance, why did Oracle buy Toplink for ? Toplink is "another independent standard for persistence".

Hibernate, not a standard, just the only good choice ;).

  Adrien

  Message #120544 Post reply Post reply Post reply Go to top Go to top Go to top

On simplifying the programming model

Posted by: Robin Roos on May 04, 2004 in response to Message #120541
The JSR-220 submission talks about simplification of the EJB programming model. Unlike JDO 2.0 which was conducted in public until our JSR-243 was approved yesterday, JSR-220 is taking place behind closed doors until such time as a draft specification is available. This makes it hard for outsiders (my application to join JSR-220 was declined) to know what form their work is taking.

Based on the JSR submission document, a heavy emphasis is being placed on JSR-175 Metadata extensions to reduce the size and complexity of deployment descriptors, and to remove the need for the developer to provide home and remote interfaces as all required information could be marked up in the bean class itself. This would be welcome progress, although these techniques have been used for years by X-Doclet adopters and are not exactly new.

What we cannot tell is how JSR-220 will address specific limitations of the Entity Bean model in particular - just being able more simply to write the same deficient entity beans does not necessarily help. What about polymorphism? What about dynamic queries? What about testability? What about in-and-out of container operation? What about, dare I say it, transparency? And without the ability to encapsulate data, can entity beans ever be more than mere data structures? In its current incarnation the concept of a "behaviourally complete" object model built with entity beans is utterly laughable.

So where is the Entity Bean value-add?

Entity Beans have method-level permissions which JDO does not have. The JDO folks generally feel it inappropriate to restrict access to persistent objects at the method level as it's really a business process thing and belongs in the application itself at the point of transaction demarcation. Entity Beans have container-managed relationships, because entity beans are merely data structures and cannot undertake their own relationship management effectively. The JDO folks believe Java developers can manage associations through the object model in various ways, and that a "persistence" service should not alter the way that the object model behaves. Everything else that Entity Beans can do is more easily, more appropriately and more flexibly done by JDO (e.g. transparency, polymorphism, testability, dynamic queries, O/R mapping) independent of the presence of a Web/J2EE container.

If the JSR-220 folks simplify the programming model for EJBs then the community will be happy. But imagine the accolades they would receive were they to adopt JDO, make it accessible directly by the developer, and additionally provide a "method-level permissions service" (for those who want one) to augment POJOs!

Kind regards, Robin.

  Message #120546 Post reply Post reply Post reply Go to top Go to top Go to top

JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle

Posted by: rory Winston on May 04, 2004 in response to Message #120524
This is not a huge surprise. Maybe the EJB vendors are freaked by the success of lightweight persistence mechanisms. Anyways, it doesn't change the facts - EJBs are now widely regarded as old hat, and almost everywhere I go, I find people who have tried EJB implementations and discarded them in favour of lightweight alternatives, as well as architects who won't even consider EJBs for new implementations. I think this is a hiccup, and not a fatal setback.

  Message #120549 Post reply Post reply Post reply Go to top Go to top Go to top

JDO 2 Ballot Results: 3 no votes, 12 yes votes

Posted by: Vilya Harvey on May 04, 2004 in response to Message #120524
There seem to have been a few posts assuming that this stops JDO 2 from proceeding. It should be pointed out that the result of the ballot was "yes" overall: 12 votes for, 3 against, with only Borland not having voted. So JDO 2 will continue to move forward in spite of the objections from companies with, as has been pointed out, vested interests elsewhere.

  Message #120550 Post reply Post reply Post reply Go to top Go to top Go to top

JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle

Posted by: Jean-claude bellando on May 04, 2004 in response to Message #120546
Definitely not a surprise but ridiculous IBM, BEA, Oracle's customers refused EJB 1.0, are refusing EJB 2.0.
As we say in France "never 2 without 3" so EJB 3.0 will come and will continue to disapoint people.

  Message #120551 Post reply Post reply Post reply Go to top Go to top Go to top

Pulp fiction....

Posted by: Alex V on May 04, 2004 in response to Message #120549
...result of vote for NSR-672 (#ibernate - Ligth persistance for C# objects).
Yes = 13 : No = 4. Among 4 No votes 3 were representatives of
NET.DO vendors and Rolf Tolerud. Rolf commented his vote as revenge
for killing his baby - NSR-531 (C#pring).

  Message #120552 Post reply Post reply Post reply Go to top Go to top Go to top

JDO 2 Ballot Results: 3 no votes, 12 yes votes

Posted by: Robin Roos on May 04, 2004 in response to Message #120549
Yes, let's not forget that the ballot did approve JSR-243 for further development. The public discussions which the expert group members have been having must now go behind closed doors until the draft specification is ready for publication.

There are only a few JDO experts actually resident in France, but if you go to Cannes at the time of the JAOO conference you might bump into quite a few of us as we work towards a pre-JavOne publication milestone.

  Message #120556 Post reply Post reply Post reply Go to top Go to top Go to top

Ditto About IBM

Posted by: John Watts on May 04, 2004 in response to Message #120543
"This JSR proposes to develop extensions to JDO that apparently overlap with existing Java technologies and with other JSRs that are already in-progress. In a context where the Java community is working to simplify J2EE, it is undesirable to produce multiple overlapping ways of programming the same function."

What about SDO and SWT?

-- John

  Message #120559 Post reply Post reply Post reply Go to top Go to top Go to top

On simplifying the programming model

Posted by: Rod Johnson on May 04, 2004 in response to Message #120544
What we cannot tell is how JSR-220 will address specific limitations of the Entity Bean model in particular
Indeed. Voting to prevent evolution of JDO is dangerous when JDO 2.0 has already taken shape and will be very powerful, while EJB 3.0 is just talk--even if it's sounding like promising talk. Important new JDO 2.0 features such as attach/detach are already available in robust implementations. EJB 3.0 is still in the inception phase and has a long way to go to be a workable reality.

But as seveal people have pointed out, JDO 2.0 is going to happen anyway, so there's limited point in dwelling on the dissenting minority voices.

  Message #120560 Post reply Post reply Post reply Go to top Go to top Go to top

On simplifying the programming model

Posted by: rory Winston on May 04, 2004 in response to Message #120559
Exactly. Look at the popularity of the lightweight transparent persistence model. People like it because it's easy, it facilitates rapid development, it's portable, and it's got a low ongoing cost. I don't think you could level these claims at EJB, and I'm not sure how much EJB 3.0 is going to change this at all.

  Message #120561 Post reply Post reply Post reply Go to top Go to top Go to top

JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle

Posted by: Rick Poole on May 04, 2004 in response to Message #120524
As many others have pointed out apparently IBM, BEA, and Oracle have forgotten about the non-J2EE world. Of course there is going to be some overlap, but what is wrong with that? As much as I would have liked to use J2EE for our environment it just wasn't the right fit. Having a good persistence mechanism is very important to our project and so far we have been pleased at the ease of programming with JDO. We tried Toplink but it had too many bugs and was too hard to get working correctly so we switched to Solarmetric's Kodo and have had good results. If there were no JDO, we'd probably just go back to straight JDBC.

  Message #120562 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: Konstantin Ignatyev on May 04, 2004 in response to Message #120531
too late, Hibernate already crushing these EJB conspiracy!Michael
There is no such thing as EJB conspiracy but not so smart implementers who mistaken Entity Beans ( especially CMP ) for general ORM. Guys: CMP is a joke - agreed and should not be used, bThere is no such thing as EJB conspiracy but not so smart implementers who mistaken Entity Beans ( especially CMP ) for general ORM. Guys: CMP is a joke - agreed and should not be used, but when it comes to distributed persistence then a well defined Entity Bean life cycle is what we need. Hibernate backed BMP is a way to go in 1-3 % cases.

As for JDO: there is no need for it to be among core APIs. It is time to start cleaning core Java/EJB and make them smaller and better.
ut when it comes to distributed persistence then a well defined assun

  Message #120563 Post reply Post reply Post reply Go to top Go to top Go to top

On simplifying the programming model

Posted by: Cedric Beust on May 04, 2004 in response to Message #120544
The JSR-220 submission talks about simplification of the EJB programming model. Unlike JDO 2.0 which was conducted in public until our JSR-243 was approved yesterday, JSR-220 is taking place behind closed doors until such time as a draft specification is available.
Robin, you are right that such has been the case so far but it's going to change soon. There are two EJB 3.0 events at TheServerSymposium this coming week:

- A presentation by Linda de Michiel
- A BOF to discuss with the community and get feedback.

More information:

http://wiki.theserverside.com/symposium/display/MEETINGS/Home
http://www.theserverside.com/symposium/schedule.html

--
Cedric

  Message #120564 Post reply Post reply Post reply Go to top Go to top Go to top

On simplifying the programming model

Posted by: rory Winston on May 04, 2004 in response to Message #120563
<quote>
- A presentation by Linda de Michiel
- A BOF to discuss with the community and get feedback.
</quote>

Shouldn't the community have been involved before now?

  Message #120568 Post reply Post reply Post reply Go to top Go to top Go to top

On simplifying the programming model

Posted by: Robin Roos on May 04, 2004 in response to Message #120563
Hi Cedric. Thanks for letting us know. I participated actively in an EJB 3.0 BOF at OT2004 last month. This event was led by Scott Crawford and was thoroughly enjoyable.

The 3-hour workshop ended with a balloon debate: we all took "issues" about EJB and voted the less important ones off the balloon until only three remained. My issue, that the Entity Bean architecture "fails to support the design of behaviourally rich domain models", was eventually voted off. The three issues which remained in the balloon and were deemed "most important" included:

- Testability
- Support for Transparent Persistence
- Unchecked Exceptions

You can read more about this particular workshop at OT2004. I'd like to thank Scott for a most exhilarating and (I hope) constructive event.

  Message #120570 Post reply Post reply Post reply Go to top Go to top Go to top

On simplifying the programming model

Posted by: Scott Crawford on May 04, 2004 in response to Message #120564
Shouldn't the community have been involved before now?
There have been many, many community inputs into the EJB 3.0 JSR. A few examples:

   http://servlet.java.sun.com/javaone/sf2003/conf/bofs/display-2264.en.jsp
   http://www.xpdeveloper.com/xpdwiki/Wiki.jsp?page=Xtc20031014
   http://www.theserverside.com/news/thread.tss?thread_id=23670
   http://www.ot2004.org/cgi-bin/wiki.pl/?TowardsEjbThree

And there's always jsr-220-comments@jcp.org for anyone with views and access to e-mail.

  Message #120571 Post reply Post reply Post reply Go to top Go to top Go to top

On simplifying the programming model

Posted by: Scott Crawford on May 04, 2004 in response to Message #120568
Thanks Robin. I'm glad you enjoyed the event at OT2004. The URL you provided is one of the four I cited just above.

Best
Scott

  Message #120574 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: David Jones on May 04, 2004 in response to Message #120527
I think it is about time we called it at day with Entity Beans and let JDO become the spec for defining how to persist your model in J2EE. Entity Beans (Distributed Persistence Components) were never design for what people want and are using them for.

It also sounds like EJB 3.0 is going to be the second attempt to turn them into something they where never meant to be and fit that square peg into a round hole again.

  Message #120579 Post reply Post reply Post reply Go to top Go to top Go to top

On simplifying the programming model

Posted by: rory Winston on May 04, 2004 in response to Message #120570
OK, but where can we get a clear idea of where the overlap actually is? Is there anywhere we can get an overview of how the JDO transparent/declarative persistence interferes or overlaps with the proposed EJB implementations, and in what manner?

  Message #120581 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: Eric Ma on May 04, 2004 in response to Message #120574
I think it is about time we called it at day with Entity Beans and let JDO become the spec for defining how to persist your model in J2EE.
+1. Deprecate entity beans in EJB 3.0 and move all types of persistence to JDO 2.0.

  Message #120582 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: Robin Roos on May 04, 2004 in response to Message #120581
+1. (predictably!)

Doing this would MASSIVELY increase the credibility of EJB and, by association, that of J2EE also.

Vendors using Entity Beans for the one thing they were reasonably good at (access to legacy non-relational data) would have to engineer a PersistenceManager-based solution before the deprecated beans were no longer supported, but that in itself is not a showstopper as JDO was defined with this in mind (it is, after all, datastore agnostic).

Two questions arise:
1. Do the JSR-220 folks agree?
2. Are they bold enough?

  Message #120584 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: Erik Bengtson on May 04, 2004 in response to Message #120582
I hope that at the time EJB 3.0 is released, JDO 2.0 spec is a old one.

  Message #120585 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: rory Winston on May 04, 2004 in response to Message #120582
...JDO was defined with this in mind (it is, after all, datastore agnostic).
This is one of the best things about the JDO spec, IMHO.
1. Do the JSR-220 folks agree?
2. Are they bold enough?
I'm not holding my breath! Still, you never know...

  Message #120586 Post reply Post reply Post reply Go to top Go to top Go to top

Let's keep J2EE Simple with one persistence model

Posted by: Debu Panda on May 04, 2004 in response to Message #120579
In my opinion (not my Company's) either the simplified EJB as part of 3.0 or JDO 3.0 should be part of J2EE 1.5. As is J2EE is too complex and is NOT ALL attractive for new developers and many new additions will distract new developers. Looks like the primary goal for J2EE 1.5 to simplify development and having two persistence model will again confuse the developers .. EJBs have been in use by several enterprise and J2EE being for Enterprise EJB is the right choice. As several guys in the community pointed that JDO has several other usage other than the persistence model for J2EE applications let Sun keep this as a separate JSR and separate standard. Many and many JSRs is making J2EE complex and .NET is gaining ground. As JCP has been sponsoring the TSS Symposium they must be fan of this community and the JCP expert committee must be reading all these threads and listening the complaints about EJB. What we hear about the new EJB 3.0 model it looks like these guys have heard all our complaints and trying to address these.

Looks like JBoss/Hibernate is also fully engaged with EJB 3.0 as evident from http://www.infoworld.com/article/04/04/30/HNfleury_1.html and they must be loving the fact EJB 3.0 is being modelled after Hibernate. would be interested to know their take on the controversy for JDO 2.0 vs 3.0 as Gavin is part of both the committees

  Message #120587 Post reply Post reply Post reply Go to top Go to top Go to top

Model and technology are orthogonal

Posted by: me havename on May 04, 2004 in response to Message #120586
The technology used to persist objects should be *pluggable*. I should be able to use Hibernate or JDO or anything I want to. The more you try to design a spec to be able to do this, the more you see that the EJB *contract* is the right one.

  Message #120589 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: Eric Ma on May 04, 2004 in response to Message #120582
Two questions arise:
1. Do the JSR-220 folks agree?
2. Are they bold enough?
I hope the expert group members see the writing on the wall and show some courage on this. But IMHO it will probably not matter whether they deprecate entity beans or not, because nobody will use entity beans for future development and people are leaving entity beans in droves. So instead of keeping a bloated EJB spec, I hope they spec team find it easier to take the unwanted part out of the spec completely.

Now BEAS, IBM, and ORCL all have invested a lot of money on entity beans technology, and they need to find a way to recover some of the investment before they throw their support behind JDO 2.0. Fine. For ORCL, it is easy - make TopLink JDO compliant. For IBM, also easy - buy a JDO/ORM vendor. For BEA, eh - try to get the best deal when it is bought by ORCL.

  Message #120590 Post reply Post reply Post reply Go to top Go to top Go to top

Anything new here ?

Posted by: Andy Jefferson on May 04, 2004 in response to Message #120527
So it really is refreshing for such well respected bodies as IBM, BEA, and Oracle to provide a full analysis of the drawbacks of JDO 2.0. Have they actually listened to their users requirements, or just to their accountants maybe ?

Who gets voting rights for these things ? Perhaps since these bodies are clearly not reflecting the needs of their users they should be removed.

  Message #120592 Post reply Post reply Post reply Go to top Go to top Go to top

Model and technology are orthogonal

Posted by: Mileta Cekovic on May 04, 2004 in response to Message #120587
>> The technology used to persist objects should be *pluggable*. I should be able to use Hibernate or JDO or anything I want to. The more you try to design a spec to be able to do this, the more you see that the EJB *contract* is the right one.

I think you missed the point. JDO is pluggable (you can use different JDO implementation if you like). JDO API is somewhat like JDBC or JMS. That is the point, make the object persistence a service, a resource, not a container feature.

  Message #120594 Post reply Post reply Post reply Go to top Go to top Go to top

What to do with EJB 3.0

Posted by: Igor Shabalov on May 04, 2004 in response to Message #120581
I think it is about time we called it at day with Entity Beans and let JDO become the spec for defining how to persist your model in J2EE.
+1. Deprecate entity beans in EJB 3.0 and move all types of persistence to JDO 2.0.
And make Hibernate JDO 2.0 compatible.

Best,
Igor.

  Message #120597 Post reply Post reply Post reply Go to top Go to top Go to top

What to do with EJB 3.0

Posted by: Tom Crosman on May 04, 2004 in response to Message #120594
Hear! Hear!

  Message #120598 Post reply Post reply Post reply Go to top Go to top Go to top

Model and technology are orthogonal

Posted by: Robin Roos on May 04, 2004 in response to Message #120587
The technology used to persist objects should be *pluggable*. I should be able to use Hibernate or JDO or anything I want to. The more you try to design a spec to be able to do this, the more you see that the EJB *contract* is the right one.
J2SE already has a POJO-persistence technology that works in a plain JVM, in a Web container and in a J2EE container.

Why should J2EE simultaneously engineer a POJO-like persistence technology that ONLY works inside an EJB container?

Yes, the object model should be independent of the persistence technology (JDO achieves this).

Yes, the application should be independent of the datastore (JDO achieves this).

If you want the application additionally to be independent of the persistence technology then you must facade the persistence technology, either by detached operation or by some DAO-like concept. But beware that DAO implementations tend to be very invasive, often resulting in lowest-common denominator functionality. They can also perform badly for that reason. For example, how would you represent persistence-by-reachability in a DAO interface?

I argue that PersistenceManager already IS the DAO interface for all object persistence across all datastores.

  Message #120599 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: Juozas Baliuka on May 04, 2004 in response to Message #120581
I think it is about time we called it at day with Entity Beans and let JDO become the spec for defining how to persist your model in J2EE.
+1. Deprecate entity beans in EJB 3.0 and move all types of persistence to JDO 2.0.
+1

I think you have found the best way to solve this problem, just drop EJB and it will be no conflicts and fragmentations.

  Message #120600 Post reply Post reply Post reply Go to top Go to top Go to top

What to do with EJB 3.0

Posted by: Robin Roos on May 04, 2004 in response to Message #120594
And make Hibernate JDO 2.0 compatible.
The JDO 2.0 standard lifts barriers to entry such that Hibernate could become JDO-compliant. Instead of using our bytecode enhancement they could use their own! However, there have been few statements regarding JDO 2.0 coming out of the JBoss camp recently, either pro or anti. It is possible that they are focussing more on EJB 3.0 concept proving right now.

  Message #120601 Post reply Post reply Post reply Go to top Go to top Go to top

Appreciation to Robin Roos

Posted by: Igor Shabalov on May 04, 2004 in response to Message #120582
+1. (predictably!)Doing this would MASSIVELY increase the credibility of EJB and, by association, that of J2EE also. Vendors using Entity Beans for the one thing they were reasonably good at (access to legacy non-relational data) would have to engineer a PersistenceManager-based solution before the deprecated beans were no longer supported, but that in itself is not a showstopper as JDO was defined with this in mind (it is, after all, datastore agnostic). Two questions arise: 1. Do the JSR-220 folks agree?2. Are they bold enough?
I'd like to say thank to Robin Roos, for good posts!

It’s clear, that EJB concept has problems. Such reaction from community is absolutely predictable and I do not understand why smart people from IBM, BEA and ORACLE still decided to declare there positions. Whatever the money spent for EJB, it is very risky decision to invest more resources into such compromised idea. Big Bosses and shareholders of IBM, BEA and ORACLE probably need to think again.

Best,
Igor.

  Message #120602 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: Robin Roos on May 04, 2004 in response to Message #120599
blockquote>+1 I think you have found the best way to solve this problem, just drop EJB and it will be no conflicts and fragmentations.We need to be careful about terminology here. Dropping EJB is not something I would support. Many JDO users will want to exploit the services of Session and MessageDriven Beans for large server-side applications (although others are content with just Web components).

It is the Entity Bean component of EJB that has been superceded.

  Message #120604 Post reply Post reply Post reply Go to top Go to top Go to top

Appreciation to Robin Roos

Posted by: Robin Roos on May 04, 2004 in response to Message #120601
I'd like to say thank to Robin Roos, for good posts!
Thanks, Igor.

I try to focus on Technology and not get too carried away with Religion - I hope that comes across and is helpful.

  Message #120605 Post reply Post reply Post reply Go to top Go to top Go to top

Model and technology are orthogonal

Posted by: Cedric Beust on May 04, 2004 in response to Message #120598
J2SE already has a POJO-persistence technology that works in a plain JVM, in a Web container and in a J2EE container.
Can you be more specific?

J2SE only has JDBC and RowSets, none of which are POJO-based.

--
Cedric

  Message #120606 Post reply Post reply Post reply Go to top Go to top Go to top

Model and technology are orthogonal

Posted by: Robin Roos on May 04, 2004 in response to Message #120605
JDO is a standard extension - javax.jdo. In this form it is an official part of J2SE. It is not part of the JDK download which is a different story. Did you think otherwise?

  Message #120608 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: Juozas Baliuka on May 04, 2004 in response to Message #120602
I see no problems to drop EJB, CMP/BMP are the best candidate to drop. Probably statefull beans can be usefull in some cases, but I think any real programmer can implement this kind of framework (wrapper for RMI and JMS) at home (2 - 3 days to work) and can do it better than EJB.

  Message #120609 Post reply Post reply Post reply Go to top Go to top Go to top

What do you expect?

Posted by: geoff hendrey on May 04, 2004 in response to Message #120524
This is totally what I would expect from companies that have staked their technical reputations on EJB. EJB has dragged developers through the mud for practically half a decade. Not because EJB sucks, but because big companies have mutilated EJB into a persistence tool which it was never intended to be.

It doesn't matter to me one iota that app-server vendors don't support JDO. JDO is a developer-friendly tool that you can use without an expensive application server. How could THE BIG GUYS support JDO? Hell, they'd lose half their consulting revenues because JDO just works!

Anyway, it doesn't matter. Developers have already realized they'd be screwed if they kept using EJB for persistence. That is why open source POJO persistence tools like Hibernate and JDO have become popular.

-geoff

  Message #120611 Post reply Post reply Post reply Go to top Go to top Go to top

What do you expect?

Posted by: rory Winston on May 04, 2004 in response to Message #120609
Last week I spoke with some very savvy developers from a financial software company. They are making a big Java investment right now, and prototyped their implementation using EJBs. 7 months later they ditched EJBs entirely, and moved to a more lightweight model. Their results, cost, and speed of development speak for themselves. This is a typical and common user story. I'm reluctant to slag off the EJB 3.0 spec until I see it in more detail, however. Someone earlier said
[Hibernate-backed BMP]is a way to go in 1-3 % cases
and
well defined Entity Bean life cycle
for the rest. I disagree. Looking at the current generation of EJBs, I would say that EJBs as they stand, are suited to about 3% of users needs. The rest can be fulfilled quite nicely by a lightweight framework.

  Message #120614 Post reply Post reply Post reply Go to top Go to top Go to top

Hibernate will take over

Posted by: Michael Mattox on May 04, 2004 in response to Message #120524
JDO is already lagging behind Hibernate and with these votes it looks like JDO may die. I've done two projects with JDO and I feel like I'm the only one. All my coworkers and associates have used Hibernate but none of them have used JDO. I must say, on my next project I will choose Hibernate.

Michael Mattox

  Message #120615 Post reply Post reply Post reply Go to top Go to top Go to top

Irony - JDO 1 vs EJB 3

Posted by: Robin Roos on May 04, 2004 in response to Message #120609
Developers have already realized they'd be screwed if they kept using EJB for persistence. That is why open source POJO persistence tools like Hibernate and JDO have become popular.-geoff
There is irony in the fact that JDO 1.0.1 actually achieves most of what a developer needs for persistence from witin an EJB container. JDO 1.0.1 has been around for ages. Developers do indeed find it a pleasure to use.

And yet IBM, BEA and Oracle choose to argue against JSR-243 (JDO 2.0) on the grounds of its overlap with EJB 3.0. Whatever elements are eventually seen to commprise the overlap, it is probably the EJB 3.0 elements that are actually overlapping with JDO 1!

JDO 2.0 adds some neat stuff, but JDO 1 was never shown to be broken. That's why we were confident to watch JDO adoption and speak to users for some time before starting work on JDO 2.0 back in June 2003.

Kind regards, Robin.

  Message #120617 Post reply Post reply Post reply Go to top Go to top Go to top

Model and technology are orthogonal

Posted by: Cedric Beust on May 04, 2004 in response to Message #120606
JDO is a standard extension - javax.jdo. In this form it is an official part of J2SE. It is not part of the JDK download which is a different story. Did you think otherwise?
I guess I have a more simplistic view of what an "official part of J2SE" is...

If I can't do "javap javax.jdo.PersistenceManager" on a standard JDK, then it's not part of J2SE to me...

--
Cedric

  Message #120618 Post reply Post reply Post reply Go to top Go to top Go to top

Hibernate won't take over

Posted by: Robin Roos on May 04, 2004 in response to Message #120614
Hi Micahel

I remember our early discussions about JDO and acknowledge your sentiment.

However, J2EE needs a good standard for persistence. History will record that Gavin King did not lead a JSR to extract the essence of transparent persistence from Hibernate into an open standard to foster competition and adoption. Instead it was Craig Russell who led JSR-12 to do the same but from an ODMG and Forte Transparent Persistence background. The JCP standard in this area is therefore JDO and not Hibernate.

There is a healthy community of approx 20 JDO implementations. But if you look through the replies to date on this thread you will see a marked absence of vendor-push from the likes of Solarmetric, LIBeLIS, Versant etc. And even David Tinker's original comment was more about dispelling FUD than promoting JDOGenie. Instead the support *for* JDO in this thread has come largely from the community.

  Message #120620 Post reply Post reply Post reply Go to top Go to top Go to top

JDO is a standard extension of J2SE

Posted by: Robin Roos on May 04, 2004 in response to Message #120617
If I can't do "javap javax.jdo.PersistenceManager" on a standard JDK, then it's not part of J2SE to me...
I'll speak to Joshua Bloch about this, but as far as I know we've gone as far with JDO as is possible within the JCP concerning J2SE. The JCP certainly regards JDO as a J2SE technology of equal standing with the others you mention....

  Message #120623 Post reply Post reply Post reply Go to top Go to top Go to top

Message to Oracle, IBM, and BEA from a Pragmatic Viewpoint

Posted by: David McCuistion on May 04, 2004 in response to Message #120524
Since most of the principle-based arguments have already been well made, I hope to make an obvious pragmatic argument for JDO 2.0.

We have applications that needed to ship "yesterday," so we use a lightweight persistence framework that is available today and has a future. JDO 1.0.1 works. It isn't the most convenient to use for web applications, but it beats anything else out there for our needs. With JDO 2.0, we finally have nearly all the features we need. Our vendor is already implementing some JDO2 features that we desperately need and now use. Can EJB3 meet our needs? To be honest, I don't know. Why? Because I can't download it and use it.

So why try to kill a specification before the "competing" specification isn't yet finished, nevermind that there aren't any implementations. We need something today and something next week. We don't need something that might arrive on our desktops next year.

Oracle, IBM, BEA: I'd be glad to listen to your arguments for killing JDO when you have something I can actually compare to JDO 2.0. I may even agree with you and switch to EJB3. But not today and not until you can at least match the JDO 2.0 spec. We have products to ship.

  Message #120624 Post reply Post reply Post reply Go to top Go to top Go to top

Irony - JDO 1 vs EJB 3

Posted by: Rob Kischuk on May 04, 2004 in response to Message #120615
There is irony in the fact that JDO 1.0.1 actually achieves most of what a developer needs for persistence from witin an EJB container. JDO 1.0.1 has been around for ages. Developers do indeed find it a pleasure to use.And yet IBM, BEA and Oracle choose to argue against JSR-243 (JDO 2.0) on the grounds of its overlap with EJB 3.0. <snip/> JDO 2.0 adds some neat stuff, but JDO 1 was never shown to be broken.
While JDO 1.0 wasn't explicitly broken, the omission of specifying the O-R Mapping mechanism is a critical shortcoming. Without it, portability across JDO implementations is just a pipe dream. Simply adding O-R mapping to JDO could be asserted as an overlap with Entity Bean CMP. JDO 2.0 needs to happen as the JSR states before it's ready for widespread adoption, otherwise each JDO implementation is, practically speaking, non-standard. And if it's non-standard, why limit yourself to JDO?

  Message #120625 Post reply Post reply Post reply Go to top Go to top Go to top

Who said Hibernate won't take over?

Posted by: Eric Ma on May 04, 2004 in response to Message #120618
The JCP standard in this area is therefore JDO and not Hibernate. Instead the support *for* JDO in this thread has come largely from the community.
I think it is worthwhile to point out that the decidedly pro-JDO sentiment shown in this thread owes largely to the fact that the JDO expert group seems to be more open-minded than the EJB expert group. I hate to say that prior to JDO accepting Gavin King to the expert group, JDO was in a sorrier state than entity beans today in terms of developer adoption and critical vendor support. Now people rally behind JDO 2.0 because it makes more sense then EJB 3.0 after the stated intention of ORM support in JDO 2.0. Please never loose sight of that.

  Message #120626 Post reply Post reply Post reply Go to top Go to top Go to top

Irony - JDO 1 vs EJB 3

Posted by: Robin Roos on May 04, 2004 in response to Message #120624
Simply adding O-R mapping to JDO could be asserted as an overlap with Entity Bean CMP. JDO 2.0 needs to happen as the JSR states before it's ready for widespread adoption, otherwise each JDO implementation is, practically speaking, non-standard. And if it's non-standard, why limit yourself to JDO?
I take your point, Rob, and the O/R Mapping aspect of JDO 2.0 is one of its most important features. But what you're talking about is essentially the portavility of JDO metadata being constrained, and then only if you use pretty esoteric mappings.

Many companies choose Oracle (or another named database) as a strategic deployment platform. They are happy to code an application to that end. JDO 1 standardizes their object persistence through the JDO APIs. To move from one vendor to anohther they would have to have undertaking an exercise to port the JDO metadata, leaving standard application and code and domain object model designs unaltered. This is still an extremely viable strategy.

Anyway, we have JSR-243 now. Soon we should be able to publish a draft of the spec for public review, and quickly move JDO 2.0 into reality.

Kind regards, Robin.

  Message #120633 Post reply Post reply Post reply Go to top Go to top Go to top

Message to Oracle, IBM, and BEA from a Pragmatic Viewpoint

Posted by: Erik Bengtson on May 04, 2004 in response to Message #120623
Oracle, IBM, BEA: I'd be glad to listen to your arguments for killing JDO when you have something I can actually compare to JDO 2.0. I may even agree with you and switch to EJB3. But not today and not until you can at least match the JDO 2.0 spec. We have products to ship.
They might be waiting JDO 2.0 spec be out to do just a copy and paste to EJB 3.0

  Message #120641 Post reply Post reply Post reply Go to top Go to top Go to top

Another performance question

Posted by: Gary Struthers on May 04, 2004 in response to Message #120527
Since everyone’s here, I want to repeat my JDO performance question. Many say they like JDO and it’s easy to use. I have yet to see claims that in production JDO performance is as good or nearly as good as Hibernate, TopLink, or plain JDBC. I left out entity beans deliberately. And how do JDO generated database schema’s stack up?

Gary

  Message #120642 Post reply Post reply Post reply Go to top Go to top Go to top

is that a double irony?

Posted by: geoff hendrey on May 04, 2004 in response to Message #120624
There is irony in the fact that JDO 1.0.1 actually achieves most of what a developer needs for persistence from witin an EJB container. JDO 1.0.1 has been around for ages. Developers do indeed find it a pleasure to use.And yet IBM, BEA and Oracle choose to argue against JSR-243 (JDO 2.0) on the grounds of its overlap with EJB 3.0. <snip/> JDO 2.0 adds some neat stuff, but JDO 1 was never shown to be broken.
While JDO 1.0 wasn't explicitly broken, the omission of specifying the O-R Mapping mechanism is a critical shortcoming. Without it, portability across JDO implementations is just a pipe dream. Simply adding O-R mapping to JDO could be asserted as an overlap with Entity Bean CMP. JDO 2.0 needs to happen as the JSR states before it's ready for widespread adoption, otherwise each JDO implementation is, practically speaking, non-standard. And if it's non-standard, why limit yourself to JDO?
Lack of a standard O/R mapping in JDO 1 cannot possibly be a realistic argument against JDO 1 when the most popular alternative (Hybernate) has a totally non-standard O/R mapping, because in fact, there is no "standard". Lack of standard O/R mapping can't be seen as a shortcoming of any tool today.

The fact is that with the participation of Hybernate folks, and others, there is going to be a standard O/R mapping format. JDO will be the only technology that lets you truly achieve standards based plug-and-play persistence without the bloat of a EJB container;

JDO IS the technology that is driving standardization of O/R mapping (via JDO 2.0). Once the JDO 2.0 standard O/R mappings are in place, THEN we can talk about the shortcomings of other technologies that don't implement standard POJO persistence with standard O/R mapping.

Entity Beans are dead. Actually they are more like Zombies from Night of The Living Dead, being kept alive long after they should be dead and buried.

  Message #120643 Post reply Post reply Post reply Go to top Go to top Go to top

Message to Oracle, IBM, and BEA from a Pragmatic Viewpoint

Posted by: Robin Roos on May 04, 2004 in response to Message #120633
They might be waiting JDO 2.0 spec be out to do just a copy and paste to EJB 3.0
Well then, we'll just have to publish the JDO 2.0 spec for them quickly. I'd hate us to be responsible for delaying another JSR. ;-)

I presume that the TSS Symposium is going well. I'd expected discussion to heat up still further as the USA came on-line, but presumably they're all in Las Vegas!

  Message #120651 Post reply Post reply Post reply Go to top Go to top Go to top

Another performance question

Posted by: Igor Shabalov on May 04, 2004 in response to Message #120641
Since everyone’s here, I want to repeat my JDO performance question. Many say they like JDO and it’s easy to use. I have yet to see claims that in production JDO performance is as good or nearly as good as Hibernate, TopLink, or plain JDBC. I left out entity beans deliberately. And how do JDO generated database schema’s stack up?Gary
When you talking about JDO - you need to point to specific implementation, JDO is just a spec.

I'm using JDO in every my project at least for last year (several projects total) and I never have problems with performance. In fact I’d like to see any "home-grown plain JDBC" implementation with full support of transparent persistence, full implementation of transaction isolation and multi-level distributed cache. And than we will see how it performs :-)

Best,
Igor.

  Message #120652 Post reply Post reply Post reply Go to top Go to top Go to top

Message to Oracle, IBM, and BEA from a Pragmatic Viewpoint

Posted by: Rasmus Lund on May 04, 2004 in response to Message #120633
Oracle, IBM, BEA: I'd be glad to listen to your arguments for killing JDO when you have something I can actually compare to JDO 2.0. I may even agree with you and switch to EJB3. But not today and not until you can at least match the JDO 2.0 spec. We have products to ship.
They might be waiting JDO 2.0 spec be out to do just a copy and paste to EJB 3.0
Yes. That would prove them right regarding the big overlap between JDO and EJB :-)

  Message #120653 Post reply Post reply Post reply Go to top Go to top Go to top

is that a double irony?

Posted by: Rolf Tollerud on May 04, 2004 in response to Message #120642
Geoff: "Entity Beans are dead. Actually they are more like Zombies from Night of The Living Dead, being kept alive long after they should be dead and buried."

OSCAR WILDE: I wish I had said that.
WHISTLER: Ah, you will, Oscar, you will.

I hope you don't mind if I borrow your statement? :)

Regards
Rolf Tollerud

  Message #120654 Post reply Post reply Post reply Go to top Go to top Go to top

Message to Oracle, IBM, and BEA from a Pragmatic Viewpoint

Posted by: Igor Shabalov on May 04, 2004 in response to Message #120643
Nobody is arguing about useless of Entity Beans there, - so not enough fuel for discussion :-)

What we actually see is some sort of arguing between Hibernate and JDO folks. IMHO the best will be to combine together best features from both - say specifically ether add more transparent persistence, life cycle management and such to Hibernate, or add standard ORM to JDO, - or both.
One of the problem of JDO - lack of big vendor and (or) big open source community. Hibernate is by far lead between OS ORM, so it consolidate support from people. JDO - is a dozen of small vendors, a lot of vendor-related uncertainty, and spread of support (and inter-JDO competition).
Once somebody from big guys bye some JDO vendor - we will see different picture.

Best,
Igor.

  Message #120656 Post reply Post reply Post reply Go to top Go to top Go to top

Another performance question

Posted by: Steve Lee on May 04, 2004 in response to Message #120641
Since everyone’s here, I want to repeat my JDO performance question. Many say they like JDO and it’s easy to use. I have yet to see claims that in production JDO performance is as good or nearly as good as Hibernate, TopLink, or plain JDBC. I left out entity beans deliberately. And how do JDO generated database schema’s stack up?Gary
JDO provides as good if not better performance (due to more sophisticated field tracking) as O/R software (and certainly without the EJB overhead). Performance is dependent on the implementation (though since JDO is standardized, comparing is quite feasible). And while there certainly are simple cases where JDBC can beat all, the more complex the situation the better these persistence layers will perform in comparison.

Most if not all JDO implementations allow you to customize the schema generated, most likely matching what is already there from DBA or legacy.

  Message #120657 Post reply Post reply Post reply Go to top Go to top Go to top

Best DAO is...

Posted by: Vic Cekvenich on May 04, 2004 in response to Message #120654
iBatis of course, better than Hibrenate.

Since the specs don't care about what community want's, why should the comunity care about JCP standards?
Users use popular standards, such as Struts (not a JCP standard), Apache Jakata Commons, etc.

http://news.netcraft.com/archives/web_server_survey.html = you should only use popular stuff, not vendor propriatory stuff.

Why EJB suck:
http://www.softwarereality.com/programming/ejb/index.jsp

One sample app in Struts/iBatis is www.basicPortal.com, used by several large clients, listed on above web site.


.V

  Message #120661 Post reply Post reply Post reply Go to top Go to top Go to top

Remember the result of the case study .NET vs. J2EE

Posted by: Lofi Dewanto on May 04, 2004 in response to Message #120657
<vic>
iBatis of course, better than Hibrenate.
</vic>

sorry Vic but did you read the result of the latest case study of .NET vs. J2EE? TSS had 2 types of J2EE applications:
- J2EE + Servlet/JSP + EJB CMP and
- J2EE + Servlet/JSP only (it used JPetstore implementation)

All the results showed that only J2EE + Servlet/JSP + EJB CMP had a chance to fight against the power of .NET. JPetstore was very slow to compare with two other implementations in that test.

It would be very interesting to see JDO impl. and Hibernate in the same test...

Cheers,
Lofi.

  Message #120663 Post reply Post reply Post reply Go to top Go to top Go to top

Sun YES, SAP YES, IONA YES, NOKIA YES, APACHE YES, FUJITSU YES,

Posted by: geoff hendrey on May 04, 2004 in response to Message #120524
OK, I ran out of space in the title to finish all the organizations (not even counting individual experts) who voted YES on JD0 2.0. Apple Also voted YES. SO while a few giants voted NO, several giants voted YES along with EVERYONE else!
==============================================================================

On 2004-04-30 Sun Microsystems, Inc. voted Yes with the following comment:
This is in response to some of the comments on JSR 243 "JDO 2.0".

If JDO did not exist, it might be a worthy topic for debate as to
whether the Java community should invest in this area. I can see
pros and cons on both sides. But JDO does exist, and it has a loyal
user community who want to see it continued and extended. Sun, as
specification lead for JDO, is responding to what we perceive as
legitimate community demand for evolving JDO.

Sun believes that there is space for both JDO and EJB. I hope the
expert groups can cooperate to minimize any unnecessary differences
in areas where they overlap. Whether or not JDO should be included in
J2EE is an issue for a future J2EE expert group to debate.

Given that JDO exists and has attracted significant interest from
the Java community, I think it is appropriate to allow it to continue
to evolve, based on the feedback and requirements from its users.

                                                     - Graham

------------------------------------------------------------------------------
On 2004-04-20 Lea, Doug voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-04-20 SAP AG voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-04-20 Monson-Haefel, Richard voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-04-22 IONA Technologies PLC voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-04-26 Nokia Networks voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-04-26 BEA Systems voted No with the following comment:
JDO is one of many different persistence solutions in server-side Java today. With J2EE 1.5 emphasis on simplification and ease of use, we don't see how having another release of JDO, whose market acceptance is essentially constrained to use with object databases, can be explained in conjunction to similar enhancements being made in the EJB3 expert group. We are also concerned about taking JDO into new areas such as disconnected data set support until we better understand how ball of these solutions fit together. Unless the submitters can explain how all of this fits together, we believe the Java community would be better served with fewer apparently competing alternatives.
------------------------------------------------------------------------------
On 2004-04-26 Apache Software Foundation voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-04-30 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-04-30 IBM voted No with the following comment:
This JSR proposes to develop extensions to JDO that apparently overlap with existing Java technologies and with other JSRs that are already in-progress. In a context where the Java community is working to simplify J2EE, it is undesirable to produce multiple overlapping ways of programming the same function.
------------------------------------------------------------------------------
On 2004-04-30 Macromedia, Inc. voted Yes with the following comment:
While undesirable overlap does appear to exist between JDO and other JSRs, the feedback we have long heard on this particular subject is that Java application developers prefer to adjudicate the overlap themselves rather than have the decision enforced for them by platform vendors. The community appears to desire a choice between persistence technologies even at the expense of the additional platform complexity and fragmentation that the overlaps between those technologies can cause. We consider our vote in favor of this JSR to reflect not an architectural platform aesthetic, but instead to reflect the more practical majority sentiment long and loudly expressed by customers and others in the community.
------------------------------------------------------------------------------
On 2004-05-02 Caldera Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-05-03 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-05-03 Apple Computer, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-05-03 Oracle voted No with the following comment:
JDO 2.0 overlaps with the work being done by the EJB 3.0 expert group to provide a lightweight persistence model. Having 2 specifications address the same problem space with different APIs, persistence and transaction semantics, mapping definitions and query mechanisms does not contribute to the effort of simplifying J2EE and making it easier to use. The direction of lightweight persistence being taken by the EJB 3.0 group will have tremendous appeal to mainstream enterprise Java developers, even those who are critical of the current Entity Bean model. Given the evolution of EJB 3.0 persistence, another independent standard for persistence is unnecessary and will add confusion to those looking to adopt J2EE technology.

------------------------------------------------------------------------------

  Message #120665 Post reply Post reply Post reply Go to top Go to top Go to top

Message to Oracle, IBM, and BEA from a Pragmatic Viewpoint

Posted by: George de la Torre on May 04, 2004 in response to Message #120654
>"Nobody is arguing about useless of Entity Beans there, - so not enough fuel for discussion :-)"

Exactly, really the only problem with Entity Beans was the assumption that J2EE developers could design good enough architecture. Entity Beans and J2EE technology is way beyond the means of the masses as this board proves without a doubt.

Its the useless ability of "Entity is bad" incompetent J2EE developers which engages in empty tank discussions.

Its really frustrating to see so many people telling everybody about their inadequacies by blaming technology they don't understand.

If Entity Beans are not appropriate for your project, then it doesn't mean its not appropriate for others.

The JSP hacks are just out of control...

  Message #120666 Post reply Post reply Post reply Go to top Go to top Go to top

Go JDO!

Posted by: Tom Davies on May 04, 2004 in response to Message #120524
I'm happily using JDO *today* in both J2EE and non-J2EE contexts, and I want the standard to advance.

  Message #120670 Post reply Post reply Post reply Go to top Go to top Go to top

Message to Oracle, IBM, and BEA from a Pragmatic Viewpoint

Posted by: Eric Ma on May 04, 2004 in response to Message #120665
If Entity Beans are not appropriate for your project, then it doesn't mean its not appropriate for others.
The JSP hacks are just out of control...
If you have a few minutes, do you mind enlightening us on the circumstances under which enity beans are appropriate? I am very curious.

  Message #120672 Post reply Post reply Post reply Go to top Go to top Go to top

JDO for Standalone & CMP for EJBs

Posted by: ramesh loganathan on May 05, 2004 in response to Message #120544
At some level isnt it comparing Apples vs. Oranges? JDO is very good for standalone applications. And for applications that have OO well enmeshed into the persistence layers. But in an EJB context, for biz apps, there is very little value that JDO offers.

The often cited Polymorphism and Testability- are they of much use? In a biz app, how often would one want to inherit a "DB class"? Informix had this amazingly well conceived OR-DBMS. Which provided for all these capabilities- at the DB table level! Didnt do a swat in the market! The usage of table (by extension the persisted classes) level inheritance is a very niche segment. Most biz apps wont need this capability. Testability may be of some value- again here in a class that wraps DB tables, only thing that may need to be tested is the queries. A standalone EQL execution tool may help. But this is not of much value.

About the metadata, if one is anyway dealing with the EJB XMLs such as ejb-jar XML and vendor XMLs, is the incremental cost of using CMP is lower than that of using JDOs? Which have its own XMLs to deal with. One sure shortcoming in CMP is the lack of dynamic queries.

But otherwise, there is very little value (and probably more painful) to use JDOs in an EJB app (in JSP/Servlets- the arguments may not be the same). ( More on my blog).

Cheers,
Ramesh

  Message #120678 Post reply Post reply Post reply Go to top Go to top Go to top

JDO for Standalone & CMP for EJBs

Posted by: Robin Roos on May 05, 2004 in response to Message #120672
Hi Ramesh. I read your blog - you write very well.

There is still some wild use of the acronym EJB. There are complaints in this thread regarding the unsuitability of Entity EJBs, but there have been no complaints about the other EJB types.

Entity Beans were defined to represent data that could benefit from the EJB container&#8217;s services of remoteness, declarative transactions and method-level permissions. They also exploit the server's bean pooling policies, but 1.4.2 JDKs largely remove the need through faster object instantiation, and JDO implementations are free to pool instances if they choose.

Since then, it has been realised in the field that data usually should not be remote, and that method-level permissions and declarative transactions belong in the business process and not in the persistent data underpinning that process.

Polymorphism in JDO includes the ability to persist a reference to an instance of a subclass or interface implementing instance, and get back that same object on iterating a query. And yes, although inheritance should not be used inadvisably, there are good rules governing its applicability. Here are two examples of inheritance in a real financial persistent domain model.

Position : holding of an instrument in an account
CompoundPosition extends Position : composite position made up of sub-positions

Instrument : a financial instrument
InstrumentWithCoupon extends Instrument : instruments which pay dividends
Currency extends Instrument : instruments recognized on the money markets

So those are real inheritance hierarchies which satisfy the "is-a" rule (and Peter Coad's other rules for inheritance). In JDO, if you query for Instruments you might get some Currencies, at which time your reference actually points to a Currency object (not just its Instrument representation).

JDO is indeed excellent for stand-alone applications. But it is also excellent for Web/J2EE container-based apps. And you can use it against the same datastore from all these different architectures at the same time!!! It provides a degree of future proofing that your stand-alone application can scale to the enterpise. Entity beans lock you into a J2EE container from the start of your application design. This should no longer be acceptable to the community (evidence the concerns expressed about Entity Beans) and with JSR-220 underway perhaps now is the time to get something done about the situation.

Kind regards, Robin.

  Message #120683 Post reply Post reply Post reply Go to top Go to top Go to top

JDO for Standalone & CMP for EJBs

Posted by: David Tinker on May 05, 2004 in response to Message #120672
Hi Ramesh
in an EJB context, for biz apps, there is very little value that JDO offers. The often cited Polymorphism and Testability- are they of much use? In a biz app, how often would one want to inherit a "DB class"?
Well thats probably because domain models built for entity beans have to be simple. You cannot use the full range of OO design techniques that are available with JDO. Limited, EJB style models work for PetStore type apps. Real world business apps benefit from JDO.

Cheers
David
www.jdogenie.com

  Message #120684 Post reply Post reply Post reply Go to top Go to top Go to top

Hibernate won't take over

Posted by: Michael Mattox on May 05, 2004 in response to Message #120618
Hi MicahelI remember our early discussions about JDO and acknowledge your sentiment.However, J2EE needs a good standard for persistence. History will record that Gavin King did not lead a JSR to extract the essence of transparent persistence from Hibernate into an open standard to foster competition and adoption. Instead it was Craig Russell who led JSR-12 to do the same but from an ODMG and Forte Transparent Persistence background. The JCP standard in this area is therefore JDO and not Hibernate.There is a healthy community of approx 20 JDO implementations. But if you look through the replies to date on this thread you will see a marked absence of vendor-push from the likes of Solarmetric, LIBeLIS, Versant etc. And even David Tinker's original comment was more about dispelling FUD than promoting JDOGenie. Instead the support *for* JDO in this thread has come largely from the community.
Yes Robin we go back a few years now but what I'm saying is that since then JDO has lost momentum big time. First off, to address your first point: There are two types of standards: Open and defacto. The fact that Hibernate didn't come out of a JSR doesn't bother me the least bit. I think the JDO process is too political, with each compan promoting their selfish concerns instead of what's best for the user. This is very bad for JDO! SUN/BEA/IBM are torturing people with EJB & Entity Beans and making a fortune doing it! It's understandable that they're not going to embrace JDO. So a bloated, inefficient, tangled process involving big companies who want to push their $10,000/cpu servers doesn't concern me. What concerns me are:

- Does it work?
- Can I get support
- Is there a future?
- Is it widely used? (This is to discuss best practices, etc.)
- Is there a book available? (Great for new members to a project)
- Is it free? (perhaps the most important)

Fortunately the answers for these issues are all YES for Hibernate. Most are yes for JDO except:

- JDO doesn't seem to be as widely used as Hibernate, especially in Europe
- JDO isn't free (yes there are open source implementations but last I checked they were not feature complete)

Don't underestimate the free issue. Yes, there are inexpensive implementations like Kodo (about $800/developer last I checked) but just the process of getting a company to buy a product like this can take longer than the project. There's all kinds of beaurocratic hurdles to overcome. When it's free we just use it and there is no discussion.

Michael

  Message #120686 Post reply Post reply Post reply Go to top Go to top Go to top

Political?

Posted by: Ara Abrahamian on May 05, 2004 in response to Message #120617
I just want to ask EJB vendors these questions:
- do have any technical reasons for voting against JDO? Specially considering the mess EJB is and EJB3 will be because of the inherent flaws in EJB/CMP architecture.
- I think the -1 votes were just political. So what's the real political reason for voting againt JDO? You just don't want to let JDO kiddies in your club? You don't want to let Hibernate/JBoss be influential in forming the spec? You want to lock people to the container and squeeze them? :-) What?
- Do you actually care what the community demands??
- Will I get any answers to these questions? Of course not :-)

Ara.

  Message #120687 Post reply Post reply Post reply Go to top Go to top Go to top

And the winner is...

Posted by: Gregory Chazalon on May 05, 2004 in response to Message #120524
Guess who's is clapping to this right now ?

Yes, you found it, Microsoft and its .NET staff !!!
I believe any technical orientation taken by the JCP, which has been guided by marketshare/competitor actual positions rather than by overall improvement and enterprise Java marketshare progress is a bad thing for the Java folks.
In the end, these kind of arguments between the JCP members will only slow down innovation and weaken enterprise Java against Microsoft.

Keep in mind that "David" has to be way better than "Goliath" (e.g. ease of development, deployment, overall cost ownership etc..) in order to win the fight.

The most suprising is the "No" from BEA, which does not have any RDBMS on its own. I would have expect a different position from them..


Happy coding anyway

Gregory

  Message #120688 Post reply Post reply Post reply Go to top Go to top Go to top

What Rally?

Posted by: Michael Mattox on May 05, 2004 in response to Message #120625
Now people rally behind JDO 2.0 because it makes more sense then EJB 3.0 after the stated intention of ORM support in JDO 2.0. Please never loose sight of that.
What rally? JDO 2.0 is taking so long it's losing momentum. Gavin King joining the group was a huge boost but now we see JDO going backwards. Meanwhile Hibernate is going forwards. JDO is losing marketshare as we speak. Are the hibernate users going to switch to a non-free JDO implementation when JDO 2.0 comes out? I think it will be too late.

Michael Mattox

  Message #120689 Post reply Post reply Post reply Go to top Go to top Go to top

Hibernate won't take over

Posted by: Geni Lavalle on May 05, 2004 in response to Message #120684
Most are yes for JDO except:
- JDO doesn't seem to be as widely used as Hibernate, especially in Europe
- JDO isn't free (yes there are open source implementations but last I checked they were not feature complete)
On the second issue, JPOX (http://www.jpox.org) *does* pass the JDO TCK. It implements several of the "optional" parts of the JDO 1.0.1 spec as well.

  Message #120690 Post reply Post reply Post reply Go to top Go to top Go to top

Remember the result of the case study .NET vs. J2EE

Posted by: Juozas Baliuka on May 05, 2004 in response to Message #120661
<vic>iBatis of course, better than Hibrenate.</vic>sorry Vic but did you read the result of the latest case study of .NET vs. J2EE? TSS had 2 types of J2EE applications:- J2EE + Servlet/JSP + EJB CMP and- J2EE + Servlet/JSP only (it used JPetstore implementation)All the results showed that only J2EE + Servlet/JSP + EJB CMP had a chance to fight against the power of .NET. JPetstore was very slow to compare with two other implementations in that test. It would be very interesting to see JDO impl. and Hibernate in the same test...Cheers,Lofi.
Test results are very dependant on tester and I am sure this test is lame or political. Probably JPetstore is not the fasted
application in the world and I do not think somebody have tried to tune it, single thing you need to tune is a RDBMS (add more cache and create indexes). I am afraid it is not so trivial to tune EJB (How do you trace query plan in EBQL ?).

  Message #120692 Post reply Post reply Post reply Go to top Go to top Go to top

JDO today

Posted by: Marc Logemann on May 05, 2004 in response to Message #120690
A few words about the state of JDO:

1. look at this very own thread and you know what credibility JDO has
2. i noticed hibernate in every 3rd post, even hibernate is good, at large companies i see more JDO adoption (and of course EJB).
3. the post that you dont need DB classes inheritance is quite funny (just because EJB designers cant do it, doesnt mean its useless)
4. Good to see that also Richard M.H. voted with yes, i assume he is more involved with EJB than most of us, but this didnt prevented him to vote with yes.

  Message #120694 Post reply Post reply Post reply Go to top Go to top Go to top

Ditto About IBM

Posted by: Ruslan Zenin on May 05, 2004 in response to Message #120556
What about SDO and SWT?
Exactly! IBM and BEA came up with already redundant quick spec Service Data Objects that has disconnected data sets

Shouldn't they first check existing JSRs to see if there is already something available (JDO2)?

Looks really clumsy how these folks (IBM & BEA) are trying to "camouflage" their “control technology” agenda.

  Message #120695 Post reply Post reply Post reply Go to top Go to top Go to top

Hibernate won't take over

Posted by: Robin Roos on May 05, 2004 in response to Message #120684
Hi Michael
The fact that Hibernate didn't come out of a JSR doesn't bother me the least bit.
Me neither. I have clients who will adopt Hibernate and clients who will not adopt Hibernate. Some of those that have discounted Hibernate, after varying degrees of consideration of its technical abilities, did so on the grounds that it is an open source product that does not implement a standard.

However, since Hibernate is not a JCP standard it will not be adopted as a persistence solution by J2EE itself.

If JBoss/Hibernate decided to work with the JDO folks to (a) make Hibernate implement JDO, and (b) convince the J2EE/EJB people that JDO was the correct JCP standard for persistence from the single VM to the Web/EJB Container, then we could probably make things happen together. Hibernate's branding is very strong, and its market share could increase further from such a collaboration. And if we managed to get transparent persistence on the agenda for J2EE it would be good for Java and bad for .NET. Putting the weight of all transparent persistence advocates behind the message "JDO for J2EE" would bee awsome!

Kind regards, Robin.

  Message #120711 Post reply Post reply Post reply Go to top Go to top Go to top

Ditto About IBM

Posted by: Robin Roos on May 05, 2004 in response to Message #120694
Shouldn't they first check existing JSRs to see if there is already something available (JDO2)?
For the record, although work on JDO 2.0 began with our much publicised meeting in DC in August 2003, the review ballot to approve JSR-243 for further development only completed on 03 May 2004. It is the comments accompanying that vote which gave rise to this thread.

JSR-220 (EJB 3.0) was approved for further development on 09 June 2003.

At DC we drafted our JSR proposal, but huge delays inside Sun prevented the JSR from being submitted until very recently. Although I have no specific information, one can speculate as to the extent to which politics amongst the major J2EE players played its part in this delay. We took advantage of the delay by being more public about our proposals and progress than is possible now that the JSR has been approved.

  Message #120714 Post reply Post reply Post reply Go to top Go to top Go to top

Question for Robin (Was: What Rally?)

Posted by: rory Winston on May 05, 2004 in response to Message #120688
What rally? JDO 2.0 is taking so long it's losing momentum
I don't agree with this one, not from what I can see of the process, anyways.
Hibernate is going forwards. JDO is losing marketshare as we speak. Are the hibernate users going to switch to a non-free JDO implementation when JDO 2.0 comes out? I think it will be too late
Actually, I think the ideal situation (and one echoed by Gavin King and Bill Burke a while back) is that Hibernate will evolve a JDO 2.0 compliant interface. So you can still use Hibernate. This would be a good thing - Hibernate has a lot going for it.

I am curious about a few things, that I would like to ask Robin directly:

How do Dennis Leung and Mike Keith fit into the JDO 2.0 dpec panel now? What does the -1s by their employers signify for their involvement in the process going forward?

  Message #120715 Post reply Post reply Post reply Go to top Go to top Go to top

Ditto About IBM

Posted by: rory Winston on May 05, 2004 in response to Message #120711
At DC we drafted our JSR proposal, but huge delays inside Sun prevented the JSR from being submitted until very recently. Although I have no specific information, one can speculate as to the extent to which politics amongst the major J2EE players played its part in this delay. We took advantage of the delay by being more public about our proposals and progress than is possible now that the JSR has been approved.
I think this will be the key to the success of failure of JDO - its visibility and transparency amongst the community at large. In essence, it will probably need to follow the lead of Hibernate on this score.

  Message #120717 Post reply Post reply Post reply Go to top Go to top Go to top

Ditto About IBM

Posted by: Robin Roos on May 05, 2004 in response to Message #120715
I think this will be the key to the success of failure of JDO - its visibility and transparency amongst the community at large. In essence, it will probably need to follow the lead of Hibernate on this score.
And Hibernate sets a good example for JDO to follow: widespread adoption and brand recognition necessarily precede ubiquity.

  Message #120722 Post reply Post reply Post reply Go to top Go to top Go to top

Question for Robin

Posted by: Robin Roos on May 05, 2004 in response to Message #120714
Hi Rory
How do Dennis Leung and Mike Keith fit into the JDO 2.0 dpec panel now? What does the -1s by their employers signify for their involvement in the process going forward?
The JCP governs the Java platforms in an open and reasonably democratic manner. It is the prerogative of each executive committee member to vote for or against any JSR. This makes Java so very different from .Net.

The expert group for JSR-243 (JDO 2.0) has yet to be formed officially, although I'm sure that process is well in hand. Oracle is presently listed as a member and I strongly doubt they would withdraw - there's certainly no need for them to do so. The JDO 2.0 JSR was approved despite their objections and I trust that they will continue to work with us as closely as possible, so that the final specification is one which they will see fit to promote.

Dennis Leung has been on the JDO 2.0 email alias since late August 2003, with the specific intention of keeping Oracle informed at a senior level about the evolution of JDO away from strict binary compatibility (a spec-mandated implementation strategy) to a position where JDO no longer mandates the implementation strategy, but instead accommodates alternative implementation architectures. This position is now well entrenched in JDO 2.0 and I would be wary of any movement back towards the spec mandating PersistenceCapable as the implementation strategy, even though I believe it remains the "best" approach in the absence of native persistence hooks in the JVM itself. I don't think Dennis will be Oracle's technical representative for JSR-243, but he will certainly have access/input to our discussions through that representative.

Michael Keith, Oracle's technical representative throughout the public evolution of JDO 2.0 in its pre-JSR phase, is a pleasure to work with. With his great insight and congenial manner he quickly won my respect and that of many if not all of the others in the group. He and I argue for different sides of some discussions, but I trust that the agreements the group has reached to date satisfy Oracle's requirements as well as those of the wider Java community.

I expect that Oracle will continue to have membership of our JSR and hope that they will continue to engage in our deliberations, and I encourage IBM and BEA to become more involved as well.

Kind regards, Robin.

  Message #120723 Post reply Post reply Post reply Go to top Go to top Go to top

Let's not mess up this one!

Posted by: Yagiz Erkan on May 05, 2004 in response to Message #120524
Hi all,

We've used EJBs (even BMPs few years ago :-) for some time in different big projects (using WebLogic, WebSphere and Oracle9iAS). I'm glad that the spec and the implementations are getting better. However it's still too complex/heavy weight/not intuitive/etc. Furthermore, we have many more small "Web Application" projects deployed mostly on Tomcat not using EJBs at all. From now on, starting with the small projects, we're thinking about using Hibernate. (We're researching about Spring framework as well because we're fed up with working with heavy-weight containers in our development environments. We don't have to have coffee breaks because we're deploying!).

Obviously we're not the only ones in this situation. And I find it more than arrogant that BEA, IBM and Oracle don't want to support JDO. The users/developers have kept crucifying Entity EJBs and heavy-weight containers but they don't want to get it, do they? We had enough! We want to use something that we can develop with simple tools, that we can unit test easily and where we can deploy fast. JDO 2.0 is a part of the solution to a bigger problem and I'm looking forward to it!

We, the users/developers, drive the industry! Listen to us! Or you're doomed!

 - Yagiz -

PS: Oracle makes me laugh! I thought they were promising JDO support for TopLink!
PPS: IBM makes me laugh! As if they cared about overlapping: Have you heard about SWT?
PPPS: I'm disappointed with BEA because WebLogic is the only product that stands as the only source of hope in me concerning the J2EE Application Servers.

  Message #120724 Post reply Post reply Post reply Go to top Go to top Go to top

jdo spec

Posted by: hichem hassania on May 05, 2004 in response to Message #120663
it's nice to see all of this YES votes, i hope that the java community will benifit from both JDO and other persistance models without "big overlaps"

  Message #120727 Post reply Post reply Post reply Go to top Go to top Go to top

Question for Robin

Posted by: rory Winston on May 05, 2004 in response to Message #120722
The JDO 2.0 JSR was approved despite their objections
OK - do you think that there will be a list of specific concerns forthcoming from any of the three vendors (or their representatives) any time soon?

  Message #120730 Post reply Post reply Post reply Go to top Go to top Go to top

Question for Robin

Posted by: Robin Roos on May 05, 2004 in response to Message #120727
Do you think that there will be a list of specific concerns forthcoming from any of the three vendors (or their representatives) any time soon?
No, it would strike me as unlikely.

What follows in this next paragraph is speculation on my part, and I am alerting you to this for fear that I am accused of spreading FUD in response to the FUD that has historically targeted JDO...

<FUD?>It is possible that these three "no" votes are a last-ditch attempt by the big players to reassert the "need" for EJB-based persistence in the face of the combined threat from the "transparent persistence" camp (JDO & Hibernate) and the "lightweight container" camp (Spring & Pico & other AOP environments).</FUD?>

In my view the correct approach from the EJB people would be to embrace these threats. I'd love to hear Rod Johnson's opinion, but if EJB 3.0 made Entity Beans optional might Spring evolve to be EJB spec compliant? The current JSR-220 plans - to simplify EJB with extensive use of JSR-175 metadata - would certainly help EJB to compete in the "lightweight" game. Meanwhile, continued advocation of Entity Bean persistence as the solution for the enterprise flies in the face of the community. Persistence that requires the application to be designed specifically for, and locked into, a particular container type (J2EE) is not helpful in a world which demands more and more flexibility from its IT solutions. The object pooling motivations have been largely swept aside by JDK 1.4.2's improvements in object instantiation, and many of the other pro-Entity Bean arguments have long since been refuted by the community.

IBM, Oracle and BEA have sent a message to the community, the essence of which is that we should not be using or pursuing JDO. Their statements do not directly mention Hibernate. I think the community should send back a very clear message that transparent persistence which interoperates with but does not require Web/EJB containers is what we want.

One thing I do know for certain: I cannot win this battle on my own.

Thanks, Robin.

  Message #120732 Post reply Post reply Post reply Go to top Go to top Go to top

Model and technology are orthogonal

Posted by: Andy Grove on May 05, 2004 in response to Message #120587
The technology used to persist objects should be *pluggable*. I should be able to use Hibernate or JDO or anything I want to. The more you try to design a spec to be able to do this, the more you see that the EJB *contract* is the right one.
Surely this is why we have the Data Access Object (DAO) design pattern is part of Sun's J2EE Blueprints. By using a well-understood DAO tier you get abstraction from the persistence technology (JDBC, Entity Beans, JDO, Hibernate, and so on) and you can use the DAO classes in J2EE applications *and* from J2SE applications.

There are even a bunch of products (commercial and open source) out there to generate DAO code for you.

FireStorm/DAO is one example that already supports JDBC, Entity Beans, and JDO behind a common DAO interface. Hibernate support will be available in the next release.

Cheers,

Andy Grove
Code Futures, Ltd

  Message #120735 Post reply Post reply Post reply Go to top Go to top Go to top

Model and technology are orthogonal

Posted by: Robin Roos on May 05, 2004 in response to Message #120732
Hi Andy
By using a well-understood DAO tier you get abstraction from the persistence technology (JDBC, Entity Beans, JDO, Hibernate, and so on) and you can use the DAO classes in J2EE applications *and* from J2SE applications.
The problem comes with the variance in granularity and applicable abstraction layers of different persistence technologies.

The "traditional" DAO pattern requires that you get a DAO object from a factory that has been configured for your particular target datastore; that you use the DAO manage (create/save/delete) persistent objects. The DAOs for different underlying persistence mechanisms all implement the same interface, giving you portability over (and abstraction from) the various supported datastores. So far so good.

But in practice this often breaks down. With the transparent persistence implementations you obtain a persistent object, alter it within a transaction (perhaps adding transient instances into the graph) and finally commit your transaction. There is no save() invocation. On commit, the persistence layer knows (e.g. JDO) or determines (e.g. Hibernate) which objects have changed and synchronises these changes to the datastore, usually by emitting minimalist SQL and not writing back unaltered fields. Additionally the persistence-by-reachability algorithm (JDO) or equivalent (Hibernate) kicks in, identifies all reachable transient instances of classes capable of persistence, inserts these into the datastore and configures the relationships accordingly. All just on commit().

It is not possible to create a DAO interface which retains the development productivity of the transparent persistence approach whilst maintaining support for traditional stores. The temptation is to require an explicit save() or create() invocation for all instances of the graph which is not acceptable to the "transparent persistence" community.

Of course, what you could do is write a DAO which facilitates usage of JDO or Hibernate. I suggest that in this case the DAO interface should be javax.jdo.PersistenceManager, which is exactly how Hibernate is expected to achieve their compliance.

Another thing you can do is implement a PersistenceManager whose back-end datastore is EJB Entity Beans. This would feel a little weird, but JDO is deliberately datastore agnostic so it should be feasible. Now it becomes that particular PersistenceManager implementation's responsibility to navigate the committed object graph and issue individual invocations on an underlying graph of Entity Beans, in a similar way to the emission of SQL to an underlying relational database by the present tranche of JDO implementations.

That said, I have not had time to look at your company's product. Feel free to point out the shortcomings of my posting. Until then PersistenceManager is the DAO interface.

Kind regards, Robin.

  Message #120736 Post reply Post reply Post reply Go to top Go to top Go to top

Model and technology are orthogonal

Posted by: Robin Roos on May 05, 2004 in response to Message #120732
The following quote from the FireStorm/DAO website neatly illustrates the problem:
A typical DAO interface is shown below.

public interface CustomerDAO
{
  public void insert(Customer customer)
   throws CustomerDAOException;

  public void update(CustomerPK pk, Customer customer)
   throws CustomerDAOException;

  public void delete(CustomerPK pk)
   throws CustomerDAOException;

  public Customer[] findAll()
   throws CustomerDAOException;

  public Customer findByPrimaryKey(String email)
   throws CustomerDAOException;

  public Customer[] findByCompany(int companyId)
   throws CustomerDAOException;
}
To benefit from the portability promised by this approach I must religiously invoke the services of the DAO, programmatically insert()-ing and update()-ing records even though I know that JDO/Hibernate would do this for me transparently. Simplistic DAO-based approaches cannot realize the productivity gains of the transparent persistence movement.

PersistenceManager is the DAO interface (Am I in danger of getting religious?)

  Message #120737 Post reply Post reply Post reply Go to top Go to top Go to top

Model and technology are orthogonal

Posted by: Andy Grove on May 05, 2004 in response to Message #120736
Of course, what you could do is write a DAO which facilitates usage of JDO or Hibernate. I suggest that in this case the DAO interface should be javax.jdo.PersistenceManager, which is exactly how Hibernate is expected to achieve their compliance.
Perfectly valid approach but the whole point of using the DAO interface is to abstract from the underlying persistence technology. Your suggestion is to tie it into the JDO API.
PersistenceManager is the DAO interface (Am I in danger of getting religious?)
Yes, but that's fine. There are many perfectly valid approaches to persistence and there is no "correct" solution (although arguably there are a few "wrong" ones!)

If JDO fills your needs and you never want to move away from that API that's fine. If you want abstraction with the ability to plug-and-play with the persistence technology then DAO is ideal. One size doesn't necessarily have to fit all.

  Message #120739 Post reply Post reply Post reply Go to top Go to top Go to top

Model and technology are orthogonal

Posted by: Robin Roos on May 05, 2004 in response to Message #120737
One size doesn't necessarily have to fit all.
Great, so we can "live and let live"!

  Message #120743 Post reply Post reply Post reply Go to top Go to top Go to top

JDO for Standalone & CMP for EJBs

Posted by: ramesh loganathan on May 05, 2004 in response to Message #120683
Hi Ramesh
in an EJB context, for biz apps, there is very little value that JDO offers. The often cited Polymorphism and Testability- are they of much use? In a biz app, how often would one want to inherit a "DB class"?
Well thats probably because domain models built for entity beans have to be simple. You cannot use the full range of OO design techniques that are available with JDO. Limited, EJB style models work for PetStore type apps. Real world business apps benefit from JDO.CheersDavidwww.jdogenie.com
Surely there is a class where OO can be applied even for DB classes. My point was that in biz apps is it such a pressing need? As I mentioned, Object Dtabases never gained mainstream acceptance. Probably due to unproven reliability. But even the reliable mainstream DBMS vendors (IBM & Informix) when they extended the DBMS onto ORDBMS , the OR part never got accepted in the market.

Again, one could argue that unless the whole applciation design is OO, the OO aspect of DB cannot be used. But even in pre Java days, C++, PowerBuilder & Delphi were quite rampantly used for Biz apps. where again, not much traction for ORDBMS.

Even in this thread, if you look at the USPs cited for JDO, lot of them apply for non EJB environments. IN EJB, dont believe JDO offers much value when compared to CMP. Even the oft repeated 'complexity' in CMP is weak, as the dev mechanics are not too different between CMP and JDO. By no means a no-brainer decision that CMP is bad and JDO is good.

[ps: even as a J2EE vendor, we support JDO. JDO does offer a good portable platform for non EJB environments. But we also believe that there cannot be an identical persistence framework for both non EJB and EJB environments. EJB environments can benifit from some EJb specific semantics such as declarative Security and Transaction model- that CMP does leverage]

Cheers,
Ramesh
http://www.pramati.com

  Message #120747 Post reply Post reply Post reply Go to top Go to top Go to top

JDO for Standalone & CMP for EJBs

Posted by: Robin Roos on May 05, 2004 in response to Message #120743
For the avoidance of doubt, JDO does leverage Container Managed Transactions (CMT) and this is not "optional".

The niche uptake of ODBMS can be attributed to the lack of meaningful standards in the area, overly complex and incompletely implemented standards (ODMG), and the widespread adoption of SQL. Coincidentally, now that JDO exists it is "safe" to experiment with ODBMS technology since all your application investment is preserved should you go back to the relational world.

But my position is not to back ODBMS. I want to see Java developers supported (by the J2EE stakeholders) in their adoption of transparent object persistence, regardless of the back-end datastore to which their manipulations and persistence objects are mapped.

  Message #120749 Post reply Post reply Post reply Go to top Go to top Go to top

SDO, not redundant

Posted by: l p on May 05, 2004 in response to Message #120694
It might help if you read the SDO docs before writing they are redundant...

Disconnected data sets are useful in various contexts, not only in the JDO context. Bea and IBM engineers were smart enough to realize this and came up with a simple yet powerful abstraction. And I see no special reason JDO disconnected datasets could not conform to this SDO spec.

SDO (and a client side version of it: JavaScript SDO, for client side data models) is already being used in IBM products right now. Of course both companies are trying to control technology, but I would rather have them doing it this way (coming up with something that actually _works_) than through the normal (read: much too slow) proces.

Cheers, Luc.

  Message #120756 Post reply Post reply Post reply Go to top Go to top Go to top

Both have merits

Posted by: peter lin on May 05, 2004 in response to Message #120544
What about polymorphism? What about dynamic queries? What about testability? What about in-and-out of container operation? What about, dare I say it, transparency? And without the ability to encapsulate data, can entity beans ever be more than mere data structures? In its current incarnation the concept of a "behaviourally complete" object model built with entity beans is utterly laughable.So where is the Entity Bean value-add?
How many years have developers been griping about distributed transactions/objects. If only management types and CTO's didn't jump on buzz words and did what makes sense; I don't think EJB's and entity beans would have such a bad rap. Most applications simply don't need it. But when you really need distributed objects, because your application handles numerous concurrent sessions with shared data, a JDO model won't cut it. Of course, the easy solution is to not provide those types of features in your application and use a reasonable poll mechanism. Sure there's a greater lag, but if the lag is acceptable, a simpler JDO based approach is better. I don't know about others, but managing distributed objects with polymorphism is harder than one would think. How would a server determine which database table to save to? If object C extends B, which extends A. How is the EJB suppose to manage persistence. It's hard enough managing distributed objects in a persistent manner that adding polymorphism would be asking for trouble. I don't think there will ever be a clear answer for extending EJB to support polymorphism. But I'm not expert and most likely wrong. I agree completely that EJB spec could be simpler and easier to use, but my take is each one is driven by different requirements.

  Message #120762 Post reply Post reply Post reply Go to top Go to top Go to top

Model and technology are orthogonal

Posted by: Philip Murray on May 05, 2004 in response to Message #120587
The technology used to persist objects should be *pluggable*. I should be able to use Hibernate or JDO or anything I want to. The more you try to design a spec to be able to do this, the more you see that the EJB *contract* is the right one.
Completely agree. Hibernate, JDO, JDBC, CMP EJB, whatever DAO is the best fit.
The more you try to design a spec to be able to do this, the more you see that the EJB *contract* is the right one.
See above... EJB is just one option - sometimes the best.

  Message #120763 Post reply Post reply Post reply Go to top Go to top Go to top

Oracle showed .NET Petstore wasn't that fast

Posted by: peter lin on May 05, 2004 in response to Message #120690
<vic>iBatis of course, better than Hibrenate.</vic>sorry Vic but did you read the result of the latest case study of .NET vs. J2EE? TSS had 2 types of J2EE applications:- J2EE + Servlet/JSP + EJB CMP and- J2EE + Servlet/JSP only (it used JPetstore implementation)All the results showed that only J2EE + Servlet/JSP + EJB CMP had a chance to fight against the power of .NET. JPetstore was very slow to compare with two other implementations in that test. It would be very interesting to see JDO impl. and Hibernate in the same test...Cheers,Lofi.
Test results are very dependant on tester and I am sure this test is lame or political. Probably JPetstore is not the fastedapplication in the world and I do not think somebody have tried to tune it, single thing you need to tune is a RDBMS (add more cache and create indexes). I am afraid it is not so trivial to tune EJB (How do you trace query plan in EBQL ?).
I don't have the link handy, but Oracle duplicated the test with optimization while staying true to n-tier. It was faster when the data was cached and not cached. Google for the article and you'll see the .NET Petstore threw design principles out the door to show it was faster. Oracle's test shows you can get great performance while using good design practices.

  Message #120764 Post reply Post reply Post reply Go to top Go to top Go to top

Both have merits

Posted by: Robin Roos on May 05, 2004 in response to Message #120756
Hi Peter
But when you really need distributed objects, because your application handles numerous concurrent sessions with shared data, a JDO model won't cut it.
I will take issue with the above statement shortly (in an entirely friendly way). First of all I wanted to clarify your meaning when you refer to "distributed objects".

(a) I have data as objects on one machine which I want to access remotely in the RMI sense
(b) I have two different JVMs (logical tiers) which simultaneously require access to the same persistent data as objects
(c) Both of the above
(d) Something different

Thanks, Robin.

  Message #120765 Post reply Post reply Post reply Go to top Go to top Go to top

What to do with EJB 3.0

Posted by: Matthew Adams on May 05, 2004 in response to Message #120594
I think it is about time we called it at day with Entity Beans and let JDO become the spec for defining how to persist your model in J2EE.
+1. Deprecate entity beans in EJB 3.0 and move all types of persistence to JDO 2.0.
And make Hibernate JDO 2.0 compatible.Best,Igor.
The changes introduced in the JDO 2.0 spec include a relaxation of the binary compatibility requirement (the implementation of the javax.jdo.spi.PersistenceCapable interface), so Hibernate (and Toplink) could fairly quickly become JDO 2.0 compliant.

--matthew

  Message #120768 Post reply Post reply Post reply Go to top Go to top Go to top

But when you really need distributed objects

Posted by: Mileta Cekovic on May 05, 2004 in response to Message #120756
>> But when you really need distributed objects

You do not need distributed objects in the form of distributed entities. This is at least 1000 times shown to be bad design as remote method call is at least 1000 times slower then local in-process call.

When designing distributed systems you need distributed components or services (call it as you want) that are more coarse grained then entities.

You design interfaces of these components/services not to be object-oriented but service-oriented (because of performance). Internaly, these components/services should be object-oriented and could even have dual interface (SO and OO) for using them localy.

Mileta

  Message #120782 Post reply Post reply Post reply Go to top Go to top Go to top

Consider vendors' motivations

Posted by: Matthew Adams on May 05, 2004 in response to Message #120524
Consider this:
* IBM & BEA each sell an EJB container.
* IBM & BEA have invested significantly in entity bean support.
* IBM & Oracle each sell a relational database.
* Oracle sells an object persistence tool.

Given that JDO
* not only integrates with an EJB container but also can be used outside of one,
* supports different database vendors, and
* supports multiple implementations over the same or a different data store,
it becomes quite clear that the vendors, in their no votes, are simply trying to protect their investements. They are beset on many fronts by the threat of commoditization and innovation.

IBM's & BEA's investments in entity bean support are directly threatened by JDO, and their containers are threatened by the undercurrent of lightweight, containerless frameworks like Pico & Spring, with which JDO can be used. IBM's and Oracle's databases are threatened by JDO's encapsulation of the underlying database. Oracle's TOPLink is threatened because it would lose its customer lock-in and possibly be replaced by another persistence implementation.

I'm surprised by BEA's comment about object databases. I think anyone who's done any research on JDO knows that there are far more O-R mapping implementations used than any other kind, and there are more O-R mapping implementations than there are object database implementations.

What I does not surprise me is that the vendors are attempting to protect themselves, something for which I don't blame them. However, they exist only thanks to their customers, and their customers have a long and well-documented history of disliking the entity bean solution. They need to listen to their customers and recognize that there are better solutions out there. By the same token, their customers need to speak up and demand a better solution, JDO or not.

With JDO 2.0, every concern that I've heard about the specification has been addressed (object graph detachment & reattachment, optional bytecode enhancement, enhanced query capabilities, access to underlying database connection, etc), and products like TOPLink and Hibernate can be compliant much more easily than they could have with JDO 1.x. It's time for the vendors and the EJB specification committee to step up, admit that they fused the object and component models, acknowledge the widespread criticism and lack of use of entity beans, recognize a simpler solution, and embrace it by deprecating entity beans in EJB 3.0 in favor of JDO 2.0.

I would also like to see Hibernate and TOPLink implement JDO 2.0, unless their fear of commoditization outweighs their perceived ability to capture market share. That's a call that they're going to have to make.

Additionlly, let's not forget that Microsoft is watching. They have a similar technology called ObjectSpaces, based on ADO.NET 2.0, that is currently under development. Their first technology previews in 2001 looked an awful lot like entity beans, and their more recent previews look a lot more like JDO.

--matthew

  Message #120784 Post reply Post reply Post reply Go to top Go to top Go to top

SDO, not redundant

Posted by: Roland Barcia on May 05, 2004 in response to Message #120749
Right, SDO goes beyond OR/Mapping. SDO may very well be the mechanism to hide all these persistent layers from the presentation. SDO is more an implementation of the Active Record Pattern while JDO, Entity Beans, Hibernate follow more of a Domain Model. SDO can be used as Value Objects to an from these layers, they can be used as a data delegate, and they can be used to front legacy data, XML, etc...

SDO may have some function overlap but its goal are totally different.

  Message #120787 Post reply Post reply Post reply Go to top Go to top Go to top

Oracle showed .NET Petstore wasn't that fast

Posted by: Juozas Baliuka on May 05, 2004 in response to Message #120763
Yes, fake oracle performance tests are nothing new (aggressive marketing).
MySQL proved itself as the best database this way too, Do you think mySQL is "fater" than oracle ? Try to cache content on web server and iBatis will be the fasted framework (It will have nothing to do), Does it meens IBatis is the best technology in the world ?
<vic>iBatis of course, better than Hibrenate.</vic>sorry Vic but did you read the result of the latest case study of .NET vs. J2EE? TSS had 2 types of J2EE applications:- J2EE + Servlet/JSP + EJB CMP and- J2EE + Servlet/JSP only (it used JPetstore implementation)All the results showed that only J2EE + Servlet/JSP + EJB CMP had a chance to fight against the power of .NET. JPetstore was very slow to compare with two other implementations in that test. It would be very interesting to see JDO impl. and Hibernate in the same test...Cheers,Lofi.
Test results are very dependant on tester and I am sure this test is lame or political. Probably JPetstore is not the fastedapplication in the world and I do not think somebody have tried to tune it, single thing you need to tune is a RDBMS (add more cache and create indexes). I am afraid it is not so trivial to tune EJB (How do you trace query plan in EBQL ?).
I don't have the link handy, but Oracle duplicated the test with optimization while staying true to n-tier. It was faster when the data was cached and not cached. Google for the article and you'll see the .NET Petstore threw design principles out the door to show it was faster. Oracle's test shows you can get great performance while using good design practices.
  Message #120796 Post reply Post reply Post reply Go to top Go to top Go to top

DAO design pattern isn't

Posted by: Jochen Bedersdorfer on May 05, 2004 in response to Message #120732
I've been through all these things a long time ago.

First we used Versant OODBMS. Easy to use, even for unexperienced programmers,
but locks you in.

Then I designed a little sub-project using the DAO design pattern to make
it independent from the persistence technology. WHAT A WASTE OF TIME!
You are writing class after class just plumbing things together, after that
your business code looks like a one big mess.

In annother project we used CMP. Holy moses, why do I have to seperate my business logic/application logic when the only logical place is in the damn CMP beans?
All this nonsense about putting your logic in statless session beans, opening up
your persistent beans with numerous public setters/getters is breaking
all rules about a clean, encapsulated and simply OO design!
Every public method you have is one your developers will screw around with.

Then I tried JDO and the world was fine again! I could reduce the number of
public methods significantly, putting all user-editable data in more or less
generic DTO-objects, leaving the business logic right in the classes I would
use for persistence, reducing the lines of code significantly.
Now our sessions beans rarely do more than getting a persistent object by
Id and calling a business method right inside there and it is working
wonderfully.
Changes to the system are wonderfully localized (no traveling through n tiers
just to add an attribute to a class) and performance is good.

  Message #120810 Post reply Post reply Post reply Go to top Go to top Go to top

why 4 ejb vendors?

Posted by: Amin Mansuri on May 05, 2004 in response to Message #120524
Why are 4 EJB vendors (Sun, IBM, Oracle, BEA) the majority in a committee deciding a competing technology?

Hardly seems like a fair process for innovation.

  Message #120813 Post reply Post reply Post reply Go to top Go to top Go to top

why 4 ejb vendors?

Posted by: Robin Roos on May 05, 2004 in response to Message #120810
I don't think the four you mention form a majority. The executive committee is comprised of 16 well respected organizations and individuals, and I belive the votes held by each to be of equal weighting.

  Message #120818 Post reply Post reply Post reply Go to top Go to top Go to top

why 4 ejb vendors?

Posted by: Robin Roos on May 05, 2004 in response to Message #120813
I've just written a brief comparison between SDO and JDO 2.0 Detachment which I hope to publish tomorrow. I'll be sure to link to it from this thread for those who are interested.

Whilst I was writing it I suddenly understood Amin's question! There are 16 organizations and individuals in the executive committee, but Dion only listed at the top of this thread the five who submitted a comment along with their vote. JSR-243 (JDO 2.0) was approved for further development by a majority of 12-to-3 with 1 abstension, but only 5 companies posted specific comments.

  Message #120827 Post reply Post reply Post reply Go to top Go to top Go to top

No surprise that EJB vendors don't like JDO

Posted by: Jerome Beau on May 05, 2004 in response to Message #120574
Agreed. EJB definitely need a good an object-oriented persistence service, and JDO is a good object-oriented persistence framework. Simplifying J2EE is certainly not about building EJB as an all-needs API, but rather make J2EE federate all specialized Java API (JTA/JTS transactions, RMI distributions, JAAS security and JDO persistence) instead of re-inventing them. Everybody can see that CMP 2 and 3 are going more and more closely toward JDO principles. JDO surely can fit well as a CMP service (like JTS underlies JTA for instance) given some minor adaptations in one specification or another. Furthermore, it would make CMP even more transparent, simple, efficient and usable. Once again, keep in mind that EJB is a component framework. It needs a persistence service, but is not a persistence framework (more about this on http://www.theserverside.com/discussions/thread.tss?thread_id=18546).

  Message #120830 Post reply Post reply Post reply Go to top Go to top Go to top

Interpretation of what each vendor is saying

Posted by: Seong-yong Kim on May 05, 2004 in response to Message #120524
Sun: We have no choice to support JDO effort because EJB really sucks big time in performance, and we know it.

Macromedia: We like options. The more standard options the developers have the more likely they will consider to use less dominant servers like "JRun".

BEA: Our livelihood is depends on our popular EJB Container. JDO will only take our customers away.

IBM: We can hardly (actually have not) keep up with the latest J2EE spec. Maybe later.

Oracle: JDO promote Object Databases. What are you crazy? We don't do Object Database.


Seong-yong

  Message #120842 Post reply Post reply Post reply Go to top Go to top Go to top

JSR 220

Posted by: G Hermitage on May 05, 2004 in response to Message #120730
I don't see anything in JSR 220 that amounts to transparent persistence. Has this talk of transparent persistence for EJB 3 arisen since its JSR was filed?


<quote>
One thing I do know for certain: I cannot win this battle on my own.
</quote>

This is a fine rallying call. We will be naming you Robin Braveheart Roos.

  Message #120852 Post reply Post reply Post reply Go to top Go to top Go to top

Transparent Persistence not in EJB?

Posted by: ramesh loganathan on May 05, 2004 in response to Message #120842
I don't see anything in JSR 220 that amounts to transparent persistence. Has this talk of transparent persistence for EJB 3 arisen since its JSR was filed
Need for (or the current lack of) Transparent Persistence in EJB has been repeated several times on this thread. This is kind of wierd. Why does EJB need any more Transparent Persistence? Entity Beans offer just that. Even if it comes with additional functionality of distributed objects- which also can be avoided by using local interfaces.

Cheers,
Ramesh

  Message #120853 Post reply Post reply Post reply Go to top Go to top Go to top

Transparent Persistence

Posted by: G Hermitage on May 06, 2004 in response to Message #120852
Why does EJB need any more Transparent Persistence? Entity Beans offer just that.
If you clearly state what you think transparent persistence is we can help you sort out your misunderstanding.

  Message #120870 Post reply Post reply Post reply Go to top Go to top Go to top

Transparent Persistence not in EJB?

Posted by: rory Winston on May 06, 2004 in response to Message #120852
I don't see anything in JSR 220 that amounts to transparent persistence. Has this talk of transparent persistence for EJB 3 arisen since its JSR was filed
Need for (or the current lack of) Transparent Persistence in EJB has been repeated several times on this thread. This is kind of wierd. Why does EJB need any more Transparent Persistence? Entity Beans offer just that. Even if it comes with additional functionality of distributed objects- which also can be avoided by using local interfaces. Cheers,Ramesh
Ramesh, I don't know if you've ever used a framework that offers true transparent persistence, but if you did, you would realise the vast difference between that kind of persistence and the EJB-based approach. Transparent persistence doesn't make sense until you actually make use of it, and then you "get it". Once you reach that point, you never want to go back. I wasn't that excited about JDO 1.0, and Hibernate has been my framework of choice for a long time. However, if you look at the plans for JDO 2.0, the EG has put in place the foundations for an amazing framework. To have Hibernate-style functionality in place as part of the J2SE, and (if Hibernate evolves a JDO 2.0 interface) to be able to continue to use Hibernate under the covers is IMHO, one of the most exciting proposals in a long time. Of course, we will still need to see what JSR 220 will bring, but I for one, can't see where they greatly overlap. JSR 220, despite the proposed addition of metadata-driven persistence, still seems to be "container-oriented". Still, we will see.

  Message #120873 Post reply Post reply Post reply Go to top Go to top Go to top

Transparent Persistence

Posted by: ramesh loganathan on May 06, 2004 in response to Message #120853
Why does EJB need any more Transparent Persistence? Entity Beans offer just that.
If you clearly state what you think transparent persistence is we can help you sort out your misunderstanding.
One definition I have come across often (and intuitive also)- "Transparent persistence is the storage and retrieval of persistent data with little or no work from the developer."
Dont believe there is any misunderstanding. CMP beans does offer transparent persistence. Much like JDO or Hibernate (even if it may differ in its details):
- There is a basic java class that offers the object abstraction
- The persistence is declaratively specified in XMLs
- APIs are available to create new instances or load existing instances
- Persistence is transparently managed by the runtime (Persistence
  framework or the Container)

Talk about simplifying the abstractions and usage, probably makes sense (even if not a whole lot, when talkingabout an EJB application). But surely not correct to state that there is Transparent Persistence in CMP.

Cheers,
Ramesh

  Message #120875 Post reply Post reply Post reply Go to top Go to top Go to top

Transparent Persistence

Posted by: ramesh loganathan on May 06, 2004 in response to Message #120873
But surely not correct to state that there is Transparent Persistence in CMP.
Oops. I meant to say "But surely not correct to state that there is *NO* Transparent Persistence in CMP."

  Message #120880 Post reply Post reply Post reply Go to top Go to top Go to top

Transparent Persistence not in EJB?

Posted by: Michal Maczka on May 06, 2004 in response to Message #120870
Ramesh, I don't know if you've ever used a framework that offers true transparent persistence, but if you did, you would realise the vast difference between that kind of persistence and the EJB-based approach.

Transparent persistence means in simple words: you create an instance of bean/object, you change its properties and those changes are transparently propagated to the database (or to some other storage). In fact transparent persistence in EJBs( I am not a fan of them) is taken to higher level then it takes places in JDO or/and in frameworks like OJB or Hibernate. And this is paradoxically probably one of the major problems of EJBs.
As they went so far with "transparency" and are not even supporting dynamic queries as implementation of finders is provided by container. You can very easily as well build fully transparent persistence on top of JDO implementations with AOP. EJBs attempt in fact to the same thing but it only gives you this "transparent" way of dealing with databases. With EJB you cannot easly decent one level down and have a choice if you want "transparency" or not ( please forget about BMP 1.x as they were one big mistake).

So Ramesh is 100% right.
To have Hibernate-style functionality in place as part of the J2SE, and (if Hibernate evolves a JDO 2.0 interface) to be able to continue to use Hibernate under the covers is IMHO, one of the most exciting proposals in a long time. Of course, we will still need to see what JSR 220 will bring, but I for one, can't see where they greatly overlap. JSR 220, despite the proposed addition of metadata-driven persistence, still seems to be "container-oriented". Still, we will see.
Well the overlapping is a plain to see (at least accordingly to Mr. Fleury):

http://jboss.org/jbossBlog/blog/mfleury/?permalink=Transparent+middleware%2C+EJB3.0%2C+Las+Vegas+TSS.html

"But until that day, the day where you all walk through walls, let's make sure you don't bang your head on the walls for simple stuff. EJB3.0, of which JBoss is a contributing expert member, greatly simplifies the programming model. To lay rumors, yes both Gavin King and myself are on the committee. We are working on lightweight persistence (POJO persistence) and simplified programming models. EJB3.0 will be big, it will be surrounded by buzz by the javaone timeframe and it will be good."
 


Michal

  Message #120881 Post reply Post reply Post reply Go to top Go to top Go to top

Transparent Persistence not in EJB?

Posted by: Michal Maczka on May 06, 2004 in response to Message #120880
Upss! sorry!!
the first paragraph in my previous post was a citation:Ramesh, I don't know if you've ever used a framework that offers true transparent persistence, but if you did, you would realise the vast difference between that kind of persistence and the EJB-based approach.Michal

  Message #120882 Post reply Post reply Post reply Go to top Go to top Go to top

Transparent Persistence

Posted by: G Hermitage on May 06, 2004 in response to Message #120873
Why does EJB need any more Transparent Persistence? Entity Beans offer just that.
If you clearly state what you think transparent persistence is we can help you sort out your misunderstanding.
Dont believe there is any misunderstanding. CMP beans does offer transparent persistence. Much like JDO or Hibernate (even if it may differ in its details)
So you are actually taking the position that EJB 2.1 CMP Entity Beans are transparently persistent? For openers, can you see that the methods that the container requires at EJB 2.1 for entity beans are entirely contrary to transparent persistence? Can you identify a similar non-transparency in JDO or Hibernate?

  Message #120883 Post reply Post reply Post reply Go to top Go to top<