Sun creates new Persistence API: EJB & JDO join forces

Discussions

News: Sun creates new Persistence API: EJB & JDO join forces

  1. 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 Messages (218)

  2. 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.
  3. Why ONE?[ Go to top ]

    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
  4. Why ONE?[ Go to top ]

    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.
  5. Non-relationa data stores?[ Go to top ]

    I am a little confused about the stated purpose of the joint effort. The letter mentions both a new POJO persistence model and a single object/relational mapping facility. I sincerely hope that the resulting API does not assume that the data store is only a relational database. One attractive aspect to us of JDO is that (in its implementations) it allows a mapping to the data store which is not directly visible to the writer of business rules and which handles non-relational data stores.

    I have no experience with Hibernate. Could Hibernate, as proposed for EJB 3.0, accommodate non-relational databases?
  6. Non-relationa data stores?[ Go to top ]

    Could Hibernate, as proposed for EJB 3.0, accommodate non-relational databases?
    Both EJB3 and Hibernate focus on Relational persistence.
  7. Non-relational data stores?[ Go to top ]

    I am a little confused about the stated purpose of the joint effort. The letter mentions both a new POJO persistence model and a single object/relational mapping facility. I sincerely hope that the resulting API does not assume that the data store is only a relational database. One attractive aspect to us of JDO is that (in its implementations) it allows a mapping to the data store which is not directly visible to the writer of business rules and which handles non-relational data stores.I have no experience with Hibernate. Could Hibernate, as proposed for EJB 3.0, accommodate non-relational databases?
    The joint effort recognizes that a huge number of object persistence developers use relational databases as the backing store, and it is essential that their needs be satisfied with a standard mapping specification.

    However, we specifically will not require that a relational backing store be used with the persistence API. This allows vendors to supply implementations of the standard that support non-relational data stores. For example, the TCK for the new API will not have any tests for the "SQL query" methods, which are intended for users who want to get direct access to the underlying native query features.

    I expect that many implementations will support relational databases and other data stores such as object databases, mainframe data access APIs, XML data stores, LDAP data, etc.
  8. Non-relational data stores?[ Go to top ]

    I am a little confused about the stated purpose of the joint effort. The letter mentions both a new POJO persistence model and a single object/relational mapping facility. I sincerely hope that the resulting API does not assume that the data store is only a relational database. One attractive aspect to us of JDO is that (in its implementations) it allows a mapping to the data store which is not directly visible to the writer of business rules and which handles non-relational data stores.I have no experience with Hibernate. Could Hibernate, as proposed for EJB 3.0, accommodate non-relational databases?
    The joint effort recognizes that a huge number of object persistence developers use relational databases as the backing store, and it is essential that their needs be satisfied with a standard mapping specification.However, we specifically will not require that a relational backing store be used with the persistence API. This allows vendors to supply implementations of the standard that support non-relational data stores. For example, the TCK for the new API will not have any tests for the "SQL query" methods, which are intended for users who want to get direct access to the underlying native query features. I expect that many implementations will support relational databases and other data stores such as object databases, mainframe data access APIs, XML data stores, LDAP data, etc.
    what you are describing already exists and is called JDO. What's the reason to drop the JDO EG work and use the EJB 3.0 draft developed by a team with O/R mapping background?
  9. Non-relational data stores?[ Go to top ]

    what you are describing already exists and is called JDO. What's the reason to drop the JDO EG work and use the EJB 3.0 draft developed by a team with O/R mapping background?
    The JDO 2.0 work is not being dropped. It will complete, most likely before the JSR 220 work completes. The reason for defining a new persistence API has already been discussed.

    Craig
  10. Non-relational data stores?[ Go to top ]

    what you are describing already exists and is called JDO. What's the reason to drop the JDO EG work and use the EJB 3.0 draft developed by a team with O/R mapping background?
    The JDO 2.0 work is not being dropped. It will complete, most likely before the JSR 220 work completes. The reason for defining a new persistence API has already been discussed.Craig
    I will rephase: I don't mean JSR 243 (JDO 2.0) will be dropped, but opposite to that it will be soon released.

    I tried to ask: why not start the new API based on the JDO 2.0 work instead of the EJB 3.0 draft?
  11. Too late I think.[ Go to top ]

    Other already existing persistent frameworks are very good by this time and by time when JSR-220 is be released ... a bit late.
  12. Non-relational data stores?[ Go to top ]

    However, we specifically will not require that a relational backing store be used with the persistence API. This allows vendors to supply implementations of the standard that support non-relational data stores. For example, the TCK for the new API will not have any tests for the "SQL query" methods, which are intended for users who want to get direct access to the underlying native query features. I expect that many implementations will support relational databases and other data stores such as object databases, mainframe data access APIs, XML data stores, LDAP data, etc.
    1) Is it something wrong with SQL ? If it is possible implement JDOQL then it must be possible to implement SQL parser too. I am not expert for non-relational data stores, but I think vendors have strong motivation (money) to implement SQL and to support clients like MS Office, report generators and cool toys. I do not believe non-relational data store providers play stupid political games against industry standards and mature technologies with OOP stuff to lose money. Is it some cometition with RDBMS vendors fear or religion ?

    2) SQL support is too conservatyve, It must be good to add some interpolation stuff like ODBC/JDBC and escapes for metadata (not for query transformations).
  13. Entity Beans in EJB3???[ Go to top ]

    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
  14. 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
  15. What's wrong with Hibernate?[ Go to top ]

    Just wondering.
  16. What's wrong with Hibernate?[ Go to top ]

    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
  17. What's wrong with Hibernate?[ Go to top ]

    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.
  18. What's wrong with Hibernate?[ Go to top ]

    Hibernate3.0 is the good solution for the OR mapping , why developer need to use JDO??
  19. Implementation without Specification[ Go to top ]

    Any questions?
  20. 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).
  21. 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?
  22. 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.
  23. As I figured, it might be such an outcoming:
    The output of this JSR will be a purely interface based. It has 2 implemention mechanism: Server-side(J2EE based) and Stand-alone(J2SE based), it won't be different in client code, but when using in server-side sceniaro, it might need a bit of deploy work
    The requirement might differ a bit. If a PO define tag property like @transaction, @cluster..These property maybe allowed to be ignored by stand-alone implemention, but is mandatory to server-side implementation
  24. Meeting in the middle[ Go to top ]

    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
  25. Glad I was not eating or drinking when I read your post. :)
  26. What's wrong with Hibernate?[ Go to top ]

    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.
  27. What's wrong with Hibernate?[ Go to top ]

    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!
  28. What's wrong with Hibernate?[ Go to top ]

    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?
  29. What's wrong with Hibernate?[ Go to top ]

    So why should I bother Hibernate?
    Probably because Hibernate has more users than all the JDO vendors put together?
    Being on a small-userbase product puts you firmly on the bug-finding path...

    Large-scale vendor adoption has been one of the adoption barriers for JDO. None of the appserver vendors and none of the database vendors have really touched it... :-(

    -Nick
  30. What's wrong with Hibernate?[ Go to top ]

    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
  31. What's wrong with Hibernate?[ Go to top ]

    Ok, it seems i was too conclusive ;)

    But my message is the same - Hibernate has the exact same mechanisms to support batch operation; but we would never say it's the *best* way!

    And we will of course fix any issues/bugs that shows up (which we have always done - also for people having problems with batch operations).

    But we won't remove the 1st level cache which is the "issue" that people normally brings up since that simply does not make sense for the rest of the core. Basically the problems introduced by removing it outweighs the flexibility provided.....and this goes for every ORM not just Hibernate.
  32. What's wrong with Hibernate?[ Go to top ]

    But we won't remove the 1st level cache which is the "issue" that people normally brings up since that simply does not make sense for the rest of the core. Basically the problems introduced by removing it outweighs the flexibility provided.....and this goes for every ORM not just Hibernate.
    Actually it doesn't quite go for "every ORM". At least not to the same extent.

    In an approach where the object instantly notifies its owning PersistenceManager/Session when it becomes dirty, the PM/Session can be "smart" enough to allow clean objects to get GC'd in low-mem situations while holding on to dirty objects, without any manual user intervention. David Tinker alluded to this earlier. This allows products using enhancement and similar approaches to iterate vast amounts of data in a single transaction without the user having to explicitly say which objects can be safely dropped from L1 cache.

    In most reflection-based approaches, you don't know which objects are dirty until you do state comparisons on flush. So you have to hold hard refs to everything, unless the user explicitly tells you certain objects are OK to GC.

    In this case, enhancement provides an advantage that helps make memory management more transparent to the user. But of course in other cases, reflection may have advantages. I'm just making the point that a product's approach to persistence really can impact scalability significantly, or at least impact how easy it is to make your apps scalable.
  33. What's wrong with Hibernate?[ Go to top ]

    But we won't remove the 1st level cache which is the "issue" that people normally brings up since that simply does not make sense for the rest of the core. Basically the problems introduced by removing it outweighs the flexibility provided.....and this goes for every ORM not just Hibernate.
    Actually it doesn't quite go for "every ORM". At least not to the same extent.
    Please be aware that when I talk about the necessity for the object cache it is for providing that "in the scope of a single persistence context, persistent identity is equivalent to Java identity" - thus my claim about every ORM needs a 1st level cache had nothing to do with eviction.

    Eviction is a feature that any ORM can (and should) provide; and which we can see is both available in JDO and Hibernate.
    In an approach where the object instantly notifies its owning PersistenceManager/Session when it becomes dirty, the PM/Session can be "smart" enough to allow clean objects to get GC'd in low-mem situations while holding on to dirty objects, without any manual user intervention.
    Yes - that's correct.
      David Tinker alluded to this earlier. This allows products using enhancement and similar approaches to iterate vast amounts of data in a single transaction without the user having to explicitly say which objects can be safely dropped from L1 cache.In most reflection-based approaches, you don't know which objects are dirty until you do state comparisons on flush. So you have to hold hard refs to everything, unless the user explicitly tells you certain objects are OK to GC.
     In this case, enhancement provides an advantage that helps make memory management more transparent to the user. But of course in other cases, reflection may have advantages.
    I can't see why reflection-based (as hibernate) can't do the same state comparison; the only difference is that products that uses enhancement maybe can decide this in a more effective way - but I would for sure also be able to do similar stuff with a reflection-based tool because nothing prevents it for doing state comparison *during* a "unit-of-work".
    I'm just making the point that a product's approach to persistence really can impact scalability significantly, or at least impact how easy it is to make your apps scalable.
    Yes, and I'm totally agreeing with this; but no matter how much eviction features you have (wether it's automatic or not) - you do *need* a 1st level cache to provide the proper identity semantics, right ? (otherwise I would like to hear what you would do otherwise to ensure that ;)
  34. What's wrong with Hibernate?[ Go to top ]

    the only difference is that products that uses enhancement maybe can decide this in a more effective way - but I would for sure also be able to do similar stuff with a reflection-based tool because nothing prevents it for doing state comparison *during* a "unit-of-work".
    Yes, of course.
    I'm just making the point that a product's approach to persistence really can impact scalability significantly, or at least impact how easy it is to make your apps scalable.
    Yes, and I'm totally agreeing with this; but no matter how much eviction features you have (wether it's automatic or not) - you do *need* a 1st level cache to provide the proper identity semantics, right ?
    Yes; no argument from me! An L1 cache is critical.
  35. What's wrong with Hibernate?[ Go to top ]

    This allows products using enhancement and similar approaches to iterate vast amounts of data in a single transaction without the user having to explicitly say which objects can be safely dropped from L1 cache.In most reflection-based approaches, you don't know which objects are dirty until you do state comparisons on flush. So you have to hold hard refs to everything, unless the user explicitly tells you certain objects are OK to GC. In this case, enhancement provides an advantage that helps make memory management more transparent to the user. But of course in other cases, reflection may have advantages. I'm just making the point that a product's approach to persistence really can impact scalability significantly, or at least impact how easy it is to make your apps scalable.
    Does the enhancement approach also helps when objects are dettached, modified and attached again to the persistence manager to know wich objects are modified outside the control from the persistence manager?
  36. What's wrong with Hibernate?[ Go to top ]

    Does the enhancement approach also helps when objects are dettached, modified and attached again to the persistence manager to know wich objects are modified outside the control from the persistence manager?
    Yes, it can. If you aren't transferring the detached objects to a remote client, or can rely on the client having copies of the enhanced classes, the enhanced code can internally track which fields change and provide that info to the PM on re-attach. The nice thing about this is that you can avoid any DB hits for the clean objects. When you don't have the dirty info, you have to either assume all attached objects are dirty (requiring UPDATEs on flush), or load their state and do a state-compare (requiring SELECTs to get the current state for comparison).
  37. What's wrong with Hibernate?[ Go to top ]

    This allows products using enhancement and similar approaches to iterate vast amounts of data in a single transaction without the user having to explicitly say which objects can be safely dropped from L1 cache.In most reflection-based approaches, you don't know which objects are dirty until you do state comparisons on flush. So you have to hold hard refs to everything, unless the user explicitly tells you certain objects are OK to GC. In this case, enhancement provides an advantage that helps make memory management more transparent to the user. But of course in other cases, reflection may have advantages. I'm just making the point that a product's approach to persistence really can impact scalability significantly, or at least impact how easy it is to make your apps scalable.
    Does the enhancement approach also helps when objects are dettached, modified and attached again to the persistence manager to know wich objects are modified outside the control from the persistence manager?
    Probably it is not common in practice but class transformation can not solve some problems too, reflection based tool or scripting language can change object state and it will not be detected by transformed code. Do you use something more clever than replace field access instructions with method call to invoke callback ? It must be better to add this feature for reflection first and everybody will be happy, it must be not so hard to implement it in JVM level.
  38. What's wrong with Hibernate?[ Go to top ]

    Hibernate doesn't support remote clients [at least not well]
  39. 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.
  40. Sorry, I should not have been so blunt. Maybe I'm wrong. I see the following
    options to support remote clients with Hibernate, but neither makes me feel
    good about it.

    (1) Run Hibernate on the client and use RmiJdbc.

        Not very secure, anybody who gets access to the client can get access
        to the database and do any DML he wants.

    (2) Make Hibernate's SessionFactory and Session remotely accessible (at least
        indirectly with session beans as a remote access layer) and
        make your domain objects remotely accessible

        Every call to the domain objects is a remote call, so won't scale. The
        client accesses any object by its remote interface.
        
        Same performance problem as remotely accessing entity beans.

        IMHO the most elegant solution, but it probably won't perform well
        for most applications.

    (3) Serialize the object graph you get from a Hibernate query back to a
        remote client, make changes, then serialize back.

        Can't use lazy loading. The whole object graph has to be sent over at once.
        Also difficult to have fine-grained access control - someone could hack
        something to bypass privilege checks when accessing data.

        Not so easy to publish and open API.


    What I would want is an O/R framework that supports model (2) but has
    performance enhancements to make things fast enough, with fine grained
    security checks done server-side (smart proxies to cache state for remote
    objects, batching calls client-server and back, anything to reduce number
    of remote calls necessary).


    Patrick, Max, please let me know if I miss something. What do you mean with
    "remoteable service layer with Hibernate stuff on the server"? Serializing
    objects graphs between client and server?
  41. Andrej, are you looking for something like Kodo JDO's remote PersistenceManagers? Basically, you use PersistenceManagers exactly as you would locally, and they have a normal local object cache for performance, but all persistence operations take place on a remote server.

    JDO wasn't designed explicitly for remote PMs, but the API makes it possible to implement them efficiently. I expect that JSR 220 APIs will be similar.
  42. Well, not looking now, only keeping my eyes open :) Thank's for the info.
  43. A "hard", but a good way is to move access control stuff to RDBMS (it is designed for this use case too). It must be more "easy-of-use"
    than home-made RPC layer and it must be more secure too.
    Sorry, I should not have been so blunt. Maybe I'm wrong. I see the followingoptions to support remote clients with Hibernate, but neither makes me feelgood about it.(1) Run Hibernate on the client and use RmiJdbc. Not very secure, anybody who gets access to the client can get access to the database and do any DML he wants.(2) Make Hibernate's SessionFactory and Session remotely accessible (at least indirectly with session beans as a remote access layer) and make your domain objects remotely accessible Every call to the domain objects is a remote call, so won't scale. The client accesses any object by its remote interface. Same performance problem as remotely accessing entity beans. IMHO the most elegant solution, but it probably won't perform well for most applications.(3) Serialize the object graph you get from a Hibernate query back to a remote client, make changes, then serialize back. Can't use lazy loading. The whole object graph has to be sent over at once. Also difficult to have fine-grained access control - someone could hack something to bypass privilege checks when accessing data. Not so easy to publish and open API.What I would want is an O/R framework that supports model (2) but hasperformance enhancements to make things fast enough, with fine grainedsecurity checks done server-side (smart proxies to cache state for remoteobjects, batching calls client-server and back, anything to reduce numberof remote calls necessary).Patrick, Max, please let me know if I miss something. What do you mean with"remoteable service layer with Hibernate stuff on the server"? Serializingobjects graphs between client and server?
  44. What's wrong with Hibernate?[ Go to top ]

    eh - I use that everyday, so I have a hard time understanding such a claim ;)

    Could you elaborate on this ?
  45. What's wrong with Hibernate?[ Go to top ]

    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.
  46. What's wrong with Hibernate?[ Go to top ]

    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).
  47. What's wrong with Hibernate?[ Go to top ]

    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)
  48. What's wrong with Hibernate?[ Go to top ]

    Just wondering.
    I guess the main problem is it is not base on a spec. from JSR, from Sun's point of view
  49. My takeaway as well.[ Go to top ]

    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.
  50. Nothing for simple uses[ Go to top ]

    However if your database doesn't easily map to your logical objects then O/R mapping tools are essentially useless :-(
  51. 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.
  52. EJB & JDO join forces[ Go to top ]

    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!!!!!!
  53. 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.
  54. So what IS wrong with Hibernate?[ Go to top ]

    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?
  55. Standard Persistence API != Hibernate[ Go to top ]

    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
  56. Standard Persistence API != Hibernate[ Go to top ]

    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?
  57. This persistence API != All of EJB 3 :)[ Go to top ]

    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
  58. 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
  59. The seperate API[ Go to top ]

    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
  60. The seperate API[ Go to top ]

    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.
  61. The seperate API[ Go to top ]

    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?
  62. New name for new specification[ Go to top ]

    How about "YADO"...Yet Another Data Objects...sorry couldn't resist that either ;-)

     - Keiron
  63. New name for new specification[ Go to top ]

    What about a sexy one?

    PORM: Persistence O/R Mapping
  64. New name for new specification[ Go to top ]

    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...
  65. 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
  66. JSR-220 will deliver 2 specifications[ Go to top ]

    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.
  67. 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
  68. RE: JSR-220 will deliver 2 specifications[ Go to top ]

    We need the FAQ badly!
  69. 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
  70. 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
  71. Standard Persistence API != Hibernate[ Go to top ]

    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...
  72. PersistenceManager[ Go to top ]

    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.
  73. So what IS wrong with Hibernate?[ Go to top ]

    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
  74. So what IS wrong with Hibernate?[ Go to top ]

    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.
  75. So what IS wrong with Hibernate?[ Go to top ]

    We are actually making Hibernate3 JSR-220 compliant.
  76. So what IS wrong with Hibernate?[ Go to top ]

    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
  77. So what IS wrong with Hibernate?[ Go to top ]

    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.
  78. So what IS wrong with Hibernate?[ Go to top ]

    We are actually making Hibernate3 JSR-220 compliant.
    So EJB3, Hibernate3 and JDO will converge? That would be outstanding!
  79. Also picked up by eWeek.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  80. 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
  81. Excellent idea[ Go to top ]

    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.
  82. EJB & JDO join forces[ Go to top ]

    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)
  83. 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
  84. 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
  85. JDO 2: dead end?[ Go to top ]

    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
  86. right into the quagmire[ Go to top ]

    "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
  87. 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
  88. I feel misunderstood! :([ Go to top ]

    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..)
  89. right into the quagmire[ Go to top ]

    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
  90. how to get a good laugh..[ Go to top ]

    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?
  91. right into the quagmire[ Go to top ]

    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.-- Cedrichttp://beust.com/weblog
    This is one more proof that Rolf is most often speaking completely uninformed.
  92. Dorel,

    Thank you! BTW, why not raise the antes and spice up a little bit with a little sweep-stake? What odds do you give me that the expert group not will become a laughing stock (AGAIN) in 12 months?

    Regards
    Rolf Tollerud
  93. Absolutely huge.[ Go to top ]

    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.
  94. Why Make the Change ?[ Go to top ]

    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/
  95. Why Make the Change ?[ Go to top ]

    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 ?
  96. Why Make the Change ?[ Go to top ]

    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 :))
  97. Why Make the Change ?[ Go to top ]

    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 ...")
  98. 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....
  99. they never give up[ Go to top ]

    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.
  100. they never give up[ Go to top ]

    Todd! Do not be so grumpyEJB 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.
    lol

    I guess EJB does make me grumpy :)

    You are right. Enterprise Joke Beans ARE funny now that I think about it.

    Very interesting to hear everyone's opinions however. Mine is just a bit on the negative side.
  101. they never give up[ Go to top ]

    I know...I worked with it
    Thats not what I remember... you have worked with very little of it. Plent of talk about it though... :-)
  102. Just went to Javapolis last week and I went too see the JDO 2.0 & EJB 3.0 sessions. I really like the stuff in JDO 2.0.
    The information about the new common persistence API in EJB3.0 worried me: The API is is the old EJB entity API (but now greatly simplified through annotations) with EJBQL greatly expanded (basically almost the same as SQL). So basically they are not restarting from scratch but are trying to fix the old entity beans (in such a way that the old entity beans still work) by probably switching the underlying implementation (but not the API!) to something very close to Hibernate with some JDO stuff thrown in, and make it look simple through annotations.

    It is totally focussed on OR mapping as is clear from the query language. No thought was given to querying non-relational data stores. From the talk it was also clear that the expert group had not thought for one second yet how this would work outside of a EJB container.

    From the point of a JDO user this seems like a regression rather then a progression. I doubt also that the JDO members in the expert group have a lot to say. they are probably squashed by the big EJB server vendors and are there more for political correctness to give the outside world the illusion that this new api really is a common effort.

    I don't see the need for this new persistence API: JDO does everything and more that this new API will do:
    - it runs perfectly standalone
    - you can easily use it in a EJB server: either by using it like you would standalone (programmatic transactions) or by letting the container manage the transactions via the JCA API.
    - easily integrates with Spring so that Spring can declaratively manages the local JDO transactions. This is not possible with EJB since there global JTA transactions are used! Frankly I care much more about Spring then EJB because I think this is the future not EJB (not even EJB3.0)
    - let's me query non-relational data stores using the same API.

    One can question if sacrificing JDO to save entity beans is the right way to go. When Rod Johson in his the talk 'J2EE without EJB' at Javapolis asked how many people were still using entity beans only a few people (out of maybe 300 persons) raised their hands; so clearly people have left entity beans behind and either switched back to JDBC or switched to Hibernate or JDO. So why give up a good working thing like JDO which is actually being used to try to fix a broken thing like entity beans that nobody uses anymore. the answer is of course: politics. The EJB vendors recognized that entity beans were crap, that JDO works well but rather than give up entity beans and just stick with session beans (the only thing they should be doing anyway since the task of an app server is not persistence but transaction coordination), like little children they still wanted to be the winners and just hijacked JDO via the JCP by deciding that JDO 2.0 would the end of JDO and that they were the future of persistence and that they now finally after have tried many times already to get it right would now get it right and everybody should migrate to their API.

    The right to do would have been to drop entity beans and adopt JDO.

    I really feel that this has shown that the JCP is not the unbiased, vendor politics-free process we hoped it would be. I really would like to see JDO continue beyond JDO 2.0 and maybe the best place for this is not the JCP but outside of it. Maybe the best place for this would be in the form of an open source project. this would allow to experiment with new features before setting them in stone in the spec and avoid design by committee. The new Apache JDO project for the reference implementation would be a good place to start.

    Maybe we should start a poll on the server side about this? What do you (JDO) guys think about this?
  103. Hi,

    I'm not an expert on persistence APIs, but there does seem to be a common theme here with regards to the JCP process. What I see is a lot of standardisation too early. Why not let a number of solutions compete for mind share, and then after some time standardise on the best?

    This standards thing seems to create as many problems as it solves. I do not think that standards committees are the best place for inovation. They work much better when they act as a rubber stamp for solutions that have proven their worth in the real world.

    EJB 3.0 standardising on Hibernate sounded like a good thing to me. At least Hibernate has a proven track record. It appears that JDO also has a proven record. So mix both together and what do you end up with? Something unproven and untested just like EJB1.0, 1.1, 2.0, 2.1, JSF, the WS APIs etc.

    Surely there has got to be a better way?
  104. Just went to Javapolis last week and I went too see the JDO 2.0 &amp; EJB 3.0 sessions. I really like the stuff in JDO 2.0.The information about the new common persistence API in EJB3.0 worried me: The API is is the old EJB entity API (but now greatly simplified through annotations) with EJBQL greatly expanded (basically almost the same as SQL). So basically they are not restarting from scratch but are trying to fix the old entity beans (in such a way that the old entity beans still work) by probably switching the underlying implementation (but not the API!) to something very close to Hibernate with some JDO stuff thrown in, and make it look simple through annotations.It is totally focussed on OR mapping as is clear from the query language. No thought was given to querying non-relational data stores. From the talk it was also clear that the expert group had not thought for one second yet how this would work outside of a EJB container.From the point of a JDO user this seems like a regression rather then a progression. I doubt also that the JDO members in the expert group have a lot to say. they are probably squashed by the big EJB server vendors and are there more for political correctness to give the outside world the illusion that this new api really is a common effort.I don't see the need for this new persistence API: JDO does everything and more that this new API will do:- it runs perfectly standalone- you can easily use it in a EJB server: either by using it like you would standalone (programmatic transactions) or by letting the container manage the transactions via the JCA API.- easily integrates with Spring so that Spring can declaratively manages the local JDO transactions. This is not possible with EJB since there global JTA transactions are used! Frankly I care much more about Spring then EJB because I think this is the future not EJB (not even EJB3.0)- let's me query non-relational data stores using the same API.One can question if sacrificing JDO to save entity beans is the right way to go. When Rod Johson in his the talk 'J2EE without EJB' at Javapolis asked how many people were still using entity beans only a few people (out of maybe 300 persons) raised their hands; so clearly people have left entity beans behind and either switched back to JDBC or switched to Hibernate or JDO. So why give up a good working thing like JDO which is actually being used to try to fix a broken thing like entity beans that nobody uses anymore. the answer is of course: politics. The EJB vendors recognized that entity beans were crap, that JDO works well but rather than give up entity beans and just stick with session beans (the only thing they should be doing anyway since the task of an app server is not persistence but transaction coordination), like little children they still wanted to be the winners and just hijacked JDO via the JCP by deciding that JDO 2.0 would the end of JDO and that they were the future of persistence and that they now finally after have tried many times already to get it right would now get it right and everybody should migrate to their API.The right to do would have been to drop entity beans and adopt JDO.I really feel that this has shown that the JCP is not the unbiased, vendor politics-free process we hoped it would be. I really would like to see JDO continue beyond JDO 2.0 and maybe the best place for this is not the JCP but outside of it. Maybe the best place for this would be in the form of an open source project. this would allow to experiment with new features before setting them in stone in the spec and avoid design by committee. The new Apache JDO project for the reference implementation would be a good place to start.Maybe we should start a poll on the server side about this? What do you (JDO) guys think about this?

    Well put Steven. As a happy JDO user I am as worried about what I see in EJB3 as you are. It really seems as if a technically fantastic spec in JDO2 is being superceded by yet another attempt to fix Entity Beans. You would think that at least in the technology industry, better technology would win over politics! :-(
  105. Guarded optimisim![ Go to top ]

    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
  106. YAPM[ Go to top ]

    Yet another persistence model ;-)
  107. ahhh...what is wrong with JDBC?[ Go to top ]

    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.
  108. 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.
  109. ahhh...what is wrong with JDBC?[ Go to top ]

    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.
    Caching, you get it for free with iBatis SqlMaps
    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.
    I couldn't agree more. If you are used to using JDBC, just stop and start using iBatis SqlMaps. There is very little learning curve because you are basically doing the same thing. You get to move your SQL statements out of your code, but like I said above, you get a decent caching mechanism, with the ability to flush on an interval or when another query is executed.
  110. ahhh...what is wrong with JDBC?[ Go to top ]

    Yes, iBATIS is vastly superior. With ORM, using the example above, after mapping all 1700 tables to classes, (1690 unnecessary) you have an application that has a 2-3 times as big code base, that is slower, where you have lost control over your SQL and where you have to recompile and restart after the slightest change. But not only that,

    In comes the caching, and now things are getting really complicated..

    The story goes on.

    Regards
    Rolf Tollerud
  111. ahhh...what is wrong with JDBC?[ Go to top ]

    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?
  112. ahhh...what is wrong with JDBC?[ Go to top ]

    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?
  113. JDBC[ Go to top ]

    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.
  114. Re: JDBC[ Go to top ]

    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..
  115. Eventually, MS will have the last laugh[ Go to top ]

    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.
  116. Eventually, MS will have the last laugh[ Go to top ]

    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.
  117. ADO.NET == JDBC, ObjectSpaces == JDO[ Go to top ]

    After all the muck with persistence, you will end up with ADO.NET.
    ADO.NET is most similar to JDBC, an object-oriented view of relational database artifacts, like Statement, ResultSet, etc.

    JDO is not like ADO.NET; it lets you define an object model of your domain and then map it to a datastore (relational or not). Microsoft's entry into this space is called ObjectSpaces, which has now been folded into WinFS and is supposed to be released after Longhorn. I don't know the timetables at all, but I don't think this is great news for MS folks who want to pursue transparent persistence. Hibernate.NET might be a good option in the future, however.

    --matthew
  118. read, understand, then post[ Go to top ]

    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.
    Sure it's called JDBC batch API, which by the way is usable from within Hibernate. Next...

    ADO.net is great for de-typed systems and simple general CRUD apps. It breaks down as soon as you start talking about complex systems (complex != large).
  119. read, understand, then post[ Go to top ]

    Oh thank heaven! I am so grateful that you got me this information in last minute. I were just going to use ADO.NET in a large application!

    Then again, a thousands thanks!

    Regards
    Rolf Tollerud
    (that could have been a disaster! :)
  120. yes[ Go to top ]

    Glad I could help. Good thing I jumped on. I should have realized you are also an ADO.net fan :)
  121. g[ Go to top ]

    ADO.net is great for de-typed systems and simple general CRUD apps. It breaks down as soon as you start talking about complex systems (complex != large).
    I should further qualify this...

    It starts to break down unless you buy into the notion of the full proprietory stack. .Net's usual approach to this is to use stored procedures and other in-db features. Again, this is a somewhat valid approach as long as you only ever need to run your app against one db and will never ever move away from that db.

    The other main place where it starts to break down is when you have fluid schemas.
  122. why?[ Go to top ]

    I loved your old header ("read, understand, then post"), why did you changed it? But then, with afterthought, I can understand why..:)

    Best regards
    Rolf Tollerud
    (ado.net & iBATIS user)
  123. Re: JDBC[ Go to top ]

    .. 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
  124. Re: JDBC[ Go to top ]

    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
  125. Re: JDBC[ Go to top ]

    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
  126. Re: JDBC[ Go to top ]

    what if your going to use every column from the table?
  127. Re: JDBC[ Go to top ]

    I guess i should have quoted.
    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.
  128. Re: JDBC[ Go to top ]

    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.
    what if your going to use every column from the table?
    Then you select every column, by its name. Using "select *" to get data is a good way to build code that is guaranteed to eventually break. (IMHO, etc.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  129. JDBC[ Go to top ]

    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.
  130. JDBC[ Go to top ]

    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.
  131. JDBC[ Go to top ]

    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")
  132. JDBC[ Go to top ]

    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.
  133. JDBC[ Go to top ]

    Most of them don't generate SQL as optimized as hand written SQL.
    Don't sell the JDO implementations short here. This is one of the areas where implementations differentiate themselves, on the quality of the SQL they generate. Their business is based in part on the quality of their SQL and the resulant performance. I think you'd be surprised at how well generated can do.
    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.
    It is not reasonable to expect to utilize any OR mapping product well without knowing anything about relational database theory. I agree that a solid background in relational databases will only serve to help.

    --matthew
  134. JDBC[ Go to top ]

    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.
    We have a system with 750 tables and also quite a lot of data and have a similar opinion: all java developers must have good SQL knowledge and understand both 'worlds'. It is an illusion to write good software by shielding the java deveropers from the DB. Data exists much longer than programs (at least in our banking world) and the data model is the heart of the system. SQL currently is the only way to have efficient and stable (technology independant) access to data, whether it be from java, cobol, reporting tools or whatever.

    We are considering hibernate to solve some of the more tedious parts where no high data volumes are required, only because it is so flexible and doesn't force you into a specific paradigm (we'll design DB and java and connect them through the xml mapping definitions, and absolutely won't generate DB from java or java from DB).

    Until now we've fared well by using SQL in a self written template system where you can fill in named parameters and generate larger queries form parts of queries etc. I think it is a bit similar to iBATIS of which existence I just learned.

    Projects here which have a strict separation between the java guys and the database guys suffer from bloat, confusion (both worlds need to understand each other) and so much encapsulation layers (first in the DB then 3 times more in some of the java tiers) that noone knows exactly what is going on.
  135. JDBC[ Go to top ]

    I feel the same that it is an illusion to write good software by shielding the java deveropers from the DB.

    I used Hibernate for a while, and I took a lot of time to try to understand how to map and code for better performance.

    Besides, anybody uses Hibernate generate reports or do OLAP stuff, it's nothing but awkward.

    I used ASP.net with stored procedure, quite efficient and work done. I didn't see the necessity of using ObjectSpaces kind of stuff.
  136. JDBC[ Go to top ]

    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.

    Not only should you probe for relational calculus, but also pretty much everything that is taught in CS school when interviewing or hiring solid programmers (algorithms, data structures, system architecture, OO design, functional languages, whatever may suit your purpose).

    I'll be bold and bet you have not even considered using any type of ORM solution, and you dismiss them right off the bat (based on what you said). This, IMHO, is sort of sad and inappropriate. If you look at Hibernate, or iBatis (my favorites)- both let you do your own SQL, should you choose to.. And nowhere in there does it say you are precluded from knowing relational theory by virtue of using ORM...

    ORM's _can_ be good at generating SQL (not necessarily db schemas though), if not as good as manually written SQL, given a schema.. As a matter of fact, Gavin King had announced a contest for a 100 dollars or so, if someone could actually generate more optimal SQL than what Hibernate does, once you give it the correct mappings for your db schema.

    ORM also relievies you of the true 'plumbing' work you have to do when doing JDBC. Take for example some app that uses JDBC only... If coded right, the DAO layer of the application will be a repetitive pattern of setting up connections/prepated statements or some such thing, executeQuery() and getting results back out... the plumbing code is the stuff that is the pattern across all these methods. The different parts is where the M in OR comes in - taking what is in the maps and the db rows, and bridging that gap as best or as 'natural' as possible when you combine these two not so compatible worlds (OO & RDBMS).

    This is where ORM shines, not in replacing your knowledge of relational databases... If you ignore relational db theory, one way or another, it will come back to bite you in the ass. ORM was only meant to serve as a _bridge_ between the relational and the OO world.... not to conceal or diminish or ignore it.
  137. JDBC[ Go to top ]

    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.


    I am 200% agree with you. The Persistent layer like JDO, EJB POHO all is just hype. Use Pure SQL simple (Small project/Big project), it works efficiently for all.
  138. Why ORM can be nice..[ Go to top ]

    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
  139. Why ORM can be nice..[ Go to top ]

    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.
  140. 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
  141. 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.
  142. Why ORM can be nice..[ Go to top ]

    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.
  143. Why ORM can be nice..[ Go to top ]

    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.
  144. Why ORM can be nice..[ Go to top ]

    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.)
  145. Why ORM can be nice..[ Go to top ]

    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.
  146. Why ORM can be nice..[ Go to top ]

    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.
  147. Why ORM can be nice..[ Go to top ]

    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.
  148. in search of an honest person..[ Go to top ]

    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
  149. in search of an honest person..[ Go to top ]

    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.RegardsRolf Tollerud
    I usually map 99% because I work (or want to) in an object world. And most domain objects end up mapping to more than on view. By view I mean List, Table, collection of fields (text, drop down, etc), Reports, JUnit tests, "batch" jobs.

    I did this with some VB code a few years back. After putting my code in domain objects for the Application, I saw the the user was cutting and pasting from the application to Excel. I was able to quickly add reference to the dll and minimize her effort greatly.

    Sometimes I don't use ORM at all. It is usually throw away code.
  150. found one[ Go to top ]

    Thank you Mark. I knew you would be honest! :)

    "What are the chances you need 1700 tables?"

    That was just arbitrary because someone mentioned that number earlier and besides in another thread it was said that Hibernate really shines with a large number of tables.

    "What are the chances 1 form (have only one view) will map to 1 table?"

    My example works equally well when you have more tables(views) on the form, you still can add a(some) column(s) to the DB, change the SQL in the XML-map and add one or more fields to the form without restart with IBATIS.

    Regards
    Rolf Tollerud
  151. multiple access routes[ Go to top ]

    No, multiple access routs is a reality, not
    >a (wrong/right) architectural desigion

    How could you possibly handle writes from
    multiple sources?
  152. multiple access routes[ Go to top ]

    >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.
  153. multiple access routes[ Go to top ]

    >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 )
  154. ahhh...what is wrong with JDBC?[ Go to top ]

    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.
  155. ahhh...what is wrong with JDBC?[ Go to top ]

    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.
  156. ahhh...what is wrong with JDBC?[ Go to top ]

    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.
    You must be kidding. Right?
  157. Writing all SQL statements explicit can be a little bit time-consuming. But of course, using EJB usually are much more time-consuming. But there are ways of increasing developer efficency. An object model on top of JDBC (like http://butler.sourceforge.net) will speed up development time. The key thing is not trying to hide the fact that you are working with a relational database, like JDO and EJB.
  158. ahhh...what is wrong with JDBC?[ Go to top ]

    The key thing is not trying to hide the fact that you are working with a relational database, like JDO and EJB.
    Unless of course, one is like me and hopes that one day we can move on to something the matches our development language. But until the biggest supporters of Java are not RDBMS venders ... .
  159. Not stupid. Just lazy.[ Go to top ]

    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.
    Michael,

    Anyone competent at writing serious enterprise applications, including those using ORM, already knows SQL. And not just the simple SQL syntax you can teach in a few minutes, because understanding how to design a data model for good performance for a complex OO system is bloody hard. So don't pretend that people want to use ORMs because they're stupid or ignorant of SQL.

    I like ORM not because I'm stupid, but because I'm lazy. Lazy is _good_. Every line of code I write increases the chance of bugs in my system, and increases the maintenance burden I leave behind. ORM is designed to do things for me so as to make for less code (= easier maintenance and less bugs).

    Sean
  160. A first move towards fixing EJBs[ Go to top ]

    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
  161. No optional semantic on the stantard.[ Go to top ]

    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.
  162. Stored procedure issue[ Go to top ]

    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.
  163. Stored procedure issue[ Go to top ]

    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.


    You don't need a special API to access stored procedures from Java.

    FireStorm/DAO can import a database schema/stored procedures and generate data access objects based on JBDC DAOs, EJB CMP, JDO, or Hibernate.


    PJ Murray

    CodeFutures Software

    Java Code Generation for Data Persistence
  164. 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
  165. Extraordinary.[ Go to top ]

    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
  166. Extraordinary.[ Go to top ]

    As usual, Chris, very well said, and I agree completely.

    No one likes to admit their mistakes, but admission leads to betterment. I, for one expert group member, am looking forward to working on this together. Whether it's JDO, EJB 3.0 POJO entity beans, Hibernate, or the next persistence API, I'm excited about what it enables: the return to the pursuit of true object orientation. Only this time around, we have the benefits of learning from the experiences of multiple- vs. single-inheritance, aspect orientation, and service orientation.

    I think we are on the verge of incredible advancement in our industry.

    Optimistically,
    Matthew
  167. Changing APIs... MDA![ Go to top ]

    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
  168. Changing APIs... MDA![ Go to top ]

    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.
  169. Congratulations![ Go to top ]

    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.
  170. Congratulations![ Go to top ]

    I join in the congratulations! It's a great day for java developers!
  171. Every one in Java creates their own [Persistance] Framework and their Parents.
  172. 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
  173. 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
  174. 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
  175. P.S.[ Go to top ]

    You don't even have to restart the application! (even if you change the SQL).
  176. 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
  177. still don't understand[ Go to top ]

    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
  178. still don't understand[ Go to top ]

    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".
  179. still don't understand[ Go to top ]

    What are the chances you need 1700 tables?

    What are the chances 1 form (have only one view) will map to 1 table? Always. Is anyone here doing OOP? MVC?
  180. still don't understand[ Go to top ]

    What are the chances you need 1700 tables?What are the chances 1 form (have only one view) will map to 1 table? Always. Is anyone here doing OOP? MVC?
    Some people design databases for business data and transactions, this stuff can have more than HTML generator, login form and table for "user" object in some cases.
  181. still don't understand[ Go to top ]

    What are the chances you need 1700 tables?What are the chances 1 form (have only one view) will map to 1 table? Always. Is anyone here doing OOP? MVC?
    Some people design databases for business data and transactions, this stuff can have more than HTML generator, login form and table for "user" object in some cases.


    ???
  182. still don't understand[ Go to top ]

    But Henrique,What are the chances for that you need "complicated and everchanging business rules involving validation, calculations and derivations", on all 1700 tables?
    No one is telling you that you should "use domain model on all 1700 tables" (!?!?), in case you didn't notice it... :) Use it where it fits best, but if it doesn't fit anywhere or if you have another solution you're more confortable with, dont use it! Simple! Should I repeat it again?
    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
    Nice that you know about one of the many great Object to Relational Mapping tools... :) Last time I checked it, though, you still had to map your objects (domain or not) to the DB in a XML config file, similar to other ORM tools like it.

    Regards,
    Henrique Steckelberg
  183. still don't understand[ Go to top ]

    As I know from practice 1700 table databases are common in goverment, table per input form and report with duplicated stuff. Databases in business are not so complex, business can not have complex process, structures and products (It is hard to sell complex things) and modeling, database design is used to optimize and to solve this problem.
  184. still don't understand[ Go to top ]

    As I know from practice 1700 table databases are common in goverment, table per input form and report with duplicated stuff. Databases in business are not so complex, business can not have complex process, structures and products (It is hard to sell complex things) and modeling, database design is used to optimize and to solve this problem.
    Yeah. Business can afford to be screwed up. :P
  185. still don't understand[ Go to top ]

    As I know from practice 1700 table databases are common in goverment, table per input form and report with duplicated stuff. Databases in business are not so complex, business can not have complex process, structures and products (It is hard to sell complex things) and modeling, database design is used to optimize and to solve this problem.
    Yeah. Business can afford to be screwed up. :P
    Can't.
  186. still don't understand[ Go to top ]

    As I know from practice 1700 table databases are common in goverment, table per input form and report with duplicated stuff. Databases in business are not so complex, business can not have complex process, structures and products (It is hard to sell complex things) and modeling, database design is used to optimize and to solve this problem.
    I work with Telecom systems, and I can assure you this business is full of complex processes, structures and products... No simple modeling and database design can optimize or solve it.
  187. still don't understand[ Go to top ]

    I work with Telecom systems, and I can assure you this business is full of complex processes, structures and products... No simple modeling and database design can optimize or solve it.
    I am not expert in Telecom systems, but probably there is more log file processing stuff, C programs and shell scripting than databases, it must not be a very big problem to lose transaction (connection) too. Is this complex stuff with many tables is used for billing ?
  188. still don't understand[ Go to top ]

    I work with Telecom systems, and I can assure you this business is full of complex processes, structures and products... No simple modeling and database design can optimize or solve it.
    I am not expert in Telecom systems, but probably there is more log file processing stuff, C programs and shell scripting than databases, it must not be a very big problem to lose transaction (connection) too. Is this complex stuff with many tables is used for billing ?
    I work with network management systems, not billing, but from what I have seen around here during these 10 years, there are >50.000 LOC C and C++ programs, huge billing file processing jobs, 25 years old mainframe systems, big Sqlserver and paralel clustered Oracle databases, MS Access (ugh!), 100s of web apps in ASP & JSP, Java, J2EE, shell scripts, unix, linux, windows, the list goes on forever!
    BTW, tell those guys at billing they can lose transactions and see if they're happy about it... ;)
    At my specific area at least, there surely are very complex circuit/equipment inventory plus order fulfillment systems with complex, changing business logic and hundreds of tables. This is the kind of situation where domain objects and ORM really shine.

    Regards,
    Henrique Steckelberg
  189. Henrique,

    I have no doubt that in your case, ORM is really useful. However in the much more common many mainstream cases, there is not a lot of "complicated and ever-changing business rules involving validation, calculations and derivations" in the domain model.

    That takes us back to the EJB phenomena again. EJB also can be useful in some cases, for instance in EIA scenarios with 2-phase commit, and others. Not in 5% or even 0.5% of the cases but more like 0.05%. But the problem was, and is, that people thought EJB was cool, and started to use it everywhere, down to systems for the music store on the corner.

    Then comes the same problem with ORM, even if can be right in certain situations, today it is enormous overused. Just routinely used all over in all projects!

    Someone that is outside the Java world is forced to reflect that, "What is it that gives the Java guys this eternal longing for Computer Science?" They will use even the flimsiest excuse to complicate and/or over-architecture their solutions.

    I almost don't dare saying it but, but..
    can it be lack of self-confidence?

    I mean, when they can not beat the opposition in performance, productivity or uptime they think them can beat them by being "more serious". :)

    Regards
    Rolf Tollerud
  190. people thought EJB was cool, and started to use it everywhere.
    Problem is, certain people cannot distinguish J2EE from EJB (one is a component of the other).

    One can just as easy ship a ResultSet to a Client who has just typed in a SQL call to a Database, or one can go through as many Layers and Frameworks as one is instructed to be the architects.
    They will use even the flimsiest excuse to complicate and/or over-architecture their solutions.
    Problem I see in some cases is that someone is convinced one framework (42?) can solve every problem. After 5 years of development comes the all-encompassing framework which by the time it is finished is no longer valid because the market has switched to a new paradigm.
  191. 1+ to Jon for literary reference.
  192. I almost don't dare saying it..[ Go to top ]

    They will use even the flimsiest excuse to complicate and/or over-architecture their solutions.I almost don't dare saying it but, but..can it be lack of self-confidence?I mean, when they can not beat the opposition in performance, productivity or uptime they think them can beat them by being "more serious". :)RegardsRolf Tollerud
    You are assuming that using an ORM tool means you are over-engineering it. It doesn't mean that one is. Most projects end up needing some sort of mapping or rolling their own. Just because someone thinks the don't or doesn't recognize that they do doesn't mean they don't or didn't try themselves.

    If your app is so simple that you don't need one - just give the users SQuirrel and an SQL book. Much faster and cheaper. :)
  193. ORM are for beginners..[ Go to top ]

    Hello, hello, Mark. Just to keeps things straight. There are the ORM users that take the easy way (quick and dirty), not the other way around. And yes, I have all 3 Joe Celko's books.

    Using an ORM tool may not mean that they are over-engineering, but they think they are smart and that is evidently enough! :) That the code base is 2-3 times bigger doesn't bother them.

    Regards
    Rolf Tollerud
    (iBATIS user)
  194. ORM are for beginners..[ Go to top ]

    That the code base is 2-3 times bigger doesn't bother them.
    Just as long as it isn't my code base. :)
  195. ...it must not be a very big problem to lose transaction (connection) too...
    Your right. For example, losing a few call records here and there isn't much of a problem. I mean, after all, it's only money. Losing a customer's order isn't an issue either--if they really want the product, they'll call again.
  196. No problem losing transations in telecoms[ Go to top ]

    ...it must not be a very big problem to lose transaction (connection) too...
    Your right. For example, losing a few call records here and there isn't much of a problem. I mean, after all, it's only money. Losing a customer's order isn't an issue either--if they really want the product, they'll call again.
    Some one there is using SQL Server. So obviously lost data is of little concern. :)
  197. No problem losing transations in telecoms[ Go to top ]

    Darn, I said data. Now I will have to wash my mouth out. Good thing no one uses bar soap anymore. :)
  198. No problem losing transations in telecoms[ Go to top ]

    ...it must not be a very big problem to lose transaction (connection) too...
    Your right. For example, losing a few call records here and there isn't much of a problem. I mean, after all, it's only money. Losing a customer's order isn't an issue either--if they really want the product, they'll call again.
    Some one there is using SQL Server. So obviously lost data is of little concern. :)
    It is not a shame to do mistake, it is a shame to ignore it. Honest people fix mistakes, loosers blame tool. I am sure most ORM fans start to blame tool if something goes wrong.
  199. No problem losing transations in telecoms[ Go to top ]

    ...it must not be a very big problem to lose transaction (connection) too...
    Your right. For example, losing a few call records here and there isn't much of a problem. I mean, after all, it's only money. Losing a customer's order isn't an issue either--if they really want the product, they'll call again.
    Some one there is using SQL Server. So obviously lost data is of little concern. :)
    It is not a shame to do mistake, it is a shame to ignore it. Honest people fix mistakes, loosers blame tool. I am sure most ORM fans start to blame tool if something goes wrong.
    Come on. If the tool IS at fault, "blame" it (or those who developed it). If it is partially at fault, then "blame" it and the whatever else is to "blame". Then fix the problem. Which might be get another tool. Loosers blame everything else but the real culprit.
  200. Telecom experts I know do do not use ORM too, they develop and integrate rule engines, mediators to optimize the most complex stuff, they are very smart integratos and have JAVA,COBOL,SQL,C, UNIX experts in the same team. "easy-of-use" doe's not help for experts, they work very hard to get good result.
  201. Telecom experts I know do do not use ORM too, they develop and integrate rule engines, mediators to optimize the most complex stuff, they are very smart integratos and have JAVA,COBOL,SQL,C, UNIX experts in the same team.

    Yes, we do everything you said, with a bit of domain modeling + ORM here and there too! ;)
    "easy-of-use" doe's not help for experts, they work very hard to get good result.
    It is not about easy-of-use, it is about delivering cheaper, faster, safer and more maintainable systems on time.

    Regards,
    Henrique Steckelberg
  202. legacy data[ Go to top ]

    It seems to me that the conclusion of some "experts" here is to say to their customers: "go to hell with your data! i am going to use a RDBMS and you got to choose this because I don't know to do anything else".

    or

    "Why should I choose an inteligent solution? I will just let a 20 guys team to code their way JDBC... and after 1 year of dev I will scream out loud that JDBC is a mess"

    ./the_mindstorm
    [read more on blog]
  203. Telecom experts I know do do not use ORM too, they develop and integrate rule engines, mediators to optimize the most complex stuff, they are very smart integratos and have JAVA,COBOL,SQL,C, UNIX experts in the same team. "easy-of-use" doe's not help for experts, they work very hard to get good result.
    We've worked with several telecoms that I know were using JDO and/or Hibernate. I don't know what a "telecom expert" is, but there are lots of J2EE experts that work at telecoms and use ORM ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  204. Telecom experts I know do do not use ORM too, they develop and integrate rule engines, mediators to optimize the most complex stuff, they are very smart integratos and have JAVA,COBOL,SQL,C, UNIX experts in the same team. "easy-of-use" doe's not help for experts, they work very hard to get good result.
    We've worked with several telecoms that I know were using JDO and/or Hibernate. I don't know what a "telecom expert" is, but there are lots of J2EE experts that work at telecoms and use ORM ;-)Peace,Cameron PurdyTangosol, Inc.Coherence: Shared Memories for J2EE Clusters
    I use ORM tools myself, but it is not a reason to make systems tied to JAVA and to blame SQL and "easy-of-use" becomes motyvation for crap. "legacy" system experts I know more integrate and maintain old stuff than develop new toys, probably they can not use new coll stuff for every project and integrate many domain models for the same domain.
  205. Persistence is not ORM, and not JDBC[ Go to top ]

    I think this is a good solution. JDO and EJB persistence specs are not too far away (at least in intent). An important point about persistence is that this is not a synonimus for ORM, and so JDBC is not the general solution.

    ./the_mindstorm
    [read more on blog]
  206. 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.
  207. No EJB3.0 Persistence?[ Go to top ]

    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.

    Throws me a bit. If the POJO model is a separate spec, Does that mean
    there is no EJB3.0 persistence? Just Session Beans and MDBs? No EJB3.0
    Entity beans?

    Guess making J2EE container relationships and cascade delete part of a J2EE Domain model upset the entity/relationship model folks. Of course there are
    J2EE domain models and then there are OO domain models. I think the pojo persistence is aimed more at the entity/relationship model, oftentimes refered to as legacy database and merging the inheritance/behavior rich OO domain model with the current J2EE delegation/aggregation model. This is a very muddy area for J2EE and filling in the mud with pojos may make this an easier transition for folks stuggling with OO and then thinking J2EE Components are OO.
       Also a standard J2EE O/R mapping solution is needed for J2EE non-EJB Apps.
    I almost thought we had moved away from having to do entity/relationship models and could solve the problem completely with J2EE components, in a single technical infastructure rather than 2. Then there's database independence, say moving to an OO database without the relational baggage. I would be concerned about throwing the baby out with the bath water, but the JSR seem to be too smart to do something like that.
  208. No EJB3.0 Persistence?[ Go to top ]

    If the POJO model is a separate spec, Does that meanthere is no EJB3.0 persistence? Just Session Beans and MDBs? No EJB3.0Entity beans?
    Nope, it's the opposite. EJB3.0 "POJO" Entity Beans that will run inside and outside of a container. Entity Beans are not going away, they're going to be lightweight and run in J2SE or J2EE. JDO spec contributors will now be part of the EJB3.0 spec.

     - Don
  209. hopefully the new specification will be backward compatible with JDO 1.0.1, so that those of us with JDO-based applications today (and those building apps with persistence requirements between now and 2006) will have a simple migration path...

    so, hopefully we can keep the javax.jdo.* package naming, considering there aren't any legacy EJB 3 apps to migrate, and it would be a bit strgae to use javax.ejb.* packages within J2SE apps...

    Dave.
  210. Hi Dave
    hopefully the new specification will be backward compatible with JDO 1.0.1, so that those of us with JDO-based applications today (and those building apps with persistence requirements between now and 2006) will have a simple migration path...
    Versant Open Access (formerly JDO Genie) will both new peristence API and JDO. So our customers can choose to migrate or not when it suites them. It will take some time for the new persistence API to catch up with JDO in terms of functionality (there are many features in JDO missing from the EJB3 draft). People developing apps today should use JDO.

    Cheers
    David
    Versant Open Access www.versant.com
  211. Hi Dave
    hopefully the new specification will be backward compatible with JDO 1.0.1, so that those of us with JDO-based applications today (and those building apps with persistence requirements between now and 2006) will have a simple migration path...
    Versant Open Access (formerly JDO Genie) will both new peristence API and JDO. So our customers can choose to migrate or not when it suites them. It will take some time for the new persistence API to catch up with JDO in terms of functionality (there are many features in JDO missing from the EJB3 draft). People developing apps today should use JDO.CheersDavidVersant Open Access www.versant.com

    I agree. After reading the 2nd draft of the EJB3 persistence spec, I'm a little worried that it may be a bit of a step back from JDO 2.
  212. Not just a good thing[ Go to top ]

    This is a great thing in a number of ways..

    1. It shows that both expert groups actually listened to what the community was saying. Several of us raised the question at JavaOne why EJB was expanding into the POJO persistence domain that JDO seemed to be doing well in 1.x and even better in 2.x. The question was raised several times, by myself and many others, whether it wouldn't make sense to have POJO persistence be developed independent of the rest of the EJB specification's features. I'm very happy to see the two groups getting together to work toward this end (or toward something similar).

    2. It brings us a step closer to having working, reliable JDO implementations on all our favorite app servers. Too many J2EE vendors have said they would not put time and resources into implementing JDO because it wasn't part of the J2EE stack. If I'm reading this right, POJO persistence in general and JDO specifically could now be included in J2EE proper--or at least included enough to warrant J2EE vendors providing JDO/POJO implementations. Finally we'll have a vendor-supported and vendor-neutral POJO API to replace entity beans!

    3. It could conceivably represent a great coalescing of the many ORM tools under a single community-driven API. The biggest hurdle I've tackled in trying to move toward POJO persistence was that there were so many choices. Sure, many (most?) of them are great choices, but all for different reasons and using different API specifications. With this announcement, we might finally be able to say that POJO persistence has not only the community's but the vendors' stamp of approval. That will do worlds for adoption of POJO persistence in less adventurous enterprises.

    My jaw dropped when I read the letter. Kudos to the JDO and EJB teams for putting aside politics and finally settling their differences!
  213. I agree with people that say SQL and relational is way to go for persistance.

    Non ANSI SQL such as EQL and non DB transactions are of little use and O/R is not needed. I do not need an object "car" - that is academic OGM crap, I need a list of customers to do a muti row update.
    Even JSF is using RowSet.

    This is return to PetStore, this time bigger.
    What users want is ismple relational like iBatis jPetStore - now on apache.

    I wish JCP would have at least some user input or support; so vendors don't show us technlogy looking for a problem.
    This memo makes .NET stronger, becuase in .NET there is no EJB, that tend to fail projects.

    Just SQL-relational mappers will do.

    .V
  214. User input in JCP[ Go to top ]

    I wish JCP would have at least some user input or support; so vendors don't show us technlogy looking for a problem.
    You, as well as any other interested individual, is free to become a JCP member. For individuals, this is even free of charge. If you do not want to be a member, you can still comment on early draft and public draft releases, or make general comments on a specific JSR. The JSR websites contain e-mail addresses for this purpose.

    The JSR-243 expert group has a number of members that are not associated with any JDO vendor or open-source project. (This includes me.) Apparently, some users require (or believe they require) OR mapping capabilities or Java object persistence capabilities in general. These users may have different problems to solve than you have. Or maybe they just like to solve them in a different way. Or, maybe, their (alright, our) problems are just academic crap.

    So, I am not really sure what you're referring to. But then, I think we have been through this kind of discussion before, haven't we, Vic?


    Regards,

    Oliver Kamps
  215. User input in JCP[ Go to top ]

    I think we have been through this kind of discussion before, haven't we, Vic?
    No need for that kind of tone, right. I am not sure who "we" is, I assume we the users have give feedback -- as others and John above me in this topic said:
     ...it's nothing but awkward. I used ASP.net with stored procedure, quite efficient and work done. I didn't see the necessity of using ObjectSpaces kind of stuff.
    I have no interest in EJB, other in that it hurts J2EE reputation; and I do not want to master C# if I can keep using Java.
    You need to just get over it, Oliver. I sugest you focus on geting JSF JCP to use EJB and not RowSet, and show me a prouduction user site (Friendster?).

    .V
  216. User input in JCP[ Go to top ]

    No need for that kind of tone, right.
    Interesting, considering that you just called other people's work 'academic crap'. Where was the need for that?

    I'm getting more and more confused my your messages: you complained about the lack of user input into the JCP; I pointed out ways for you to participate, but apparently didn't get through.

    I'm also not quite sure what I have to do with the JSF specification, nor do I understand why only web applications matter in the ORM discussion?
  217. User input in JCP[ Go to top ]

    On June 16th 2004, Vic Cekvenich wrote:
    Comities don't solve anything, comities have meetings!
    They ignores us, why can't we ignore them?
    (Even silly JSF does not use EJB or JDO, they use CachedRowSet DAO AFAIK )
    http://www.theserverside.com/news/thread.tss?thread_id=26626#126188

    and Oliver Kamps replied:
    I have tried to find your name in the list of JCP members, but failed. So I assume you are a member through an organisation. Is this so? (By the way, individual membership is free!)

    More importantly, have you ever tried to interact with an expert group, e.g. by sending an e-mail to the corresponding jsr-nnn-comment e-mail alias? What were your experiences? Have you ever tried to join an expert group? This is really easy with the JDO 2.0 expert group: all I had to do was send a polite e-mail to the specification lead. I explained what I have done before, and what my interest in this specification was. And in I was. Real easy, didn't hurt a bit.
    http://www.theserverside.com/news/thread.tss?thread_id=26626#126207
  218. Persistence Needs and Queries[ Go to top ]

    There are at least two different ways applications use persistence. One is when you have a large graph of objects which you'd prefer to keep in memory if memory was infinite and permanent, but since it isn't, you need a way to swap them out to a database. Object persistence frameworks are a good fit for these situations and a fine solution to the old problem of developers spending all their time writing the same repetitive persistence code.

    The other scenario is where you have an enourmous mass of data which doesn't exist as logical objects, but rather as a database on which your application wants to run specific focused queries to produce reports, aggregate results, etc. It is less clear to me that an object persistence framework is the right solution in these cases, particularly when the application is most interested in sums, groupings, averages, mass updates, etc.

    I learned and used EJB 1.1 entity beans as originally recommended by the spec. I found them extraordinarily convenient when I had an application that fit the former description and unbelievably frustrating in the latter case. Consider a simple task like increasing every client's credit limit by 10%. With SQL you could write one statement that updates every row in your database. With an object persistence framework (if you're adhering to it strictly) you have to access and update every object.

    We definitely need to unify EJB and JDO if they're doing the same thing. But I also think we should give up trying to make them meet the needs of applications that really want to use databases as databases. For such applications we should either use JDBC as-is, or we should come up with an alternate framework that retains JDBC's emphasis on queries and result sets and global data modification but reduces some of the busy work we have to go through to use JDBC.

    Finally, I have pretty mixed feelings about attempts to define a generic query language for SQL databases. My company is a 100% dedicated Oracle shop. We will never switch databases and all our developers are both comfortable writing Oracle SQL and able to take maximum advantage of it to write the most effective queries. A generic query language might be OK for an object persistence layer but it isn't what programmers who need to do efficient queries over large databases want. SQL is a powerful, well-developed technology; let's let people use it when they need it without feeling like they're resorting to a dirty hack.

    Frank
  219. Sun really do a perfect choice[ Go to top ]

    Today, the biggest problem in java communicty I think is not how much choices we have but too many choices we own. When a few of fans enjoy them, many of others complain this. It push some of them to migrate to .net group. We have too many frameworks, too many persistent standards and too many apis. Every group thinks they are the best and want to replace other's with their standard. It's time for us to say no to this kind of phenomenon in java community. We should welcome different products designed for same function and based on a same standard. Sun shows us a real leader this time. Focus more on business solution and focus more on new field we don't touch yet. Comparing to your effort of the poor performance improvement coming from a new framework, buying a little bit fast box can reach same goal.