667514 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: 218 Messages: 218 Messages: 218 Printer friendly Printer friendly Printer friendly Post reply Post reply Post reply XML XML XML

Sun creates new Persistence API: EJB & JDO join forces

Posted by: Dion Almaer on September 24, 2004 DIGG
An open letter from Sun, to the community, has been released. The letter talks about how a new specification, RI, and TCK will be placed under the JSR-220 (EJB 3) group. JDO experts will join this effort, which will be based on the EJB 3 early draft as a starter.

Sun is hoping that the entire community can get behind the goal of ONE persitence API for J2SE and J2EE.

They are encouraging us to read through all of the material to understand what is going to happen to the future of persistence in Java.

Open Letter
A Letter to the Java Technology Community

For years, the Enterprise JavaBeans(tm) (EJB(tm)) and Java(tm) Data Objects (JDO) specifications have evolved independently as they addressed different sets of requirements. The core of both specifications, however, includes persistence technology. Even to this day, the data persistence models in EJB and JDO differ significantly. This divergence has caused confusion and debates among Java developers, and is not in the best interest of the Java community. Consequently, requests to put an end to this unwanted divide have poured in from members of the Java community. In response to these requests, Sun Microsystems is leading a community effort to create a single POJO (Plain Old Java Object) persistence model for the Java community. This effort will strengthen community solidarity.

Starting this reconciliation effort now is very timely given that both the EJB and JDO specifications are going through significant revisions. As specification leads for EJB 3.0 (JSR-220) and JDO 2.0 (JSR-243), we have jointly created the following plan to move this community effort forward:

  • This is a community effort. We are expanding the JSR-220 Expert Group to include some members from the JSR-243 Expert Group. By joining forces, we will bridge the two communities and leverage the know-how in both groups. The current JSR-220 specification lead will remain unchanged.
  • The work to define a single POJO persistence model for the Java community will be done under JSR-220 starting from the existing JSR-220 Early Draft.
  • The technical objective for this new POJO persistence model is to provide a single object/relational mapping facility for all Java application developers that works in both J2SE and J2EE. The work will be done within the J2EE 5.0 time frame.
  • The new POJO persistence model will be delivered by JSR-220 as a separate specification, Reference Implementation, and Technology Compatibility Kit, usable independently of EJB 3.0.
  • As currently planned, the scope of JSR-243 will include maintenance to JDO 1.0.1 and enhancements to JDOQL. Additionally, the JDO expert group will aim to deliver JDOQL that would work with the new POJO persistence model so those with a preference for JDO query style can leverage the new common persistence API. The current JSR-243 specification lead will remain unchanged.
We believe this is a unique opportunity for the Java community to create a common POJO persistence model for both J2SE and J2EE. Some of the industry's best minds will be collaborating to agree upon this standard. By incorporating best-of-breed design concepts, this common POJO persistence model will further strengthen the Java platform.

We are asking the entire Java technology community to support us and the efforts of the JSR-220 Expert Group. We'd like to encourage everyone to contribute to the direction of this persistence work by reviewing the specification drafts and sending us your feedback. Your input is crucial to the continued success of the Java platform.

Sincerely,

Linda DeMichiel and Craig Russell
Specification Leads, JSR-220 and JSR-243
Read the open letter

Read the FAQ (coming soon!)

We are all joining forces to try to create the dream of a POJO persistence model that works within, or without a J2EE container.

TheServerSide asked Patrick Linskey of SolarMetric (a leading JDO vendor, with Kodo) what he thought of the news:
"This is a good opportunity for the Java community. By building a team that is comprised of people from both the EJB and JDO expert groups, Sun has established a new body that will drive collaboration and friendly competition between the two specifications. This will provide a number of persistence options that will meet the needs of the community while also ensuring compatibility among the choices. As members of both JSRs (220 and 243), SolarMetric will provide support for both the JDO framework and this new specification in the Kodo product suite."
Be Heard. Get Involved

The devil is always in the details, but I really hope that people get behind the new group. As always, the best way to help is to get involved in the JCP process and give feedback!

What do you want to see in this new API? What features matter to you... and do you think should be standardized?

Threaded replies

·  Sun creates new Persistence API: EJB & JDO join forces by Dion Almaer on Fri Sep 24 18:33:24 EDT 2004
  ·  Sun creates new Persistence API: EJB & JDO join forces by Konstantin Ignatyev on Mon Sep 27 10:53:22 EDT 2004
    ·  Why ONE? by Dion Almaer on Mon Sep 27 11:13:57 EDT 2004
      ·  Why ONE? by Konstantin Ignatyev on Mon Sep 27 11:53:18 EDT 2004
      ·  Non-relationa data stores? by Tom Kehrwald on Wed Sep 29 12:36:49 EDT 2004
        ·  Non-relationa data stores? by Emmanuel Bernard on Wed Sep 29 15:03:59 EDT 2004
        ·  Non-relational data stores? by Craig Russell on Thu Sep 30 03:18:13 EDT 2004
          ·  Non-relational data stores? by Erik Bengtson on Thu Sep 30 03:49:00 EDT 2004
            ·  Non-relational data stores? by Craig Russell on Thu Sep 30 05:32:40 EDT 2004
              ·  Non-relational data stores? by Erik Bengtson on Thu Sep 30 06:28:35 EDT 2004
          ·  Too late I think. by Martin Dolog on Thu Sep 30 04:04:37 EDT 2004
          ·  Non-relational data stores? by Juozas Baliuka on Thu Sep 30 13:23:10 EDT 2004
    ·  Entity Beans in EJB3??? by srikanth koppisetty on Mon Sep 27 12:15:17 EDT 2004
    ·  Names are relativ, but which concepts well be supported by Matthias Kaiser on Mon Sep 27 17:49:21 EDT 2004
  ·  What's wrong with Hibernate? by Patrick Carroll on Mon Sep 27 10:56:37 EDT 2004
    ·  What's wrong with Hibernate? by Jacob Hookom on Mon Sep 27 11:12:41 EDT 2004
      ·  What's wrong with Hibernate? by Konstantin Ignatyev on Mon Sep 27 21:12:55 EDT 2004
      ·  What's wrong with Hibernate? by Santosh Maskar on Mon Sep 27 23:59:15 EDT 2004
    ·  Implementation without Specification by Jon Kofal on Mon Sep 27 11:12:53 EDT 2004
    ·  Hibernate as an API or Hibernate as an implementation? by John Reynolds on Mon Sep 27 11:42:04 EDT 2004
      ·  Hibernate as an API or Hibernate as an implementation? by Neill Robbins on Mon Sep 27 11:55:07 EDT 2004
        ·  Hibernate as an API or Hibernate as an implementation? by Eric Ma on Mon Sep 27 12:15:00 EDT 2004
          ·  Hibernate as an API or Hibernate as an implementation? by Huang Kai on Tue Sep 28 21:05:16 EDT 2004
        ·  Meeting in the middle by Dion Almaer on Mon Sep 27 12:27:41 EDT 2004
        ·  Hibernate as an API or Hibernate as an implementation? by Mark Nuttall on Mon Sep 27 12:47:28 EDT 2004
    ·  What's wrong with Hibernate? by Steve Zara on Mon Sep 27 18:21:40 EDT 2004
      ·  What's wrong with Hibernate? by Max Andersen on Tue Sep 28 08:06:22 EDT 2004
        ·  What's wrong with Hibernate? by Steve Zara on Tue Sep 28 09:51:54 EDT 2004
          ·  What's wrong with Hibernate? by Nick Minutello on Thu Sep 30 22:56:38 EDT 2004
        ·  What's wrong with Hibernate? by David Tinker on Tue Sep 28 11:04:00 EDT 2004
          ·  What's wrong with Hibernate? by Max Andersen on Tue Sep 28 17:06:38 EDT 2004
            ·  What's wrong with Hibernate? by Abe White on Tue Sep 28 17:48:39 EDT 2004
              ·  What's wrong with Hibernate? by Max Andersen on Tue Sep 28 23:39:12 EDT 2004
                ·  What's wrong with Hibernate? by Abe White on Wed Sep 29 00:29:17 EDT 2004
              ·  What's wrong with Hibernate? by Reto Breitenmoser on Wed Sep 29 02:37:52 EDT 2004
                ·  What's wrong with Hibernate? by Abe White on Wed Sep 29 03:11:56 EDT 2004
                ·  What's wrong with Hibernate? by Juozas Baliuka on Wed Sep 29 03:21:29 EDT 2004
    ·  What's wrong with Hibernate? by Andrej Gabara on Mon Sep 27 20:13:42 EDT 2004
      ·  I'm afraid I don't understand your comment. by Patrick Carroll on Tue Sep 28 07:50:41 EDT 2004
        ·  I'm afraid I don't understand your comment. by Andrej Gabara on Tue Sep 28 23:01:06 EDT 2004
          ·  I'm afraid I don't understand your comment. by Abe White on Tue Sep 28 23:24:42 EDT 2004
            ·  I'm afraid I don't understand your comment. by Andrej Gabara on Wed Sep 29 18:54:40 EDT 2004
          ·  I'm afraid I don't understand your comment. by Juozas Baliuka on Wed Sep 29 15:39:33 EDT 2004
      ·  What's wrong with Hibernate? by Max Andersen on Tue Sep 28 08:07:42 EDT 2004
    ·  What's wrong with Hibernate? by Tom Eugelink on Tue Sep 28 03:18:14 EDT 2004
      ·  What's wrong with Hibernate? by Mark Nuttall on Tue Sep 28 07:44:58 EDT 2004
      ·  What's wrong with Hibernate? by Max Andersen on Tue Sep 28 08:15:05 EDT 2004
    ·  What's wrong with Hibernate? by Carfield Yim on Tue Sep 28 07:35:57 EDT 2004
      ·  My takeaway as well. by Patrick Carroll on Tue Sep 28 07:58:54 EDT 2004
    ·  Nothing for simple uses by Simon Langford on Wed Sep 29 03:50:31 EDT 2004
  ·  Sun creates new Persistence API: EJB & JDO join forces by Jacob Hookom on Mon Sep 27 10:59:57 EDT 2004
    ·  EJB & JDO join forces by Jan Prill on Mon Sep 27 11:05:17 EDT 2004
  ·  Sun creates new Persistence API: EJB & JDO join forces by surajeet dev on Mon Sep 27 11:16:58 EDT 2004
  ·  So what IS wrong with Hibernate? by Neill Robbins on Mon Sep 27 11:17:03 EDT 2004
    ·  Standard Persistence API != Hibernate by Dion Almaer on Mon Sep 27 11:23:48 EDT 2004
      ·  Standard Persistence API != Hibernate by surajeet dev on Mon Sep 27 11:33:20 EDT 2004
        ·  This persistence API != All of EJB 3 :) by Dion Almaer on Mon Sep 27 12:24:53 EDT 2004
          ·  This persistence API != All of EJB 3 :) by Juergen Hoeller on Mon Sep 27 12:45:47 EDT 2004
            ·  The seperate API by Dion Almaer on Mon Sep 27 12:56:18 EDT 2004
              ·  The seperate API by Thomas Risberg on Mon Sep 27 13:29:50 EDT 2004
              ·  The seperate API by Chris Perrin on Mon Sep 27 16:48:28 EDT 2004
                ·  New name for new specification by Keiron McCammon on Mon Sep 27 17:05:04 EDT 2004
                  ·  New name for new specification by Erik Bengtson on Mon Sep 27 17:11:11 EDT 2004
                    ·  New name for new specification by totototo totototo on Tue Sep 28 08:00:58 EDT 2004
            ·  JSR-220 will deliver 2 specifications by Oliver Kamps on Mon Sep 27 12:56:46 EDT 2004
              ·  JSR-220 will deliver 2 specifications by Sutanu Ghosh on Mon Sep 27 13:13:29 EDT 2004
                ·  RE: JSR-220 will deliver 2 specifications by Dion Almaer on Mon Sep 27 13:19:01 EDT 2004
                  ·  RE: JSR-220 will deliver 2 specifications by Eric Ma on Mon Sep 27 13:25:08 EDT 2004
                  ·  RE: JSR-220 will deliver 2 specifications by Juergen Hoeller on Mon Sep 27 14:11:16 EDT 2004
                    ·  RE: JSR-220 will deliver 2 specifications by Dion Almaer on Mon Sep 27 14:47:50 EDT 2004
      ·  Standard Persistence API != Hibernate by Neill Robbins on Mon Sep 27 11:35:55 EDT 2004
        ·  PersistenceManager by Chris Perrin on Mon Sep 27 16:43:12 EDT 2004
    ·  So what IS wrong with Hibernate? by Mike Keith on Mon Sep 27 11:52:21 EDT 2004
    ·  So what IS wrong with Hibernate? by Sam Regh on Tue Sep 28 02:41:58 EDT 2004
      ·  So what IS wrong with Hibernate? by Emmanuel Bernard on Tue Sep 28 05:35:18 EDT 2004
        ·  So what IS wrong with Hibernate? by Juergen Hoeller on Tue Sep 28 07:17:29 EDT 2004
          ·  So what IS wrong with Hibernate? by Emmanuel Bernard on Tue Sep 28 09:47:41 EDT 2004
        ·  So what IS wrong with Hibernate? by Steve Zara on Tue Sep 28 09:54:19 EDT 2004
  ·  Sun creates new Persistence API: EJB & JDO join forces by Cameron Purdy on Mon Sep 27 11:18:52 EDT 2004
    ·  Sun creates new Persistence API: EJB & JDO join forces by Chris Perrin on Mon Sep 27 16:40:42 EDT 2004
  ·  Excellent idea by Arik Kfir on Mon Sep 27 11:23:05 EDT 2004
  ·  EJB & JDO join forces by Andy Jefferson on Mon Sep 27 12:09:03 EDT 2004
    ·  EJB & JDO join forces. Unequal marriage? by Alex Roytman on Mon Sep 27 17:59:58 EDT 2004
      ·  EJB & JDO join forces. Unequal marriage? by Matthias Kaiser on Mon Sep 27 18:25:25 EDT 2004
      ·  JDO 2: dead end? by Oliver Kamps on Tue Sep 28 04:06:25 EDT 2004
  ·  right into the quagmire by Rolf Tollerud on Mon Sep 27 12:23:59 EDT 2004
    ·  Rolf: I don't think you can talk much here. How is ObjectSpaces? by Dion Almaer on Mon Sep 27 12:30:03 EDT 2004
      ·  I feel misunderstood! :( by Rolf Tollerud on Mon Sep 27 13:22:08 EDT 2004
    ·  right into the quagmire by Cedric Beust on Mon Sep 27 12:44:57 EDT 2004
      ·  how to get a good laugh.. by Rolf Tollerud on Tue Sep 28 08:08:30 EDT 2004
      ·  right into the quagmire by Dorel Vaida on Wed Sep 29 03:40:22 EDT 2004
        ·  TSS, both useful and entertaining! (How common is that?) by Rolf Tollerud on Wed Sep 29 05:44:17 EDT 2004
  ·  Absolutely huge. by Bruce Tate on Mon Sep 27 13:36:30 EDT 2004
    ·  Why Make the Change ? by Rodolfo de Paula on Mon Sep 27 15:05:38 EDT 2004
      ·  Why Make the Change ? by Stephane TRAUMAT on Mon Sep 27 15:34:36 EDT 2004
        ·  Why Make the Change ? by Vagif Verdi on Mon Sep 27 17:45:51 EDT 2004
          ·  Why Make the Change ? by Mark Nuttall on Tue Sep 28 07:22:18 EDT 2004
  ·  Sun creates new Persistence API: EJB & JDO join forces by Todd Bowker on Mon Sep 27 14:18:41 EDT 2004
    ·  they never give up by Rolf Tollerud on Mon Sep 27 14:31:23 EDT 2004
      ·  they never give up by Todd Bowker on Tue Sep 28 13:08:51 EDT 2004
      ·  they never give up by Nick Minutello on Thu Sep 30 23:00:49 EDT 2004
      ·  Let JDO continue after 2.0 outside of JCP by Steven Sagaert on Sat Dec 18 09:34:32 EST 2004
        ·  Let JDO continue after 2.0 outside of JCP by Paul Beckford on Tue Jan 04 07:08:14 EST 2005
        ·  Let JDO continue after 2.0 outside of JCP by Tony Vai on Sat Feb 26 20:25:07 EST 2005
  ·  Guarded optimisim! by Vijay Ganesan on Mon Sep 27 15:59:40 EDT 2004
  ·  YAPM by Jean-Daniel Gamache on Mon Sep 27 16:19:32 EDT 2004
  ·  ahhh...what is wrong with JDBC? by Michael McCutcheon on Mon Sep 27 18:30:35 EDT 2004
    ·  ahhh...what is wrong with JDBC? by Konstantin Ignatyev on Mon Sep 27 18:47:21 EDT 2004
      ·  ahhh...what is wrong with JDBC? by Paul Barry on Wed Sep 29 13:39:57 EDT 2004
        ·  ahhh...what is wrong with JDBC? by Rolf Tollerud on Wed Sep 29 15:14:25 EDT 2004
    ·  ahhh...what is wrong with JDBC? by David McCoy on Mon Sep 27 20:02:49 EDT 2004
      ·  ahhh...what is wrong with JDBC? by Rashid Jilani on Mon Sep 27 21:25:47 EDT 2004
    ·  JDBC by Robert Hayes on Mon Sep 27 20:53:33 EDT 2004
      ·  Re: JDBC by Amin Mansuri on Mon Sep 27 22:43:07 EDT 2004
        ·  Eventually, MS will have the last laugh by tom tarb on Mon Sep 27 23:57:31 EDT 2004
          ·  Eventually, MS will have the last laugh by Rolf Tollerud on Tue Sep 28 02:14:51 EDT 2004
          ·  ADO.NET == JDBC, ObjectSpaces == JDO by Matthew Adams on Tue Sep 28 13:21:18 EDT 2004
          ·  read, understand, then post by Steve Ebersole on Wed Sep 29 22:37:24 EDT 2004
            ·  read, understand, then post by Rolf Tollerud on Wed Sep 29 23:43:25 EDT 2004
              ·  yes by Steve Ebersole on Thu Sep 30 00:45:25 EDT 2004
            ·  g by Steve Ebersole on Thu Sep 30 00:55:40 EDT 2004
              ·  why? by Rolf Tollerud on Thu Sep 30 01:25:23 EDT 2004
        ·  Re: JDBC by Cameron Purdy on Tue Sep 28 00:41:44 EDT 2004
          ·  Re: JDBC by Marina Prikaschikova on Tue Sep 28 07:34:41 EDT 2004
            ·  Re: JDBC by Cameron Purdy on Tue Sep 28 12:40:57 EDT 2004
          ·  Re: JDBC by Andre Mermegas on Tue Sep 28 13:08:16 EDT 2004
            ·  Re: JDBC by Andre Mermegas on Tue Sep 28 13:10:45 EDT 2004
            ·  Re: JDBC by Cameron Purdy on Tue Sep 28 22:00:37 EDT 2004
      ·  JDBC by Michael McCutcheon on Mon Sep 27 23:46:08 EDT 2004
        ·  JDBC by Toby Reyelts on Tue Sep 28 01:00:27 EDT 2004
        ·  JDBC by Juozas Baliuka on Tue Sep 28 04:43:09 EDT 2004
        ·  JDBC by Mark Nuttall on Tue Sep 28 08:11:30 EDT 2004
        ·  JDBC by Matthew Adams on Tue Sep 28 13:27:29 EDT 2004
        ·  JDBC by peter mutsaers on Wed Sep 29 10:32:15 EDT 2004
          ·  JDBC by john smith on Wed Sep 29 10:58:51 EDT 2004
        ·  JDBC by Martin N. on Fri Nov 12 19:52:37 EST 2004
        ·  JDBC by vik sheth on Wed Jan 19 16:12:59 EST 2005
    ·  Why ORM can be nice.. by Dion Almaer on Mon Sep 27 23:44:31 EDT 2004
      ·  Why ORM can be nice.. by Michael McCutcheon on Tue Sep 28 00:00:58 EDT 2004
        ·  ORM doesn't mean "The tool churns out the DDL" by Dion Almaer on Tue Sep 28 00:09:23 EDT 2004
        ·  Different strokes for different folks by Toby Reyelts on Tue Sep 28 01:19:53 EDT 2004
        ·  Why ORM can be nice.. by Mark Nuttall on Tue Sep 28 08:25:43 EDT 2004
          ·  Why ORM can be nice.. by Alex V on Tue Sep 28 09:14:36 EDT 2004
            ·  Why ORM can be nice.. by Mark Nuttall on Tue Sep 28 09:28:49 EDT 2004
              ·  Why ORM can be nice.. by Juozas Baliuka on Tue Sep 28 10:10:47 EDT 2004
                ·  Why ORM can be nice.. by Alex V on Tue Sep 28 10:40:47 EDT 2004
                ·  Why ORM can be nice.. by Mark Nuttall on Tue Sep 28 12:29:38 EDT 2004
                  ·  in search of an honest person.. by Rolf Tollerud on Tue Sep 28 12:35:53 EDT 2004
                    ·  in search of an honest person.. by Mark Nuttall on Tue Sep 28 12:52:31 EDT 2004
                      ·  found one by Rolf Tollerud on Tue Sep 28 13:10:37 EDT 2004
            ·  multiple access routes by thoff thoff on Tue Sep 28 09:57:02 EDT 2004
              ·  multiple access routes by Alex V on Tue Sep 28 10:26:38 EDT 2004
                ·  multiple access routes by Juozas Baliuka on Tue Sep 28 10:46:44 EDT 2004
    ·  ahhh...what is wrong with JDBC? by Mark Nuttall on Tue Sep 28 07:58:18 EDT 2004
    ·  ahhh...what is wrong with JDBC? by Steve Zara on Tue Sep 28 10:49:57 EDT 2004
    ·  ahhh...what is wrong with JDBC? by Markus Kirsten on Tue Sep 28 15:24:52 EDT 2004
    ·  ahhh...what is wrong with JDBC? by Fredrik Bertilsson on Tue Sep 28 23:12:22 EDT 2004
      ·  ahhh...what is wrong with JDBC? by Mark Nuttall on Wed Sep 29 07:41:46 EDT 2004
    ·  Not stupid. Just lazy. by Sean Broadley on Tue Sep 28 23:24:25 EDT 2004
  ·  A first move towards fixing EJBs by Sean Broadley on Mon Sep 27 19:23:29 EDT 2004
  ·  No optional semantic on the stantard. by Rodrigo Kumpera on Mon Sep 27 19:34:44 EDT 2004
  ·  Stored procedure issue by Code Manner on Mon Sep 27 21:18:04 EDT 2004
    ·  Stored procedure issue by PJ Murray on Fri Apr 08 16:57:58 EDT 2005
  ·  no amount of emergency procedures will help by Rolf Tollerud on Mon Sep 27 21:30:12 EDT 2004
  ·  Extraordinary. by Chris Beams on Tue Sep 28 00:55:52 EDT 2004
    ·  Extraordinary. by Matthew Adams on Tue Sep 28 13:46:02 EDT 2004
  ·  Changing APIs... MDA! by Lofi Dewanto on Tue Sep 28 02:16:30 EDT 2004
    ·  Changing APIs... MDA! by Lofi Dewanto on Tue Sep 28 02:26:53 EDT 2004
  ·  Congratulations! by Wilfred Springer on Tue Sep 28 02:43:35 EDT 2004
    ·  Congratulations! by Carlo Marchiori on Tue Sep 28 02:46:05 EDT 2004
  ·  Sun creates new Persistence API: EJB & JDO join forces by Muhammad Mansoor on Tue Sep 28 06:47:03 EDT 2004
  ·  Great news and kudos to Sun! Surprised by TSS reaction by Kalyan Kolachala on Tue Sep 28 08:15:55 EDT 2004
    ·  Great news and kudos to Sun! Surprised by TSS reaction by Henrique Steckelberg on Tue Sep 28 09:38:04 EDT 2004
      ·  Please explain like to a 7 years old.. by Rolf Tollerud on Tue Sep 28 10:25:55 EDT 2004
        ·  P.S. by Rolf Tollerud on Tue Sep 28 10:45:37 EDT 2004
        ·  Please explain like to a 7 years old.. by Henrique Steckelberg on Tue Sep 28 11:30:23 EDT 2004
          ·  still don't understand by Rolf Tollerud on Tue Sep 28 12:06:02 EDT 2004
            ·  still don't understand by Juozas Baliuka on Tue Sep 28 12:36:14 EDT 2004
            ·  still don't understand by Mark Nuttall on Tue Sep 28 12:45:05 EDT 2004
              ·  still don't understand by Juozas Baliuka on Tue Sep 28 13:15:40 EDT 2004
                ·  still don't understand by Mark Nuttall on Tue Sep 28 13:34:51 EDT 2004
            ·  still don't understand by Henrique Steckelberg on Tue Sep 28 13:19:54 EDT 2004
              ·  still don't understand by Juozas Baliuka on Tue Sep 28 13:31:41 EDT 2004
                ·  still don't understand by Mark Nuttall on Tue Sep 28 13:38:06 EDT 2004
                  ·  still don't understand by Mark Nuttall on Tue Sep 28 13:52:48 EDT 2004
                ·  still don't understand by Henrique Steckelberg on Tue Sep 28 13:47:44 EDT 2004
                  ·  still don't understand by Juozas Baliuka on Tue Sep 28 14:59:26 EDT 2004
                    ·  still don't understand by Henrique Steckelberg on Tue Sep 28 15:37:32 EDT 2004
                      ·  I almost don't dare saying it.. by Rolf Tollerud on Tue Sep 28 16:34:14 EDT 2004
                        ·  We will be Assimilated (just waiting 'till 20xx for Longhorn...) by Jon Kofal on Wed Sep 29 05:27:56 EDT 2004
                          ·  We will be Assimilated (just waiting 'till 20xx for Longhorn...) by Rolf Tollerud on Wed Sep 29 05:47:42 EDT 2004
                        ·  I almost don't dare saying it.. by Mark Nuttall on Wed Sep 29 07:27:26 EDT 2004
                          ·  ORM are for beginners.. by Rolf Tollerud on Wed Sep 29 07:55:36 EDT 2004
                            ·  ORM are for beginners.. by Mark Nuttall on Wed Sep 29 10:37:47 EDT 2004
                    ·  No problem losing transations in telecoms by Oliver Kamps on Tue Sep 28 15:50:12 EDT 2004
                      ·  No problem losing transations in telecoms by Mark Nuttall on Tue Sep 28 15:53:25 EDT 2004
                        ·  No problem losing transations in telecoms by Mark Nuttall on Tue Sep 28 15:54:19 EDT 2004
                        ·  No problem losing transations in telecoms by Juozas Baliuka on Tue Sep 28 17:12:08 EDT 2004
                          ·  No problem losing transations in telecoms by Mark Nuttall on Wed Sep 29 07:33:56 EDT 2004
                      ·  No problem losing transations in telecoms by Juozas Baliuka on Tue Sep 28 16:07:37 EDT 2004
                        ·  No problem losing transations in telecoms by Henrique Steckelberg on Tue Sep 28 16:33:24 EDT 2004
                        ·  legacy data by alex popescu on Tue Sep 28 16:34:05 EDT 2004
                        ·  No problem losing transations in telecoms by Cameron Purdy on Tue Sep 28 22:11:32 EDT 2004
                          ·  No problem losing transations in telecoms by Juozas Baliuka on Wed Sep 29 01:07:34 EDT 2004
            ·  Persistence is not ORM, and not JDBC by alex popescu on Tue Sep 28 14:11:24 EDT 2004
        ·  Please explain like to a 7 years old.. by Shireesh Thanneru on Tue Sep 28 11:59:08 EDT 2004
  ·  No EJB3.0 Persistence? by Andy Stefancik on Tue Sep 28 18:49:18 EDT 2004
    ·  No EJB3.0 Persistence? by Donald Smith on Tue Sep 28 20:50:53 EDT 2004
      ·  so will the new API be javax.jdo.* or javax.ejb.* ??? by Dave Clark on Tue Sep 28 21:49:06 EDT 2004
        ·  so will the new API be javax.jdo.* or javax.ejb.* ??? by David Tinker on Wed Sep 29 01:50:36 EDT 2004
          ·  so will the new API be javax.jdo.* or javax.ejb.* ??? by Tony Vai on Sat Feb 26 19:51:37 EST 2005
  ·  Not just a good thing by Charles Nutter on Tue Sep 28 19:05:15 EDT 2004
  ·  Vendors shoving EJB to users that want SQL by Vic Cekvenich on Wed Sep 29 11:50:06 EDT 2004
    ·  User input in JCP by Oliver Kamps on Wed Sep 29 12:13:06 EDT 2004
      ·  User input in JCP by Vic Cekvenich on Wed Sep 29 12:54:15 EDT 2004
        ·  User input in JCP by Oliver Kamps on Wed Sep 29 13:13:56 EDT 2004
        ·  User input in JCP by Robin Roos on Wed Sep 29 13:30:08 EDT 2004
  ·  Persistence Needs and Queries by Frank LaRosa on Thu Oct 28 17:30:36 EDT 2004
  ·  Sun really do a perfect choice by Jim Huang on Thu Oct 28 22:35:40 EDT 2004
  Message #139815 Post reply Post reply Post reply Go to top Go to top Go to top

Sun creates new Persistence API: EJB & JDO join forces

Posted by: Konstantin Ignatyev on September 27, 2004 in response to Message #139630
Sun is hoping that the entire community can get behind the goal of ONE persitence API for J2SE and J2EE.
It has been beaten to death: there is no single right way to do things and persistence is no different. So the efforts to build THE persistence API are doomed.

  Message #139816 Post reply Post reply Post reply Go to top Go to top Go to top

What's wrong with Hibernate?

Posted by: Patrick Carroll on September 27, 2004 in response to Message #139630
Just wondering.

  Message #139817 Post reply Post reply Post reply Go to top Go to top Go to top

Sun creates new Persistence API: EJB & JDO join forces

Posted by: Jacob Hookom on September 27, 2004 in response to Message #139630
I think this is a wonderful idea. Based on the weblogs on java.net, there are a lot of developers out there reflecting on what open source/options has done to software development on the java platform (good and bad).

With JSF and now a Persistence API, I believe web application development will a lot more coherant across solutions with possible tool support.

As for the comment about there not being one solution for persistence, that's blatently true, but if the new persistene API can solve the 'common' case, I'm all for it.

  Message #139818 Post reply Post reply Post reply Go to top Go to top Go to top

EJB & JDO join forces

Posted by: Jan Prill on September 27, 2004 in response to Message #139817
Can't agree more. If you're dependent on standards, than in my opinion this is the best thing that could have happened. There has been a lot of discussions about EJB, JDO and their differences, now there is the chance to use this discussions to evolve a great persistence technology for the most common cases. Great!!!!!!

  Message #139820 Post reply Post reply Post reply Go to top Go to top Go to top

What's wrong with Hibernate?

Posted by: Jacob Hookom on September 27, 2004 in response to Message #139816
What's wrong with Hibernate?
Nothing is wrong with Hibernate at all and IMHO, it's the best solution for the Java platform.

How best to explain the underlying issue--

When you write Java code, you use utility classes like List and Map. They are used all over the place in your code like persistence logic. But, what if Java didn't have a List or Map in their API and you had to pick an open source solution every time? How confident are you in vendor A's implementation of Map versus B's and what if you need to swap later in the project?

I look at persistence frameworks the same way-- a lot of great implementations, but you have to write your own facade over everything and hide implementation features in order to protect the longevity of your application code.

Having a common Persistence API doesn't commit you to an implemenation persay, but allows you to proceed with confidence in a common API across J2SE and J2EE. I believe it will spawn stronger persistence solutions if the API is setup correctly to even allow Hibernate to adapt 'under the sheets'.

http://hookom.blogspot.com

  Message #139821 Post reply Post reply Post reply Go to top Go to top Go to top

Implementation without Specification

Posted by: Jon Kofal on September 27, 2004 in response to Message #139816
Any questions?

  Message #139822 Post reply Post reply Post reply Go to top Go to top Go to top

Why ONE?

Posted by: Dion Almaer on September 27, 2004 in response to Message #139815
Konstantin -

I understand what you are saying. But, if you look at the EJB 3 and JDO 2 specs, they aren't that different at all in the MAJOR ways. If the groups can get together and work out the couple of wrinkles so everyone is happy, then the community benefits.

I therefore think it makes obvious sense to have one persistence API that is standardized in this way.

If a totally new form of persistence comes up, then that is a different matter.

Also, the spec is there to get together commonality. Vendors will put in their own features to differentiate themselves (which is why I think having a pluggable API is good. I want to be able to choose my persistence vendor :)

Cheers,

Dion

  Message #139823 Post reply Post reply Post reply Go to top Go to top Go to top

Sun creates new Persistence API: EJB & JDO join forces

Posted by: surajeet dev on September 27, 2004 in response to Message #139630
Is it also a move towards accepting that not all is well with EJB's? In that case,it would mean that _of_late discussions about EJB's were heard,by all concerned.

  Message #139824 Post reply Post reply Post reply Go to top Go to top Go to top

So what IS wrong with Hibernate?

Posted by: Neill Robbins on September 27, 2004 in response to Message #139630
Bizarre.

Unless I'm reading it incorrectly, this is a re-implementation of Hibernate. By committee.

Sounds completely pointless to me. I can see its (possibly) more worthwhile if the intention is to create POJO persistance to more than just relational EIS', but as the stated intention is Object Realational. I'm a bit confused.

Gavin, Juergen. You there to make a comment?

  Message #139826 Post reply Post reply Post reply Go to top Go to top Go to top

Sun creates new Persistence API: EJB & JDO join forces

Posted by: Cameron Purdy on September 27, 2004 in response to Message #139630
Also picked up by eWeek.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

  Message #139827 Post reply Post reply Post reply Go to top Go to top Go to top

Excellent idea

Posted by: Arik Kfir on September 27, 2004 in response to Message #139630
I'll gladly join the parade of "whoohoo" ;-)

I wonder whether we're going to a common "persistence specification", with JDO and EJB as implementations, or rather to a whole new model?

Personally, I hope the new spec will define a common set of annotations for JDK1.5 and have both JDO and EJB-servers implement these annotations - for each his own! :)

Cheers,
    Arik Kfir.

  Message #139828 Post reply Post reply Post reply Go to top Go to top Go to top

Standard Persistence API != Hibernate

Posted by: Dion Almaer on September 27, 2004 in response to Message #139824
Hibernate is a fantastic ORM product.

There are a lot of OTHER great ORM solutions however, and these vendors are also involved in the standard.

This API is not just Hibernate3, but is based on great ideas from:

Hibernate, JDO, TOPLink, <insert your favorite ORM software here>...

If there is a feature that you feel is needed, let the expert group know.

Dion

  Message #139831 Post reply Post reply Post reply Go to top Go to top Go to top

Standard Persistence API != Hibernate

Posted by: surajeet dev on September 27, 2004 in response to Message #139828
Hibernate is a fantastic ORM product.There are a lot of OTHER great ORM solutions however, and these vendors are also involved in the standard.This API is not just Hibernate3, but is based on great ideas from:Hibernate, JDO, TOPLink, <insert your favorite ORM software here>...If there is a feature that you feel is needed, let the expert group know.Dion
Is it true , that most people think that EJB's are provided to 'only' solve OR mapping?

  Message #139832 Post reply Post reply Post reply Go to top Go to top Go to top

Standard Persistence API != Hibernate

Posted by: Neill Robbins on September 27, 2004 in response to Message #139828
I undestand this, and will admit writing from a position of ignorance as I have only used IBATIS and Hibernate.

Am I correct in my undersatnding that JDO is more than 'just' ORM? i thought it did non relational mappings as well.

So would that mean that any proposed solution would be a cut down version of JDO for the relational space?

Why would you want to reinvent the wheel, or require everbody conform to some committee based et of functionality? Why not allow each of these vendors to plug their persistence framework in using some sort of PersistanceManager, and allow the user decide which of the numerous ORM frameworks to use based on requirements and technical fit, a'la web frameworks...

Only asking...

  Message #139833 Post reply Post reply Post reply Go to top Go to top Go to top

Hibernate as an API or Hibernate as an implementation?

Posted by: John Reynolds on September 27, 2004 in response to Message #139816
The only problem with Hibernate is that it is a product, not a specification.

It's a great product, but at the moment there's no way for multiple implementations (how would you know that your version is compliant with the "reference implementation).

  Message #139834 Post reply Post reply Post reply Go to top Go to top Go to top

So what IS wrong with Hibernate?

Posted by: Mike Keith on September 27, 2004 in response to Message #139824
Bizarre.Unless I'm reading it incorrectly, this is a re-implementation of Hibernate. By committee.Sounds completely pointless to me.
Yes, you are reading it wrong. EJB 3 is attempting to fix some of the longstanding problems with persistent entities and bring it in line with modern persistence technology. Hibernate is one of the current products from which many ideas are being taken. TopLink is another popular product which is being significantly represented. The same can be said of BEA's product experience. I think that if you take a closer look you will recognize the mixture of features that everybody likes and that we hope will be able to be standardized.

-Mike

  Message #139835 Post reply Post reply Post reply Go to top Go to top Go to top

Why ONE?

Posted by: Konstantin Ignatyev on September 27, 2004 in response to Message #139822
Konstantin -I understand what you are saying. But, if you look at the EJB 3 and JDO 2 specs, they aren't that different at all in the MAJOR ways. If the groups can get together and work out the couple of wrinkles so everyone is happy, then the community benefits.I therefore think it makes obvious sense to have one persistence API that is standardized in this way. If a totally new form of persistence comes up, then that is a different matter.Also, the spec is there to get together commonality. Vendors will put in their own features to differentiate themselves (which is why I think having a pluggable API is good. I want to be able to choose my persistence vendor :)Cheers,Dion
IMO: Marrying JDO and ORM imposes unnecessary burden on non-RDBMS storages or persistence implementations, and in the same time hides power of RDBMS.
I know, I know there will be some hooks to allow using RDBMS (SQL) directly, but then we again have non-standard solutions.
Kind of situation with JDO now: it is virtually useless without vendor extensions which allow better query language and more RDBMS oriented.
How big will be Hibernate(TopLink, etc) if it has to support flat files or tree storage (LDAP)? Will it provide same features for those kinds of storages? Does it make sense even try? - I doubt so.

  Message #139837 Post reply Post reply Post reply Go to top Go to top Go to top

Hibernate as an API or Hibernate as an implementation?

Posted by: Neill Robbins on September 27, 2004 in response to Message #139833
OK. Perhaps if I'd read some of the emails that arrived while i was writing mine... :-)

So the idea is a common persisance api, and presumably vendor specific adapters to specifc implementations.

So, what I was trying to say (badly) then.

All sounds lovely.

Anybody got any idea how big a bunfight is likely trying to get all the various persistance frameworks to agree on a common adapter framework? Just how disparate are the solutions out there?

  Message #139842 Post reply Post reply Post reply Go to top Go to top Go to top

EJB & JDO join forces

Posted by: Andy Jefferson on September 27, 2004 in response to Message #139630
As a JDO provider, I welcome this initiative since JDO has always been about providing a definitive API for persistence, and O/R mapping is a major part of that.

I would however point out that the timescales for EJB 3 are "not aggresive" to say the least (talking about 2006 here aren't we ?). Implementations of JDO 2.0 were always going to be in production usage well before that. The JPOX JDO OpenSource implementation will continue to implement the latest standard of O/R mapping as far as it has been defined by the JDO 2.0 Expert Group (JSR 243) and *when* this common O/R mapping initiaive delivers fruit we will adapt to that.


Andy
Java Persistent Object JDO (JPOX)

  Message #139843 Post reply Post reply Post reply Go to top Go to top Go to top

Hibernate as an API or Hibernate as an implementation?

Posted by: Eric Ma on September 27, 2004 in response to Message #139837
So the idea is a common persisance api, and presumably vendor specific adapters to specifc implementations.
If we are indeed trying to develop a common Java persistence API which is data store agnostic, then the EJB 3.0 JSR-220 is definitely NOT the best place to put in it. For marketing and political purpose, IMHO we need to start a new JSR. Then JSR-220 can become the ORM implementation, and JSR-243 covers the kitchen sink other than relational databases.

  Message #139844 Post reply Post reply Post reply Go to top Go to top Go to top

Entity Beans in EJB3???

Posted by: srikanth koppisetty on September 27, 2004 in response to Message #139815
Does anybody of you know the future of Entity Beans, is that still going to be there in EJB3 or further?
Is persistence concept is changing or drifting towards the same concept as JDO?

Srikanth Koppisetty

  Message #139846 Post reply Post reply Post reply Go to top Go to top Go to top

right into the quagmire

Posted by: Rolf Tollerud on September 27, 2004 in response to Message #139630
"Bizarre.Unless I'm reading it incorrectly, this is a re-implementation of Hibernate. By committee"

Anybody got any idea how big a bunfight is likely trying to get all the various persistance frameworks to agree on a common adapter framework? Just how disparate are the solutions out there?

:) I never thought I could be gleeful but I succumbed.
After all one is only human.

The situation is:
Both Microsoft and Sun & Co is working on the same impossible task! And the only person that maybe could untied this "Gordian Knut", - Gavin King is not a member of anything.

Regards
Rolf Tollerud

  Message #139848 Post reply Post reply Post reply Go to top Go to top Go to top

This persistence API != All of EJB 3 :)

Posted by: Dion Almaer on September 27, 2004 in response to Message #139831
Surajeet -

What we are talking about here is new spec that for now sits within JSR-220.

There will still be another spec for the rest of EJB 3.

Thus, EJB 3 is NOT just about persistence. The persistence portion has just been moved to a new sub-spec, with everyone getting behind it.

Dion

  Message #139849 Post reply Post reply Post reply Go to top Go to top Go to top

Meeting in the middle

Posted by: Dion Almaer on September 27, 2004 in response to Message #139837
Anybody got any idea how big a bunfight is likely trying to get all the various persistance frameworks to agree on a common adapter framework? Just how disparate are the solutions out there?
This is the world of working in commitees. We already have a bunch of vendors from the EJB 3 side who were able to come up with their draft spec. JDO 2 has a lot of ORM vendors and they were able to come up with their spec too.

It isn't easy. It sometimes isn't pretty. But if everyone gets their heads down and works together it can work.

Also, the role of the spec isn't to specify everything! Vendors will compete with their implementations.

Dion

  Message #139850 Post reply Post reply Post reply Go to top Go to top Go to top

Rolf: I don't think you can talk much here. How is ObjectSpaces?

Posted by: Dion Almaer on September 27, 2004 in response to Message #139846
Ah Rolf :)

I don't think anyone from a Microsoft world can laugh too much here.

ObjectSpaces has been around for HOW long without a release? I feel so sorry for the poor product lead who ended up moving over to C#. And you can't blame the guy... he may want to see his technology released at some point ;)

And when ObjectSpaces is finally released, it is just one product NOT a standard. Hibernate.NET will be killing it by then ;)

Dion

  Message #139852 Post reply Post reply Post reply Go to top Go to top Go to top

right into the quagmire

Posted by: Cedric Beust on September 27, 2004 in response to Message #139846
And the only person that maybe could untied this "Gordian Knut", - Gavin King is not a member of anything.RegardsRolf Tollerud
What are you talking about? Gaving has been a member of the JSR 220 Experts Group (which becomes the new umbrella JSR) for over six months now.

--
Cedric
http://beust.com/weblog

  Message #139853 Post reply Post reply Post reply Go to top Go to top Go to top

This persistence API != All of EJB 3 :)

Posted by: Juergen Hoeller on September 27, 2004 in response to Message #139848
What we are talking about here is new spec that for now sits within JSR-220.There will still be another spec for the rest of EJB 3.Thus, EJB 3 is NOT just about persistence. The persistence portion has just been moved to a new sub-spec, with everyone getting behind it.
Dion,

Is this confirmed information? The open letter doesn't clearly outline the strategy in that respect. It rather seems to imply that JSR-220 will cover both EJB 3 and POJO persistence, just with separate RIs etc.

If JSR-220 becomes a pure POJO persistence JSR, will it be renamed? Any suggestions for a new name? And will a new JSR then be called "EJB 3.0"? This is a bit confusing, to say the least...

Juergen

  Message #139854 Post reply Post reply Post reply Go to top Go to top Go to top

Hibernate as an API or Hibernate as an implementation?

Posted by: Mark Nuttall on September 27, 2004 in response to Message #139837
Glad I was not eating or drinking when I read your post. :)

  Message #139857 Post reply Post reply Post reply Go to top Go to top Go to top

The seperate API

Posted by: Dion Almaer on September 27, 2004 in response to Message #139853
Hi Juergen -

This line is key:
The new POJO persistence model will be delivered by JSR-220 as a separate specification, Reference Implementation, and Technology Compatibility Kit, usable independently of EJB 3.0.
Although it is under JSR-220 now, in the future (after this release) this could be moved to its own group (I personally think this makes sense, but it will be up to the JCP of course).

There currently isn't a name for this new spec/ri/tck, any suggestions?

Dion

  Message #139858 Post reply Post reply Post reply Go to top Go to top Go to top

JSR-220 will deliver 2 specifications

Posted by: Oliver Kamps on September 27, 2004 in response to Message #139853
Hi,

my understanding is that JSR-220 will deliver two specifications, two RIs, and two TCKs.

One set of those will deal with EJB 3, the other set will deal with the new/common persistence API.

Cheers,
Oliver

  Message #139859 Post reply Post reply Post reply Go to top Go to top Go to top

JSR-220 will deliver 2 specifications

Posted by: Sutanu Ghosh on September 27, 2004 in response to Message #139858
JSR-220 will deliver two specifications
It's getting a bit confusing right at the start. I would rather prefer JSR-220 to be EJB 3 minus persistence. And create a new JSR for the new persistence api.

  Message #139860 Post reply Post reply Post reply Go to top Go to top Go to top

RE: JSR-220 will deliver 2 specifications

Posted by: Dion Almaer on September 27, 2004 in response to Message #139859
Sutanu -

I think a bunch of people agree with you. The reason to keep it under JSR-220 was to "build on the momentum" and the fact that it takes time to create a new JSR etc.

Hopefully for the next version it WILL be a seperate JSR, with its own expert group, etc etc.

Dion

  Message #139861 Post reply Post reply Post reply Go to top Go to top Go to top

I feel misunderstood! :(

Posted by: Rolf Tollerud on September 27, 2004 in response to Message #139850
Dion,

I am not in first hand against Unix/Java, but against overcomplicated solutions in general. I'm a big fan of Spring, Velocity and iBatis for example.

That said, I must admit that IMO, MS is better avoiding over-architecture that than the competition. In the case of ObjectSpaces however, they are in the same deep shit.

So my laugh is as much for ObjectSpaces as this project. Both are doomed.

Regards
Rolf Tollerud
(I said it first..)

  Message #139862 Post reply Post reply Post reply Go to top Go to top Go to top

RE: JSR-220 will deliver 2 specifications

Posted by: Eric Ma on September 27, 2004 in response to Message #139860
We need the FAQ badly!

  Message #139863 Post reply Post reply Post reply Go to top Go to top Go to top

The seperate API

Posted by: Thomas Risberg on September 27, 2004 in response to Message #139857
How about MOJO Specification (Mapped Old Java Object) :)

Even though the choice of JSR to define this standard could be argued, the specification itself is after all what we really need as long as it is independent when it comes to deployment dependencies.

  Message #139864 Post reply Post reply Post reply Go to top Go to top Go to top

Absolutely huge.

Posted by: Bruce Tate on September 27, 2004 in response to Message #139630
I've long been in favor of breaking the EJB entity bean model out of the EJB core specification. (That was one of the core motivations of "Don't make me eat the Elephant Again.") This is long overdue, in my book. It also makes it possible to use my two favorite persistence frameworks (Kodo, Hibernate) where they best fit, and learn a single API.

At the core, EJB should be about how you package, produce, and consume enterprise services in a potentially transactional distributed environment. Persistence never belonged in that specification. This change takes us in that direction, and it's most welcome.

Well done, JSR 220 and 243 teams.

  Message #139870 Post reply Post reply Post reply Go to top Go to top Go to top

RE: JSR-220 will deliver 2 specifications

Posted by: Juergen Hoeller on September 27, 2004 in response to Message #139860
The reason to keep it under JSR-220 was to "build on the momentum" and the fact that it takes time to create a new JSR etc.Hopefully for the next version it WILL be a seperate JSR, with its own expert group, etc etc.Dion
Well, so the first version will be part of the EJB 3 umbrella, and have version number 3.0? Then the next version could be an independent JSR, and start again at version number 1.0?

Furthermore, what's the future for JDO 2.0? Will it happen at all, under that name? The open letter indicates "maintenance" for JDO 1.0.1, but doesn't show the ambitious goals anymore that JDO 2.0 originally had.

I'm still confused. I do welcome this effort - a dedicated spec for POJO O/R mapping is overdue -, but the exact conditions are obviously still unclear. In the long run, we absolutely need a separate JSR for this.

Juergen

  Message #139871 Post reply Post reply Post reply Go to top Go to top Go to top

Sun creates new Persistence API: EJB & JDO join forces

Posted by: Todd Bowker on September 27, 2004 in response to Message #139630
I thought we already had a POJO persistence layer called JDO. I don't understand why EJB can't retire at this point and JDO can improve. Why rally everyone around yet another standard when there is one already.

Two great choices: JDO/Kodo and Hibernate.

I think what is going on here is that the EJB camp is trying to "outdo" the framework of the month to get developers to switch to something else. Why can't Sun just give EJB the boot? EJB is absolute 100% crap. I know...I worked with it. I know it's different this time, but it's too late folks.


I get my job done with Hibernate. EJB just a big theory/fantasy with poor implementation.

Now we are going to have the Uber persistence framework of the future. Maybe it will be out in 4 years or so. Maybe....

  Message #139876 Post reply Post reply Post reply Go to top Go to top Go to top

they never give up

Posted by: Rolf Tollerud on September 27, 2004 in response to Message #139871
Todd! Do not be so grumpy

EJB is absolute 100% crap. I know...I worked with it."

"EJB just a big theory/fantasy with poor implementation"

"Now we are going to have the Uber persistence framework of the future."

At least they should have + for being persistent! Pun intented :)

Consider the entertainment value.

  Message #139878 Post reply Post reply Post reply Go to top Go to top Go to top

RE: JSR-220 will deliver 2 specifications

Posted by: Dion Almaer on September 27, 2004 in response to Message #139870
Well, so the first version will be part of the EJB 3 umbrella, and have version number 3.0? Then the next version could be an independent JSR, and start again at version number 1.0?

Furthermore, what's the future for JDO 2.0? Will it happen at all, under that name? The open letter indicates "maintenance" for JDO 1.0.1, but doesn't show the ambitious goals anymore that JDO 2.0 originally had. I'm still confused. I do welcome this effort - a dedicated spec for POJO O/R mapping is overdue -, but the exact conditions are obviously still unclear. In the long run, we absolutely need a separate JSR for this.

Juergen
Great questions Juergen. I am hoping that Sun will come out with a FAQ that will go into some of these details, as the community should know.

Wrt JDO 2.0, that expert group is still intact, and can continue to finish up JDO 2.0. I am dissapointed in the wording in the open letter that just mentions JDO 1.0.1 which is confusing.

Dion

  Message #139882 Post reply Post reply Post reply Go to top Go to top Go to top

Why Make the Change ?

Posted by: Rodolfo de Paula on September 27, 2004 in response to Message #139864
At the core, EJB should be about how you package, produce, and consume enterprise services in a potentially transactional distributed environment. Persistence never belonged in that specification.
At least for me, there already exists a standart way to package, produce and consume transacional components/resources : Spring. We can use any persistence choice (including proprietary/crap stuff) and even integrate JTA resources, despite as Gavin has pointed some weeks ago that JTA use has been a kind of rare requirement (at least for databases) and its apply to my past projects too.

The word "enterprise" for me means the necessity for the container / application server to provide solid (and easy) administrative functionality for their services and resources, specially the integration of this stuff within the topology options and cluster configuration it provides (the only functional diferential J2EE vendors can provide, since J2EE is a spec).

Bruce, I know you are writing a Spring book, it just my point of view.

We have seen so much effort - even more than yeat another MVC framework history ;) - to specify or build persistence stuff, relational mapping to Pojos, etc and I never understand why people don't realize there are already a lot of good options to do this, the only thing necessary is pickup one and start working...

Call me crazy but I have an opinion these efforts would be much more effective if we (Java guys) grow up and start to think really big : Relational database written in Java...the next frontier.

Why we can have mission critical enterprise, blah, blah.. applications servers but not databases written in Java ? Now we have Cloudscape as Open Source, why it (or any else) cannot get more support from us ?

BTW : Some arguments here http://javaboutique.internet.com/articles/RDBMS/

  Message #139885 Post reply Post reply Post reply Go to top Go to top Go to top

Why Make the Change ?

Posted by: Stephane TRAUMAT on September 27, 2004 in response to Message #139882
I searched during hours for articles telling me how cloudscape can compete versus mysql and postgresql but i haven't found :(

Can anyone tells me if it's a good solution for database with less than 1 millions lines ? is it enough fast ?

  Message #139888 Post reply Post reply Post reply Go to top Go to top Go to top

Guarded optimisim!

Posted by: Vijay Ganesan on September 27, 2004 in response to Message #139630
This sounds like great news. I hope it delivers on the promise of a simple and standardized POJO persistence model that most Java developers can use. (Note to Hibernate worshippers - standardization to a spec is key for wide acceptance by the community. Proprietary solutions, especially for basic things like persistence, will have limited adoption).

I do hope that the JDO folks manage to influence the spec more than the EJB folks who gave us entity beans (perhaps the most ridiculed and hated thing in recent times!). It is also my sincere hope that we have a solution that can work within and OUTSIDE a container. If the container vendors were to hijack this community process, it would be a shame.

Vijay Ganesan

  Message #139890 Post reply Post reply Post reply Go to top Go to top Go to top

YAPM

Posted by: Jean-Daniel Gamache on September 27, 2004 in response to Message #139630
Yet another persistence model ;-)

  Message #139892 Post reply Post reply Post reply Go to top Go to top Go to top

Sun creates new Persistence API: EJB & JDO join forces

Posted by: Chris Perrin on September 27, 2004 in response to Message #139826
Also picked up by eWeek.Peace,Cameron PurdyTangosol, Inc.Coherence: Shared Memories for J2EE Clusters
Can I infer from this that the persistence API will do more than just persist to a database? Or am I giving Sun too much credit?

Because if all they're doing is creating another Hibernate competitor, they'll lose. Sun doesn't have enough mindshare to beat Hibernate. IBM does not on the O/R level, either.

That's my .02

  Message #139893 Post reply Post reply Post reply Go to top Go to top Go to top

PersistenceManager

Posted by: Chris Perrin on September 27, 2004 in response to Message #139832
Why not allow each of these vendors to plug their persistence framework in using some sort of PersistanceManager, and allow the user decide which of the numerous ORM frameworks to use based on requirements and technical fit, a'la web frameworks...Only asking...
Though I shudder at the thought of implementing such a creature, I think this is the way to go.

  Message #139894 Post reply Post reply Post reply Go to top Go to top Go to top

The seperate API

Posted by: Chris Perrin on September 27, 2004 in response to Message #139857
There currently isn't a name for this new spec/ri/tck, any suggestions?Dion
LongSleep--because it's a copy of Hibernate. Sorry, couldn't resist and before you flame me, yes I realize they're different.

How does everyone feel about Persistlets?

  Message #139898 Post reply Post reply Post reply Go to top Go to top Go to top

New name for new specification

Posted by: Keiron McCammon on September 27, 2004 in response to Message #139894
How about "YADO"...Yet Another Data Objects...sorry couldn't resist that either ;-)

 - Keiron

  Message #139899 Post reply Post reply Post reply Go to top Go to top Go to top

New name for new specification

Posted by: Erik Bengtson on September 27, 2004 in response to Message #139898
What about a sexy one?

PORM: Persistence O/R Mapping

  Message #139902 Post reply Post reply Post reply Go to top Go to top Go to top

Why Make the Change ?

Posted by: Vagif Verdi on September 27, 2004 in response to Message #139885
I searched during hours for articles telling me how cloudscape can compete versus mysql and postgresql but i haven't found
There's reason for that. It simply cannot :))

  Message #139903 Post reply Post reply Post reply Go to top Go to top Go to top

Names are relativ, but which concepts well be supported

Posted by: Matthias Kaiser on September 27, 2004 in response to Message #139815
Hi everyone,

I'm working a lot with JDO/Kodo and I think it's very good O/R-Mapper.
I also think that Hibernate is very nice.

So if you look at the early draft of the ejb3 spec than all persistence model of entity beans is similar to the one in JDO 1/2.

Then look at product like Kodo: It has a bunch of features and extensions which are necassary for O/R-Mapping in enterprise business. For example
- managed relations
- distributed cache integration
- attach/detach features (DTO stuff)
- distributed transactions

So the only question for me is how will the new persistence technology/API support all necessary features when its in J2SE ?

In my own opinion the JDO2 spec is /was? the right approach for persistence.
I hope the EJB export group will recognice the work of Russel/Jordan because they are doing a great job with JDO2

-Matthias

  Message #139905 Post reply Post reply Post reply Go to top Go to top Go to top

EJB & JDO join forces. Unequal marriage?

Posted by: Alex Roytman on September 27, 2004 in response to Message #139842
Hi all,

I usually do not post on political issues but I feel strongly about it. May be upcoming FAQ will resolve my fears but ...

We've been using JDO for years and heavily depend on it. JDO-2 is exciting new specs we were awaiting for long time.

Now, this combined EJB/JDO standard will not be out for long time. Meanwhile JDO-2 will be sort of a dead end for users. As history shows there is awful lot of politics going on in EJB work group. They have lots of big vendor muscles and always eager to squash what they do not like. So here we have JDO-2 specs and several compliant implementations out in 3-6 months and production deployed apps on JDO2 in another 6 months (at least who base all their development on JDO like us). Then EJB folks say they do not like it, and go on there own once again (remember their ugly exit from JDO JSR). Where will it leave JDO-2 and it adopters? Big EJB vendor’s goal does not seem to be 100% compatible with creation of powerful implementation of persistence which can do good deal of what EJB does. They would want persistence improved a bit to strengthen their EJB but up to a point (not too god - competition) - I am afraid it is a road to least common denominator persistence specs. And they have plenty of weight to do it

I feel with this unequal marriage JDO future will be far less secured then on its own. It can compete with EJB on its own merits now but given delays and confusion and need to accommodate EJB vision it might loose its momentum in the next 1-2 years

Thanks

Alex

  Message #139907 Post reply Post reply Post reply Go to top Go to top Go to top

What's wrong with Hibernate?

Posted by: Steve Zara on September 27, 2004 in response to Message #139816
I don't use Hibernate because, as I understand the situation, it does not scale well. I believe (from posts I have read) that Gavin King's approach is that Java should not be used for large-scale batch data processing - solutions such as PL/SQL are more appropriate. Well, I code large-scale data processing, and I use Java: I like to keep my code as portable as possible, and database independent. I find JDO works well with this, as I can use features such as fetch groups to optimise speed and memory usage. I also use some cache management features (admittedly non-standard extensions) to allow me to load and modify hundreds of thousands of objects within a single transaction (something that is not uncommon in large commercial applications).

I may be wrong about Hibernate's capabilities in this area, but it puts me off using a product when the developers specifically state it is inappropriate for the purpose I would like to use it for. As a contrast, when I had memory problems with large transactions with a commercial JDO implementation, this was treated as a bug and fixed.

  Message #139908 Post reply Post reply Post reply Go to top Go to top Go to top

EJB & JDO join forces. Unequal marriage?

Posted by: Matthias Kaiser on September 27, 2004 in response to Message #139905
Hi Alex,

I fully agree with you.

The persistence debate is no more than a politic issue.

Let's look a few months ago where the big ones (everybody knows which componies)
votes again the JDO2 spec becauce the had already implemented the EJB persistence model in their containers and didn't want to spent money for another API/model.

Now with the new "joined" forces of JDO/EJB the big ones will have to provide the new persistence API/Model if they want to participate on the market.

And I agree that JDO will be dead right now, because why should a company spend money an API that will replaces by another one in 2 years

From a technical point of view the JDO2 spec would really look like an object-orientated approch for persistence. And which better and more powerful features will the new API/modell provide, which JDO has not. Anybody ideas ?

So I think the JDO experts should not join the EJB group but the persistence(entity) experts of the EJB group should join JDO Group of Russel/Jordan

Thanks for reading

-Matthias

  Message #139909 Post reply Post reply Post reply Go to top Go to top Go to top

ahhh...what is wrong with JDBC?

Posted by: Michael McCutcheon on September 27, 2004 in response to Message #139630
Why the hell don't you people just use JDBC?

Just learn SQL and use PreparedStatements. I can teach it to an idiot in a few minutes.

You're 'ORM Persistence Frameworks' just make everything harder. You people seem to think there is something 'magical' about saving your data by putting it into POJO objects. Ahh:

PreparedStatement ps = con.prepareStatement("update xxx set y = ?, z = ?");
ps.setInt(1, 123);
ps.setInt(2, 456);
ps.executeUpdate();

Now what the hell is so hard about that? I don't need no stinking POJO objects or anything.

Get back to basics folks.

  Message #139910 Post reply Post reply Post reply Go to top Go to top Go to top

ahhh...what is wrong with JDBC?

Posted by: Konstantin Ignatyev on September 27, 2004 in response to Message #139909
Why the hell don't you people just use JDBC?Just learn SQL and use PreparedStatements. I can teach it to an idiot in a few minutes.
I could rely on raw PreparedStatements if they allowed named parameters... for the lovers of JDBC I suggest using iBatis, it really makes sense. Personally I found ORM (Hibernate and JDO) shine in some cases and much more convenient for use than iBatis and raw JDBC.
Just use right tool for the job, that is it.

IMO: if iBatis gets on the way and you 'need' raw JDBC then probably entire application should not be Java based, but DB specific stored procedures and batches.

  Message #139912 Post reply Post reply Post reply Go to top Go to top Go to top

A first move towards fixing EJBs

Posted by: Sean Broadley on September 27, 2004 in response to Message #139630
An app server should provide a framework into which I can clip services - not a one-size-fits-all straightjacket. For example, I should be able to take any standard-compliant O/R mapping tool and use it to load and save my Entity Beans, with any standards-compliant app server.

But the EJB spec has always taken a large set of things - persistence, resource pooling, network connectivity, transactional demarcation, O/R mapping - and had a vision that the app server would provide everything. Not a surprising view if it is the companies building app servers who dominate the spec - they want you to buy a big, expensive app server that slices, dices, does your windows, walks your dog, and does everything else too. They do not want to sell you a lightweight framework into which you clip their competitors services.

Hopefully the threat of JDO and Hibernate - and the reality that people are using the 'official' EJB solution of CMP less and less even though it has got a lot better - has finally pushed the app server vendors who dominate J2EE into doing something sensible.

Because the other option is that the forces which have been trying to simply kill JDO and replace it with CMP are finally succeeding - in which case non-standards-compliant solutions like Hibernate will just take over. Which would be a win for non-standards-compliant solutions (TopLink from Oracle, and CocoBase from Thought Inc), but a loss for java.


Sean

  Message #139913 Post reply Post reply Post reply Go to top Go to top Go to top

No optional semantic on the stantard.

Posted by: Rodrigo Kumpera on September 27, 2004 in response to Message #139630
EJB has many cases of optional features that changes semantic.

This is the most braindamaged idea one can put in a standard. No optional stuff should mean optional behavior.

Things like "On this given situation, the container can throw XxxException or XxxSubClassException" must be avoided as this only makes code less portable across implementations and more bug prone. As no one can reliably use the given feature, it should not be on the standard from the begining.

  Message #139914 Post reply Post reply Post reply Go to top Go to top Go to top

ahhh...what is wrong with JDBC?

Posted by: David McCoy on September 27, 2004 in response to Message #139909
Why the hell don't you people just use JDBC?Just learn SQL and use PreparedStatements. I can teach it to an idiot in a few minutes. You're 'ORM Persistence Frameworks' just make everything harder. You people seem to think there is something 'magical' about saving your data by putting it into POJO objects. Ahh:PreparedStatement ps = con.prepareStatement("update xxx set y = ?, z = ?");ps.setInt(1, 123);ps.setInt(2, 456);ps.executeUpdate();Now what the hell is so hard about that? I don't need no stinking POJO objects or anything.Get back to basics folks.
He's right. And while we are at it, let's also write code to draw our own windows. And code to read files. And write our own maps, list, etc.

Let's all go back to the basics and write everything from scratch.

Who's first for assembly?

  Message #139917 Post reply Post reply Post reply Go to top Go to top Go to top

What's wrong with Hibernate?

Posted by: Andrej Gabara on September 27, 2004 in response to Message #139816
Hibernate doesn't support remote clients [at least not well]

  Message #139918 Post reply Post reply Post reply Go to top Go to top Go to top

JDBC

Posted by: Robert Hayes on September 27, 2004 in response to Message #139909
JDBC is fine for small applications. For a large scale application with 50 tables you're looking at 4+ CRUD operations per table. That's 50 * 4 = 200 flippin' JDBC calls! Now, let's PRAY that you didn't hard code those into the client application. So you stick the JDBC into a DAO/DTO layer. Now you have about 200 DTOs to write unless you use some DDL/Mapping tool.

  Message #139920 Post reply Post reply Post reply Go to top Go to top Go to top

What's wrong with Hibernate?

Posted by: Konstantin Ignatyev on September 27, 2004 in response to Message #139820
Having a common Persistence API doesn't commit you to an implemenation persay, but allows you to proceed with confidence in a common API across J2SE and J2EE.
Hmm... Lets suppose an Order object has declared list of items as List getItems(). Now lets instantiate the object with Hibernate and try sending Order object via RMI? We will have RMI exception unless we put hibernate libraries on client.
That does not seem right and I tend to blame RMI for the issue (never ever such thing would happen in CORBA). My point is that having common ‘standard’ interfaces does not guarantee compatibility, implementation matters.

  Message #139921 Post reply Post reply Post reply Go to top Go to top Go to top

Stored procedure issue

Posted by: Code Manner on September 27, 2004 in response to Message #139630
May be Sun can provide a set of new API for calling stored procedure in database site, may be in something like EJBQL of JDOQL. So, it make the integration to legacy system that use stored procedure easier.

Thanks.

  Message #139924 Post reply Post reply Post reply Go to top Go to top Go to top

ahhh...what is wrong with JDBC?

Posted by: Rashid Jilani on September 27, 2004 in response to Message #139914
Why the hell don't you people just use JDBC?Just learn SQL and use PreparedStatements. I can teach it to an idiot in a few minutes. You're 'ORM Persistence Frameworks' just make everything harder. You people seem to think there is something 'magical' about saving your data by putting it into POJO objects. Ahh:PreparedStatement ps = con.prepareStatement("update xxx set y = ?, z = ?");ps.setInt(1, 123);ps.setInt(2, 456);ps.executeUpdate();Now what the hell is so hard about that? I don't need no stinking POJO objects or anything.Get back to basics folks.
He's right. And while we are at it, let's also write code to draw our own windows. And code to read files. And write our own maps, list, etc.Let's all go back to the basics and write everything from scratch.Who's first for assembly?
I have a more simpler solutin, why the hell people don't start using OO databses at all. I mean isn't it the most simnplest and the logical solution after all?

  Message #139925 Post reply Post reply Post reply Go to top Go to top Go to top

no amount of emergency procedures will help

Posted by: Rolf Tollerud on September 27, 2004 in response to Message #139630
Such innocence, such freshness, such unboundable optimism, they actually think that something useful will be coming forth from the committee!

One time I too was a fresh and innocent little boy. What happened then? That should I like to know. It is sad really. :(

The political forces that are in work to save the big theory/fantasy with poor implementation that is called EJB, and in the extension the J2EE Application servers, the biggest fiasco of all time in the IT world, are enormous.

It is funny to watch how vanity and prestige is the most powerful driving forces in the world.

Regards
Rolf Tollerud

  Message #139929 Post reply Post reply Post reply Go to top Go to top Go to top

Re: JDBC

Posted by: Amin Mansuri on September 27, 2004 in response to Message #139918
Though I don't disagree with you.. for the sake of fairness I'll reply...

Most CRUD operations are identical.. for example a lookup:

SELECT * FROM tablename WHERE primary key = value

(simplifying a bit.. pk could be harder..)

Using this template we can easily generate all possible statements for CRUD operations.. So, no, I only need 4 queries.. not 50*4. (I don't even need the dumb DAO classes.. instead I reuse code)

Have done this already.. not just making it up..

  Message #139933 Post reply Post reply Post reply Go to top Go to top Go to top

Why ORM can be nice..

Posted by: Dion Almaer on September 27, 2004 in response to Message #139909
Michael -

For simple apps this can be true. However, what if you work on a complex object model, and want to persist it?

Think about all of the persistence logic that you have to put in:

- When user.getOrders() returns an orders put in logic to do this lazily, or not
- Hmm what shall I eagerly load?
- Let's put in some type conversion code
- Smart caching
- etc etc etc

It turns out to be a lot of work. With a good ORM solution you can run with your object model and many performance tweaks can be done at configuration time. Also, you don't have to spend the time writing the mundane repeatative code. You just create objects, call business methods, and now and then you save/makePersistent/whatever.

If you have a trivial application that doesn't need all of this, then don't bother. Just use Ruby on Rails for it :)

Dion

  Message #139934 Post reply Post reply Post reply Go to top Go to top Go to top

JDBC

Posted by: Michael McCutcheon on September 27, 2004 in response to Message #139918
JDBC is fine for small applications. For a large scale application with 50 tables you're looking at 4+ CRUD operations per table. That's 50 * 4 = 200 flippin' JDBC calls! Now, let's PRAY that you didn't hard code those into the client application. So you stick the JDBC into a DAO/DTO layer. Now you have about 200 DTOs to write unless you use some DDL/Mapping tool.
I work on DoD apps. One of our databases has 1700+ tables, some with millions of rows of data in some. Our SQL is written by app developers, then 'tuned' by DBA SQL experts. We can't use some stupid API written for 'idiots' who don't want to learn SQL.

Most of these ORM 'solutions' are nothing but serious abuses of type safety and utilize reflection (or like API's) up the wazooi. Most of them don't generate SQL as optimized as hand written SQL.

It amazes me how far 'java' developers will go to avoid doing simple SQL and JDBC. It's like they believe that they can live in their 'dream' land where they don't have to know anything about relational database theory...instead they rely on these 'magical' tools to hide the 'ugly' database stuff from them.

I would never hire a Java developer who did not have a firm handle on relational database theory. The two skills go hand in hand.

  Message #139937 Post reply Post reply Post reply Go to top Go to top Go to top

Eventually, MS will have the last laugh

Posted by: tom tarb on September 27, 2004 in response to Message #139929
There is this thing called Money ($$)
Businesses have $$
Businesses always have data. The operations on the data tends to change.
Data is stored in databases. Therefore database vendors have influence on the $$.
App vendors want a piece of the $$ too. So they are trying to eliminate the db vendors. And on the fourth day, JDO/EJB/Entity/Hibernate/Migrate was born. And it was not good.

After JSP/Struts/Velocity/Tapestry/Jetty/JSF etc. etc. Java is moving to an ASP.NET like model with JSF

After all the muck with persistence, you will end up with ADO.NET.

Riddle me this: Who told Sun that they know how to write business systems? I mean think about it - all they've developed is Solaris and some sys tools. They know jack about db development. So come on!!!

PS: Try a lightweight ado.net style wrapper on jdbc. It makes db stuff a breeze. Also, in my apps, I combine several db statements into one larger statement that executes in one go and I get back multiple result sets. The speed is phenomenal. Try that in Hibernate.

  Message #139939 Post reply Post reply Post reply Go to top Go to top Go to top

What's wrong with Hibernate?

Posted by: Santosh Maskar on September 27, 2004 in response to Message #139820
Hibernate3.0 is the good solution for the OR mapping , why developer need to use JDO??

  Message #139940 Post reply Post reply Post reply Go to top Go to top Go to top

Why ORM can be nice..

Posted by: Michael McCutcheon on September 28, 2004 in response to Message #139933
Michael -For simple apps this can be true. However, what if you work on a complex object model, and want to persist it?Think about all of the persistence logic that you have to put in:- When user.getOrders() returns an orders put in logic to do this lazily, or not- Hmm what shall I eagerly load?- Let's put in some type conversion code- Smart caching- etc etc etcIt turns out to be a lot of work. With a good ORM solution you can run with your object model and many performance tweaks can be done at configuration time. Also, you don't have to spend the time writing the mundane repeatative code. You just create objects, call business methods, and now and then you save/makePersistent/whatever.If you have a trivial application that doesn't need all of this, then don't bother. Just use Ruby on Rails for it :)Dion
Your 'complex object model' does not always translate into what is in the database. The apps I work on the database is defined by DBA experts. They know nothing of Java and object oriented programming...and certainly nothing about ORM frameworks. Changing a column on a table almost requires an act of God. We can't just have some ORM tool 'spit' out a bunch of tables and have them implement it. Our database is utilized by many applications written in many languages...both procedural and object oriented...not just java applications. Java developers seem to think that the whole world revolves around them and their object model.

  Message #139941 Post reply Post reply Post reply Go to top Go to top Go to top

ORM doesn't mean "The tool churns out the DDL"

Posted by: Dion Almaer on September 28, 2004 in response to Message #139940
Michael -

I agree that in many situations the Java developer doesn't get to choose the relational model. That is fine. In fact, if you have good DBAs that is great!

The good ORM solutions out there understand this reality though, and allow you to map between your object model and relational one. They will even go as far as giving you a nice GUI so you can drag and drop your mappings if you want.

I personally RARELY use the ability for an ORM to "spit out" the tables. The only time I do this is when prototyping.

Give a recent, good, ORM solution a try and see if you like it. I think you will be pleasantly surprised.

Dion

  Message #139943 Post reply Post reply Post reply Go to top Go to top Go to top

Re: JDBC

Posted by: Cameron Purdy on September 28, 2004 in response to Message #139929
.. for example a lookup:

SELECT * FROM tablename WHERE primary key = value

[..]

Using this template we can easily generate all possible statements for CRUD operations..

Have done this already.. not just making it up..
Interesting. Any time I see someone write "SELECT *" from anything, I just mentally cross them off the list of people that I would ever trust with a keyboard.

Look, these days, you can't impress people by showing them stone knives and bear skins. Frankly, I like bear skins .. they're warm and soft and all that. But if you want to impress technology people, show them a better tool, or at least something shiny and bauble-like.

As for the "you can build any app with only four SQL statements" concept, it's really cute in an CRUDdy academic manner .. but it's not quite good enough to even get Rolf to make fun of it.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

  Message #139944 Post reply Post reply Post reply Go to top Go to top Go to top

Extraordinary.

Posted by: Chris Beams on September 28, 2004 in response to Message #139630
I'm inspired. In the midst of so much uncertainty on this topic over the last several years, it's extraordinary to see this kind of vision and leadership on the matter. Thank you Craig and Linda - to see your two specs put aside any differences and come together to consider this problem newly is *exactly* what's been needed in this area.

To the whole community - I request we each put aside any cynicism or resignation we have that a unified persistence API is possible, and engage in questions that will make a difference: Just how *do* we want to go about this? How do we create this in a way that it presents itself as an opportunity for developers, the enterprises that employ them, and the vendors in the market? Possibly most importantly in the short term - how do we approach this in a way that draws on and honors *all* the brilliant minds, projects and experience that are leading the ORM field - alienating noone, leaving noone behind?

Java's ability to reinvent itself - to recognize and powerfully deal with a failure - and to operate with one voice - is crucial to it's continued success. What's certain is that for all our brilliant developments, we'll make a few more stupid moves along the way. How quickly and efficiently we transform our blunders into breakthroughs is what will keep us winning the game and trusted by the industries we serve. In the matter of effective persistence and transactionality, we've begun just that kind of a transformation today.

- Chris

  Message #139945 Post reply Post reply Post reply Go to top Go to top Go to top

JDBC

Posted by: Toby Reyelts on September 28, 2004 in response to Message #139934
One of our databases has 1700+ tables
It sounds like you need to add a column and an index to one table and drop about 1500 other tables. Color me unimpressed.
some with millions of rows of data in some
Don't we all? Seriously, millions of rows in a table isn't exciting anymore.

  Message #139947 Post reply Post reply Post reply Go to top Go to top Go to top

Different strokes for different folks

Posted by: Toby Reyelts on September 28, 2004 in response to Message #139940
Your 'complex object model' does not always translate into what is in the database.
Michael, nobody is saying that an ORM is perfect for every job. If your application is primarily doing batch reporting and batch updating, it may be a very good fit for JDBC ala iBatis or Spring. I've worked on applications just like that myself. For example, a large number of financial apps and webapps fall into that category.

On the other hand, I think what you're missing is that there are applications that have far more complex logic and relationships than those of the previous type. For example, we have gigabytes of data in a relational database spread across hundreds of tables, our own custom database engines, our own custom spatial indices, and yet the domain logic is, by far, the most important and complex part of the application. For those types of apps, if you attempted to write the JDBC by hand, you would
 
a) have a well-performing product that you were never able to finish, or
b) have a sub-par, not-so-well performing product

What an ORM does is give you an intuitive API that you can use to map your domain model to a database schema of your choice and which performs well 95% of the time. You spend a little of your time tuning the last 5% of the database accesses. An ORM engine is not a replacement for good engineers. Rather, it's what a good engineer would write himself when confronted with a complex domain - if the tools weren't already easily accessible and well within his budget.

  Message #139950 Post reply Post reply Post reply Go to top Go to top Go to top

Eventually, MS will have the last laugh

Posted by: Rolf Tollerud on September 28, 2004 in response to Message #139937
Kart,

<blocquote>"Try a lightweight ado.net style wrapper on jdbc. It makes db stuff a breeze. Also, in my apps, I combine several db statements into one larger statement that executes in one go and I get back multiple result sets. The speed is phenomenal."</blocquote>

And when you combine ado.net with iBatis.NET, you have all that you ever need.

  Message #139951 Post reply Post reply Post reply Go to top Go to top Go to top

Changing APIs... MDA!

Posted by: Lofi Dewanto on September 28, 2004 in response to Message #139630
Now I really realize what the real value of MDA (Model Driven Architecture) or MDD (Model Driven Development) especially in Java -> Higher abstraction level than those persistance APIs!

If you use such a language like UML and you describe your business model in PIM (Platform Independent Model), you won't tie your application into specific APIs (PSM = Platform Specific Model). No dependency to JDO, EJB, Hibernate, J2EE, Spring, ... and not even POJO and Java :-)

I would say, all those APIs and specs (JDO, EJB, what so ever from the Java Community Process) should also offer UML Profile and MDA Cartridges to help us, normal developers to develop our applications. So, each Java specs. and APIs (JSR) must offer following:

1. RI
2. TCK
3. UML Profile and Cartridge for MDA/UML/XMI so we can generate the whole application just by using the profile.

With (3) we can regenerate our application in case that we need to use different or new APIs.

Folks, it's time that we should move higher in the abstraction level so we won't care about *how* we want to persist those objects (JDO, EJB, Hibernate, etc.). We just *want to persist* those objects and that's it!

Cheers,
Lofi.
OpenUSS - EJOSA

  Message #139952 Post reply Post reply Post reply Go to top Go to top Go to top

Changing APIs... MDA!

Posted by: Lofi Dewanto on September 28, 2004 in response to Message #139951
Additional infos ;-) ...

Different types of APIs for the same purpose are not only happening in persistance area or "business layer" in general. It also happens in "presentation layer" (JSP, XMLC, Struts, JSF, Swing, SWT, ...). A standardized UML Profile + Cartridge for *one* purpose will help us application developers a lot! Just change the cartridge to use another APIs, that's it.

For different kind of business and presentation layer implementations check out this manual:
http://prdownloads.sourceforge.net/ejosa/ejosa-revo2.1-doc.pdf?download

Cheers,
Lofi.

  Message #139955 Post reply Post reply Post reply Go to top Go to top Go to top

So what IS wrong with Hibernate?

Posted by: Sam Regh on September 28, 2004 in response to Message #139824
I Agree with Neill Robbins and I hope that somehow, with some good will and compatibility kit magic :-), Hibernate (4?) would be JSR compliant. I think more official support could meke Hibernate even greater.

  Message #139956 Post reply Post reply Post reply Go to top Go to top Go to top

Congratulations!

Posted by: Wilfred Springer on September 28, 2004 in response to Message #139630
This is great news. It prooves that within the JCP avoiding fragmentation still prevales over the not invented here syndrom. I vote to let Linda and Craig have the Nobel Peace Prize, or at least some JDC award. (At times I was affraid that the EJB/JDO clash would be the new holy war, replacing the Emacs/Vi war ( that Emacs clearly won.))

Good luck!

I'll be looking forward to the outcome.

  Message #139957 Post reply Post reply Post reply Go to top Go to top Go to top

Congratulations!

Posted by: Carlo Marchiori on September 28, 2004 in response to Message #139956
I join in the congratulations! It's a great day for java developers!

  Message #139960 Post reply Post reply Post reply Go to top Go to top Go to top

What's wrong with Hibernate?

Posted by: Tom Eugelink on September 28, 2004 in response to Message #139816
Just wondering.
Well, for one; I don't like it ;-)

IMHO persistency is something that an Object IS, not something that is done via its setters and getters. That interface is for usage.

  Message #139962 Post reply Post reply Post reply Go to top Go to top Go to top

JDO 2: dead end?

Posted by: Oliver Kamps on September 28, 2004 in response to Message #139905
Meanwhile JDO-2 will be sort of a dead end for users.
Hi,

I am quite convinced that JDO 2 will not become a dead end for its users: JDO vendors will be involved in defining the new API and will support it in their products in the future. I also believe that (JDO and non-JDO) vendors will be interested in providing a migration path from JDO to the new API and tools to support this migration.


Cheers,
Oliver

  Message #139964 Post reply Post reply Post reply Go to top Go to top Go to top

JDBC

Posted by: Juozas Baliuka on September 28, 2004 in response to Message #139934
Our SQL is written by app developers, then 'tuned' by DBA SQL experts. We can't use some stupid API written for 'idiots' who don't want to learn SQL.
Yes, "easy-of-use" is a very silly reason to use O/R mapping tool. There are more things to learn in O/R than in plain SQL. "easy-of-use" has side effect "hard to maintain and to tune", it is very fun to transform and integrate different object model too.( try google with "graph" "transformation" "model" keywords to find how it is "easy-of-use")

  Message #139968 Post reply Post reply Post reply Go to top Go to top Go to top

So what IS wrong with Hibernate?

Posted by: Emmanuel Bernard on September 28, 2004 in response to Message #139955
We are actually making Hibernate3 JSR-220 compliant.

  Message #139975 Post reply Post reply Post reply Go to top Go to top Go to top

Sun creates new Persistence API: EJB & JDO join forces

Posted by: Muhammad Mansoor on September 28, 2004 in response to Message #139630
Every one in Java creates their own [Persistance] Framework and their Parents.

  Message #139978 Post reply Post reply Post reply Go to top Go to top Go to top

So what IS wrong with Hibernate?

Posted by: Juergen Hoeller on September 28, 2004 in response to Message #139968
We are actually making Hibernate3 JSR-220 compliant.
Which means that Hibernate3 won't be out before early 2006 (the target date for JSR-220)? Oh my... ;-)

Juergen

  Message #139980 Post reply Post reply Post reply Go to top Go to top Go to top

Why Make the Change ?

Posted by: Mark Nuttall on September 28, 2004 in response to Message #139902
I searched during hours for articles telling me how cloudscape can compete versus mysql and postgresql but i haven't found
There's reason for that. It simply cannot :))
Doesn't have to. They operate in different spaces. (saw the smiley, but "Humor plays close to the big hot fire called truth ...")

  Message #139984 Post reply Post reply Post reply Go to top Go to top Go to top

Re: JDBC

Posted by: Marina Prikaschikova on September 28, 2004 in response to Message #139943
>As for the "you can build any app with only four SQL statements" concept, it's
>really cute in an CRUDdy academic manner .. but it's not quite good enough to
>even get Rolf to make fun of it.

Ok, but what OR mapping tools vendors are using for access to relational DB?
Are they still in DB libs world? :-)

Marina
http://www.servletsuite.com

  Message #139985 Post reply Post reply Post reply Go to top Go to top Go to top

What's wrong with Hibernate?

Posted by: Carfield Yim on September 28, 2004 in response to Message #139816
Just wondering.
I guess the main problem is it is not base on a spec. from JSR, from Sun's point of view

  Message #139988 Post reply Post reply Post reply Go to top Go to top Go to top

What's wrong with Hibernate?

Posted by: Mark Nuttall on September 28, 2004 in response to Message #139960
Just wondering.
Well, for one; I don't like it ;-)IMHO persistency is something that an Object IS, not something that is done via its setters and getters. That interface is for usage.
Hibernate doesn't need accessors to perform persistance.

But your point is well taken. But the problem is that RDBMSs are widely used and have to be dealt with. One day the pain will go away (fingers crossed).

  Message #139989 Post reply Post reply Post reply Go to top Go to top Go to top

I'm afraid I don't understand your comment.

Posted by: Patrick Carroll on September 28, 2004 in response to Message #139917
Forgive me, but I don't understand your comment.

If you mean remote in the EJB sense, the way we handle it where I work is to have a remoteable service layer with Hibernate stuff on the server.

This combination of EJBs and Hibernate works pretty well for us. Hence my original question.

  Message #139991 Post reply Post reply Post reply Go to top Go to top Go to top

ahhh...what is wrong with JDBC?

Posted by: Mark Nuttall on September 28, 2004 in response to Message #139909
Why the hell don't you people just use JDBC?Just learn SQL and use PreparedStatements.
We are. And one should learn. We just are defering the repeatable task to a tool. And when necessary, we aren't.
  I can teach it to an idiot in a few minutes. You're 'ORM Persistence Frameworks' just make everything harder.
Spend a little time on the history of Hibernate and you'll see that they've been there and done it your way. It might seem harder at first, but looking back it won't. This from experience. The same can be said for OOP. Many say it just makes things more difficult.

It is odd how many people come up with there own ORM solution after years of performing the same task again and again.
You people seem to think there is something 'magical' about saving your data by putting it into POJO objects.
Nope. Scientific maybe.
 I don't need no stinking POJO objects or anything.Get back to basics folks.
Well, maybe you don't. But I doubt it. Maybe need is too strong. Probably could use some.

  Message #139992 Post reply Post reply Post reply Go to top Go to top Go to top

My takeaway as well.

Posted by: Patrick Carroll on September 28, 2004 in response to Message #139985
Yes, that was pretty much my takeaway as well.

I guess that I wish the original open letter had mentioned some of the existing projects that other people have mentioned in this followup. As written it came across (to me, anyway) as Sun telling the rest of the world that it was going to step in and clean up all the mess others have generated. It felt, oh, I don't know, patronizing.

When we started using Hibernate on the project I work on, we actually wrapped it so we'd be able to swap in some other O/R mapping tool if Hibernate didn't work for us. As it turns out, Hibernate has worked so well for us that we've eliminated the wrapping. Between the remoteable service layer we implemented with EJBs, and Hibernate, we have a pretty good thing going.

That said, I see the value of a specification, so I have nothing but good wishes for the spec writers.

  Message #139993 Post reply Post reply Post reply Go to top Go to top Go to top

New name for new specification

Posted by: totototo totototo on September 28, 2004 in response to Message #139899
What about a sexy one? PORM: Persistence O/R Mapping
I'd rather call it POF, for Persistant Object Framework. Save your objects and... poof! :-D
(As a side note, I believe this was to be the name of EOF long, long time ago. No wonder NeXT changed the name!)

Sorry, couldn't resist...

  Message #139994 Post reply Post reply Post reply Go to top Go to top Go to top

What's wrong with Hibernate?

Posted by: Max Andersen on September 28, 2004 in response to Message #139907
These claims are not at all true.

1. Hibernate *can* be used for batch data processing, go see http://blog.hibernate.org/cgi-bin/blosxom.cgi/2004/08/27#batch

2. The Hibernate Team's advise is to *not* use Hibernate for this as there are better and more performant solutions available for this (like pl/sql, t-sql, etc.)

The issue raised by users regarding the batch processing always surrounds about Hibernate having a first-level cache associated with the session which ensures
persistent identity is equivalent to Java identity; but which some *thinks* prevent them for large scale data processing. This is not true, and Gavin's blog contains the technical details on how to utilize things like evict() and clear() to handle this session first-level cache.

And please be aware that JDO has the *exact* same "issues" with this per their spec!

section 5.4:
"Still, JDO implementations must manage the cache of JDO instances such that there is only one JDO instance associated with each JDO PersistenceManager representing the persistent state of each corresponding datastore object."

and section 5.5 explicitly states that a persistent-clean instance retains its association to the PM *after* the end of the transaction.

In short that means that in the following scenario:

Object x = pm.getObjectById(oid);
Object y = pm.getObjectById(oid);
x.setName("foo");

x and y will per default point to the *exact* same instance because of the 1st-level cache and according to the JDO spec it is absolutely illegal for the persistence manager to transparently evict x from the cache between lines 1 and 2, since that would voilate s5.4.

Thus according to spec the JDO implementation is not allowed to do what is supported in Hibernate to remove/evict entities from the session cache.

So, the fact that you are using JDO for this kind of proves that large scale batch processing is available in ORM solutions with even stronger limitations than Hibernate.

Regarding fetch groups and cache management Hibernate has very similar features and I can only suggest you to go read the Hibernate doc or even the book which will show you that Hibernate was *built* with the intention to provide a very high performant and scalable ORM solution.
I may be wrong about Hibernate's capabilities in this area, but it puts me off using a product when the developers specifically state it is inappropriate for the purpose I would like to use it for. As a contrast, when I had memory problems with large transactions with a commercial JDO implementation, this was treated as a bug and fixed.
Can only say that we have also fixed bugs regarding these issues - nothing different here. We will just not *lie* to people and say that Hibernate (or any other ORM for that matter) is the *best* solution for doing this stuff!

  Message #139996 Post reply Post reply Post reply Go to top Go to top Go to top

What's wrong with Hibernate?

Posted by: Max Andersen on September 28, 2004 in response to Message #139917
eh - I use that everyday, so I have a hard time understanding such a claim ;)

Could you elaborate on this ?

  Message #139997 Post reply Post reply Post reply Go to top Go to top Go to top

how to get a good laugh..

Posted by: Rolf Tollerud on September 28, 2004 in response to Message #139852
Ok, my fault. Still, I would love to be a fly on the wall observing a JSR 220 meeting with Gavin and the others! :)

Somebody who know how it is working out?

  Message #140000 Post reply Post reply Post reply Go to top Go to top Go to top

JDBC

Posted by: Mark Nuttall on September 28, 2004 in response to Message #139934
I work on DoD apps.
Well, that explains alot. Spent 8 years in the AF. 4 working with DoD contractors.
  One of our databases has 1700+ tables, some with millions of rows of data in some.
Ahh. Data. No wonder OO solutions are scary.
  Our SQL is written by app developers, then 'tuned' by DBA SQL experts. We can't use some stupid API written for 'idiots' who don't want to learn SQL.
Then you have the wrong idea about ORM tools. R = relational. One still has to know Relational theory and SQL 'cause that is persistance mechanism. We are just factoring it out of the app where it can be.
Most of these ORM 'solutions' are nothing but serious abuses of type safety and utilize reflection (or like API's) up the wazooi.
That is what you get when one has no control over the persistance repository. So Reflection is bad?
Most of them don't generate SQL as optimized as hand written SQL.
Oh, I'm sure some don't. But how much SQL needs to be optimized? And please read the Hibernate discussion on this.
It amazes me how far 'java' developers will go to avoid doing simple SQL and JDBC.
It amazes me how much work a JOBOL developer will do to just in case the have to optimize a query or two.
It's like they believe that they can live in their 'dream' land where they don't have to know anything about relational database theory...instead they rely on these 'magical' tools to hide the 'ugly' database stuff from them.
It might seem like that and the unitiated might believe that. But in reality it allows us to concentrate on the important stuff. Like the <1 percent of queries and code that doesn't perform well.
I would never hire a Java developer who did not have a firm handle on relational database theory. The two skills go hand in hand.
And you shouldn't if you use RDMBS. On the otherhand, I wouldn't hire a Java developer that, at least a junior/senion one, that doesn't explore and think outside the box.

  Message #140003 Post reply Post reply Post reply Go to top Go to top Go to top

What's wrong with Hibernate?

Posted by: Max Andersen on September 28, 2004 in response to Message #139960
Again, please explain the rationale behind that claim ?

You don't like hibernate to use getter/setters ? Then use the field access feature instead.

Are your point instead about wanting all your domain objects to know about their persistence, well then do that - and use hibernate for saving your objects;
Hibernate supports transparent persistence which by many is preferred (for a good reason!) but Hibernate does not prevent you to taint your POJO's with persistence logic - but that is *your* choice; Not something I would like a framework to dictate (like e.g. JDO 1.0 and CMP did)

  Message #140004 Post reply Post reply Post reply Go to top Go to top Go to top

Great news and kudos to Sun! Surprised by TSS reaction

Posted by: Kalyan Kolachala on September 28, 2004 in response to Message #139630
It is indeed great news. Sun deserves to be congratulated for undoing the damage done earlier by EJB3 group (and vendors protecting their interests).

I am however surprised by the reaction of a number of folks in TSS. I may yet to see one credible argument as to why we need separate persistence specs for J2SE and J2EE. By going for that ONE spec, Sun has done the community a huge favor. We all have preferences whether this spec should be closer to JDO or Hibernate - we would still be better off than where we are now no matter what the outcome. I suppose credit is also due to TSS (particularly Dion) and independent members of the EJB3 group for highlighting the damage to the Java community.

Cheers,
Kalyan

  Message #140007 Post reply Post reply Post reply Go to top Go to top Go to top

Why ORM can be nice..

Posted by: Mark Nuttall on September 28, 2004 in response to Message #139940
Our database is utilized by many applications written in many languages...both procedural and object oriented...not just java applications. Java developers seem to think that the whole world revolves around them and their object model.
On the one hand, this doesn't negate the usage of ORM. M=Mapping. As explained by others this can work with your situation.

Ahh. See, in Java an application is a collection of classes. And some of those need persistance, in different forms.

Unfortunately you have multiple applications accessing the same "datastore". While this seems like a good idea, it never is. But this decision is seldom in the correct hands. So the problem is not with ORM but an architectural one.

  Message #140018 Post reply Post reply Post reply Go to top Go to top Go to top

Why ORM can be nice..

Posted by: Alex V on September 28, 2004 in response to Message #140007
Mark,

No, multiple access routs is a reality, not
a (wrong/right) architectural desigion. In this case
database triggers and stored procedures around (instead)
direct DB access is the best solution. High level business
level logic may be better placed in middle Java/Net level,
but basic and mid-level data integrity has to be as close to
data itself as possible (in case of multiple assesors).

There is no firm way to separate complex data integrity (db-level)
from business rules (domain mid-tier), so in every case it will be
up to designers....

Have a nive day.

  Message #140021 Post reply Post reply Post reply Go to top Go to top Go to top

Why ORM can be nice..

Posted by: Mark Nuttall on September 28, 2004 in response to Message #140018
Mark,No, multiple access routs is a reality, not a (wrong/right) architectural desigion. In this casedatabase triggers and stored procedures around (instead)direct DB access is the best solution. High level businesslevel logic may be better placed in middle Java/Net level,but basic and mid-level data integrity has to be as close todata itself as possible (in case of multiple assesors).There is no firm way to separate complex data integrity (db-level) from business rules (domain mid-tier), so in every case it will beup to designers....Have a nive day.
And thus we continue to live in the IT dark ages. One day we will get to the age of enlightenment. :)

Alex, I agree that due to the nature of RDBMS some integrity has to be in the DB via triggers and indexes. But that doesn't mean multiple "applications" should access the same persistance store. And because they do doesn't mean they should. Yes, it is a reality. But so is poverty and war and ... . Even though it may never happen, we should work towards stomping out all pain and suffering. (By these comments, I don't mean to trivialize proverty and war and ... . It is just allegorical and might make Rolf smile.)

  Message #140026 Post reply Post reply Post reply Go to top Go to top Go to top

Great news and kudos to Sun! Surprised by TSS reaction

Posted by: Henrique Steckelberg on September 28, 2004 in response to Message #140004
I am more surprised by the group of developers which don't use a domain model in their systems. Not that they should use it, as it is not mandatory at all in many situations. But if you don't use it and you don't need it, then why are you posting against a tool that has nothing to do with what you do? ORM frameworks, as their name imply, are used to map your domain objects to a relational database. Now, some people use and need a domain model in their systems, and they need to persist domain objects to a relational database, and the best tool for that is usually a ORM framework. For anything else, use your good sense before applying such tool, for it may not be the best solution. It should be that simple, I really can't understand what the fuss is all about.

+1 to a single persistence API/standard.

Regards,
Henrique Steckelberg

  Message #140029 Post reply Post reply Post reply Go to top Go to top Go to top

So what IS wrong with Hibernate?

Posted by: Emmanuel Bernard on September 28, 2004 in response to Message #139978
We are actually making Hibernate3 JSR-220 compliant.
Which means that Hibernate3 won't be out before early 2006 (the target date for JSR-220)? Oh my... ;-)Juergen
We are implementing the early draft version of the specs.

  Message #140031 Post reply Post reply Post reply Go to top Go to top Go to top

What's wrong with Hibernate?

Posted by: Steve Zara on September 28, 2004 in response to Message #139994
Firstly, I did not say that Hibernate could not be used for batch processing; I said that the developers of Hibernate did not recommend this. So I don't! I use a JDO implementation where the vendor has worked with me to help tune my application and and their product so I could do batch processing.

>Thus according to spec the JDO implementation is not allowed to do what is
>supported in Hibernate to remove/evict entities from the session cache.

Not true. See PersistenceManager.evict(..) and PersistenceManager.evictAll(..) in the JDO API. There seems to be a lot of mutual misunderstanding between JDO and Hibernate people.

I agree that Hibernate will probably do what I want if I do some research into it. However, so will JDO (especially with the JDO2 extensions I am using). JDO is a multi-vendor standard. So why should I bother Hibernate?

  Message #140032 Post reply Post reply Post reply Go to top Go to top Go to top

So what IS wrong with Hibernate?

Posted by: Steve Zara on September 28, 2004 in response to Message #139968
We are actually making Hibernate3 JSR-220 compliant.
So EJB3, Hibernate3 and JDO will converge? That would be outstanding!

  Message #140033 Post reply Post reply Post reply Go to top Go to top Go to top

multiple access routes

Posted by: thoff thoff on September 28, 2004 in response to Message #140018
>No, multiple access routs is a reality, not
>a (wrong/right) architectural desigion

How could you possibly handle writes from
multiple sources?

  Message #140034 Post reply Post reply Post reply Go to top Go to top Go to top

Why ORM can be nice..

Posted by: Juozas Baliuka on September 28, 2004 in response to Message #140021
And thus we continue to live in the IT dark ages. One day we will get to the age of enlightenment. :)Alex, I agree that due to the nature of RDBMS some integrity has to be in the DB via triggers and indexes. But that doesn't mean multiple "applications" should access the same persistance store. And because they do doesn't mean they should. Yes, it is a reality. But so is poverty and war and ... . Even though it may never happen, we should work towards stomping out all pain and suffering. (By these comments, I don't mean to trivialize proverty and war and ... . It is just allegorical and might make Rolf smile.)
RDBMS is a very good technology for this reason. *All* integrity constraints and security has to be in the DB, JAVA Object graph is not a reason to polute system and to drop platform neutral features.

  Message #140037 Post reply Post reply Post reply Go to top Go to top Go to top

Please explain like to a 7 years old..

Posted by: Rolf Tollerud on September 28, 2004 in response to Message #140026
Henrique: "Now, some people use and need a domain model in their systems, and they need to persist domain objects to a relational database, and the best tool for that is usually a ORM framework."
But what do you need the domain model for? I could agree if you really do something with it for instance add 10% tax to all prices, but in the great majority of cases you don't do anything at all!

Lets forget about performance and having control over the SQL and compare a ORM solution to iBATIS. Say you have 1700 tables, with 10 of these you do some business operations, therefore these 10 are classes; the other 1690 tables are just mapped to Arraylists or Maps (for presentation with Velocity).

Looks what happens with the most common change, an additional field on the screen.

1) Add a column to the table in the DB.
2) Add the field to the form.

Finished. (You may have to add the field to INSERT and UPDATE too)

So not only have you been spared 1690 unnecessary classes in your code, but the turn-around for making a simple change is umpteen times faster. In short KISS. So what (on earth) advantage do you get from ORM?

Regards
Rolf Tollerud

  Message #140038 Post reply Post reply Post reply Go to top Go to top Go to top

multiple access routes

Posted by: Alex V on September 28, 2004 in response to Message #140033
>No, multiple access routs is a reality, not>a (wrong/right) architectural desigion |||| How could you possibly handle writes from multiple sources?
client transactions? server transactions? long transactions?
various locking? isolation level?

But, in fact, my initial point was:
in case of multiple access - gather main transactional code
close to data in, for example, stored procedures.

If it was your question - multiple DIRECT data acceess is bad
but possible - because of multiplication of transactional
code for data integrity.

Alex V.

  Message #140041 Post reply Post reply Post reply Go to top Go to top Go to top

Why ORM can be nice..

Posted by: Alex V on September 28, 2004 in response to Message #140034
And thus we continue to live in the IT dark ages. One day we will get to the age of enlightenment. :)Alex, I agree that due to the nature of RDBMS some integrity has to be in the DB via triggers and indexes. But that doesn't mean multiple "applications" should access the same persistance store. And because they do doesn't mean they should. Yes, it is a reality. But so is poverty and war and ... . Even though it may never happen, we should work towards stomping out all pain and suffering. (By these comments, I don't mean to trivialize proverty and war and ... . It is just allegorical and might make Rolf smile.)
RDBMS is a very good technology for this reason. *All* integrity constraints and security has to be in the DB, JAVA Object graph is not a reason to polute system and to drop platform neutral features.
Mark, I would agree with Juozas.

Data integrity (basic and mid-level) is more important than ever-changing
 business-dependant language-diversed mid-tier consideration.

  Message #140042 Post reply Post reply Post reply Go to top Go to top Go to top

P.S.

Posted by: Rolf Tollerud on September 28, 2004 in response to Message #140037
You don't even have to restart the application! (even if you change the SQL).

  Message #140043 Post reply Post reply Post reply Go to top Go to top Go to top

multiple access routes

Posted by: Juozas Baliuka on September 28, 2004 in response to Message #140038
>No, multiple access routs is a reality, not>a (wrong/right) architectural desigion |||| How could you possibly handle writes from multiple sources?
client transactions? server transactions? long transactions?various locking? isolation level?But, in fact, my initial point was:in case of multiple access - gather main transactional codeclose to data in, for example, stored procedures.If it was your question - multiple DIRECT data acceess is bad but possible - because of multiplication of transactional code for data integrity.Alex V.
Crap is not so bad thing for political reasons, it creates many jobs forintegrators it will let to have Next Big Thing to drop legacy JAVA toys and we will get a lot of money from it, it smells like a Year 2000 Problem (It is not a problem, it is money for us )

  Message #140046 Post reply Post reply Post reply Go to top Go to top Go to top

ahhh...what is wrong with JDBC?

Posted by: Steve Zara on September 28, 2004 in response to Message #139909
Why the hell don't you people just use JDBC?Just learn SQL and use PreparedStatements. I can teach it to an idiot in a few minutes. You're 'ORM Persistence Frameworks' just make everything harder.
There are many reasons why I don't use SQL and JDBC.

Firstly, I believe one of the greatest strengths of Java is portability - it is not tied down to a specific platform. When I develop I try to extend that philosophy to the database: I do all that I can to avoid tying my application to a particular database. Its my view that portability is a fundamental part of good programming practice, even if it means some loss of performance. JDO, or cross-platform persistence solutions like Hibernate, provide portability. SQL does not: consider the differences between Access, MySQL, Postgresql and Oracle for example. I let the persistence library handle the differences. Good persistence implementations know how to optimise the SQL they produce. This portability means I can develop applications using MySQL or PostgreSQL and deploy on Oracle if I choose with no code changes!

Secondly, I find that much of what is done with JDBC/SQL is effectively re-inventing object persistence anyway! Often rows are retrieved from a query and placed into POJOs for processing. The JDBC to do this is tedious compared with the minimal code required in JDO and Hibernate. In many cases, using object persistence systems is a *lot* easier than JDBC.

Thirdly, I like to apply the DRY (Don't Repeat Yourself) strategy in development. Good persistence solutions can produce schemas from classes or reverse-engineer existing tables to produce Java classes. There is a single point of change if the structure of the data changes. This is not the case with JDBC.

  Message #140050 Post reply Post reply Post reply Go to top Go to top Go to top

What's wrong with Hibernate?

Posted by: David Tinker on September 28, 2004 in response to Message #139994
Hi Max
JDO has the *exact* same "issues" with this per their spec!section ... only one JDO instance associated with each JDO PersistenceManager representing the persistent state of each corresponding datastore object."and section 5.5 explicitly states that a persistent-clean instance retains its association to the PM *after* the end of the transaction.
The implementation can keep soft or weak references to persistent clean instances in the local PM cache. Then if they are no longer referenced by the application (e.g. when reading and processing data in a batch job) they will be cleaned up. It does not matter if when they are referenced again there is a new instance as the application is not holding any existing references.

The JDO API does have methods to evict from the local PM cache. Versant Open Access (formerly JDO Genie) will change the reference type of an evicted instance to weak so it will be safely cleaned up on next gc.

Versant Open Access Manual - Cache Management

With JDO 1.0.1 the implementation does have to keep strong references to dirty instances. JDO 2 adds a PM.flush() API to flush SQL to the database enabling gc of even dirty instances in a big batch transaction. Many implementations have this as an extension today.
Thus according to spec the JDO implementation is not allowed to do what is supported in Hibernate to remove/evict entities from the session cache.
This is not true as I have explained above.

Cheers
David Tinker - http://www.versant.com

  Message #140057 Post reply Post reply Post reply Go to top Go to top Go to top

Please explain like to a 7 years old..

Posted by: Henrique Steckelberg on September 28, 2004 in response to Message #140037
But what do you need the domain model for?
See? If you don't even know what a domain model is for, why complain about a tool that is used with/for it? If you want to learn when/why use a domain model, I suggest you read Martin Fowler's Patterns for Enterprise Application Architecture, more specifically page 119 cites the when/why of it. Quoting the book: "If you have complicated and everchanging business rules involving validation, calculations and derivations, chances are that you'll want an object model to handle them."
I could agree if you really do something with it for instance add 10% tax to all prices, but in the great majority of cases you don't do anything at all!Lets forget about performance and having control over the SQL and compare a ORM solution to iBATIS. Say you have 1700 tables, with 10 of these you do some business operations, therefore these 10 are classes; the other 1690 tables are just mapped to Arraylists or Maps (for presentation with Velocity).Looks what happens with the most common change, an additional field on the screen.1) Add a column to the table in the DB.2) Add the field to the form.Finished. (You may have to add the field to INSERT and UPDATE too)So not only have you been spared 1690 unnecessary classes in your code, but the turn-around for making a simple change is umpteen times faster. In short KISS. So what (on earth) advantage do you get from ORM? RegardsRolf Tollerud
As I said before, it is ok if you don't need a domain model, as you example shows, it is the most common situation for simple CRUD applications. Just learn when to apply an object model, and only then worry about ORM, but if you don't need it, forget it. Plain simple, no fuss about it. But just because you or 90% of all developers don't need domain models, it doesn't mean there is no need at all for it. I am sure the 10% that need it and know how to use it are most grateful that ORM tools do exist.

Regards,
Henrique Steckelberg

  Message #140067 Post reply Post reply Post reply Go to top Go to top Go to top

Please explain like to a 7 years old..

Posted by: Shireesh Thanneru on September 28, 2004 in response to Message #140037
Rolf: First of all, I am sorry to say this but you just don't get it...you unnecessarily waste people's time...TSS should just ban you from posting. Dion, why can't we ban Rolf from TSS?

Anyway, coming to your post on 1690 + 10 tables: If you don't use the 1690 tables, you just don't map those tables...it's as simple as that (and that's what people do). You just map the tables that you need. It can be incremental too...you can add map the tables as you need them. It's not an all or nothing solution.

  Message #140070 Post reply Post reply Post reply Go to top Go to top Go to top

still don't understand

Posted by: Rolf Tollerud on September 28, 2004 in response to Message #140057
But Henrique,

What are the chances for that you need "complicated and everchanging business rules involving validation, calculations and derivations", on all 1700 tables?

And in this cases where you do, you can map any SQL to objects with iBATIS just as with ORM. The difference is that you don't do the unnecessary mapping in the 1690 cases...

Regards
Rolf Tollerud

  Message #140077 Post reply Post reply Post reply Go to top Go to top Go to top

Why ORM can be nice..

Posted by: Mark Nuttall on September 28, 2004 in response to Message #140034
RDBMS is a very good technology for this reason. *All* integrity constraints and security has to be in the DB,


And that is why I say it is bad. It HAS to be in the db. At least right now.

The issue is you and others see it as Data. I and others see it as Objects. Once someone starts talking the opposite thing it really is conversation over. We'll never see eye to eye. I really do see your point. I was once on that side of the fence. But after years of unmaintainable and difficult to change and expensive systems (no Rolf, I'm not using EJBs) I'm not anymore.
JAVA Object graph is not a reason to polute system and to drop platform neutral features.
Putting all the constraints in the DB doesn't make it platform neutral. Your RMDBS provider is now the platform.

  Message #140080 Post reply Post reply Post reply Go to top Go to top Go to top

in search of an honest person..

Posted by: Rolf Tollerud on September 28, 2004 in response to Message #140077
Mark,

I ask you this because in spite of our different opinions I see you as resonable and honest, so I ask you:

When you map classes in Hibernate or other ORM tool, do you only map the tables/queries that need "complicated and everchanging business rules involving validation, calculations and derivations", or do you map all on routine?

Thank you beforehand for your honest answer.

Regards
Rolf Tollerud

  Message #140081 Post reply Post reply Post reply Go to top Go to top Go to top

still don't understand

Posted by: Juozas Baliuka on September 28, 2004 in response to Message #140070
But Henrique,What are the chances for that you need "complicated and everchanging business rules involving validation, calculations and derivations", on all 1700 tables? And in this cases where you do, you can map any SQL to objects with iBATIS just as with ORM. The difference is that you don't do the unnecessary mapping in the 1690 cases...RegardsRolf Tollerud
Lame usage doe's not make ORM a bad tool. Hibernate have good features like projection, I like IBatis too. Mapping files is not a very big problem, garbage can be generated, I like Old Plain SQL in IBatis more than "easy-of-use".

  Message #140082 Post reply Post reply Post reply Go to top Go to top Go to top

Re: JDBC

Posted by: Cameron Purdy on September 28, 2004 in response to Message #139984
Ok, but what OR mapping tools vendors are using for access to relational DB?
Probably more than four hard-coded SQL statements ;-)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

  Message #140083 Post reply Post reply Post reply Go to top Go to top Go to top

still don't understand

Posted by: Mark Nuttall on September 28, 2004 in response to Message #140070
What are the chances you need 1700 tables?

What are the chanc