Discussions

News: Sun joins JDOCentral as a charter member; JDO 2.0 work begins

  1. JDOCentral has announed that Sun Microsystems has joined the JDO site as a Charter Member. The move is a good sign of increasing interest on Sun's part of JDO's development, particularly since joining as a charter member includes some financial support to help run JDOCentral. :)

    In addition, work on JDO 2.0 is beginning, with the JDO expert group convening today and tomorrow for a private meeting to chart the course of JDO 2.0. TheServerSide's Dion Almaer has joined the expert group and will be working on the spec and in the future keeping us all up to date of it's progress.

    Read Sun Microsystems Supports Java Data Objects (JDO) And Becomes Charter Member of JDOCentral.com.

    Threaded Messages (50)

  2. JDO 2.0, JSR?[ Go to top ]

    Regarding JDO 2.0: where is the JSR?

    I did not see it listed @ http://www.jcp.org/en/jsr/all
  3. JDO 2.0, JSR?[ Go to top ]

    JSR 12 I believe...
  4. JDO 2.0[ Go to top ]

    Hi all

    The first step is to define what will be in the JDO 2.0 scope.
    The new JSR will be posted on the JCP site after.

    Best Regards, Eric.
  5. JDO 2.0 - first step[ Go to top ]

    Hi all

    >
    > The first step is to define what will be in the JDO 2.0 scope.
    > The new JSR will be posted on the JCP site after.
    >
    > Best Regards, Eric.

    Chapter 24 in JDO 1.0 spec listed some urgent issues for JDO 2.0
    1. managed bi-directional relationship
    2. multiple PMs' interactivity
    3. projections in query, probably count(...)!
  6. JDO 2.0 - Kick off meeting concluded[ Go to top ]

    The kickoff meeting to form a JSR for JDO 2.0 and its expert group has just concluded its 3 days meeting in Washington DC. Since this meeting of the expert group was not covered by confidentiality, I can tell you about it.

    The attendees were drawn from the prexisting JDO expert group and those who joined the JDO maintenance group after the JDO 1.0 spec was released. Invitations were extended to other companies and individuals influential in the persistent object space, but I'm sure some deserving company, organization, or individual was omitted by accident rather than design.

    Eighteen people were in attendance for all or a significant part of the 3 days of marathon meetings. I'll let those who were there identify themselves if they wish, but here is the top level description. Three start up companies who principal product offering is a JDO implementation were represented by a total of four people. One open source JDO implementation was represented by one person. One major application software company was represented by one person One established O/R mapping product was represented by two people. Four published authors with books on JDO were present. Sun was represented by two people, one of who is already counted as an author. The on-line press was represented by one person. Three object database companies were represented by four people. One company who develops software for internal consumption was represented by one person. The geographical areas represented (where people live, not where their companies are headquarted) were, so far as I know, Maine, Massachusetts, North Carolina, Missouri, Florida, California, Washington, Texas, England, France, Germany, and South Africa.

    Bear in mind, that this meeting was put together after the 4th of July, and held in the middle of the week. The people who are currently expected to join the JDO 2.0 expert group are about two times this number.

    I think this description shows that the JDO 2.0 expert group will be diverse group with many individual interests, but one common interest: making it easier for application developers to create object-oriented Java applications that use the database. Regardless of your views on such technology, a serious attempt to improve the standard for transparent persistence has got to be a very good thing.

    The result of the meetings was a consensus on the broad outline of JDO 2.0. It will have many new and needed features. It's ambitious, and it's responsive to the feedback that we have seen on TSS and JDOCentral. Expect a JSR within weeks, which will have the targeted date for a public draft.

    To learn more about JDO 1.0 today, you could download the JDO Learning Tools at http://jdo-tools.sourceforge.net

    David
    :)
  7. Hibernate ?[ Go to top ]

    Any chance to see Gavin joining the expert group for JDO 2.0 ?
  8. Hibernate ?[ Go to top ]

    I believe Gavin was invited. I don't know the reasons why he was not able to attend or whether he plans to join the expert group. I think it would be a good thing if he did join the expert group. If Hibernate has plans to become JDO compliant in the near to medium future, now is definitely the time to influence the course of the 2.0 spec.
  9. Hibernate ?[ Go to top ]

    It's kind of off topic but from a user point-of-view, what makes Hibernate so usable is the short feedback <-> implementation cycle, new features emerge in nearly every other week's Hibernate release. To put forward, I'll be locked into Hibernate even if Hibernate 3.0 complies to JDO 2.0 spec, when 3.0.1 comes out a week later... the JSR process is fundamentally a different value proposition, so I guess Hibernate will have nothing to do with the spec...

    Just my .02
    Steve
  10. Hibernate vs. JDO[ Go to top ]

    Hibernate can not complies to JDO, because Hibernate does not change byte code. (maybe it can be changed by new version of JDK - 1.5). It means Hibernate must have worse performance than JDO but it is more transparent technology.
  11. Hibernate vs. JDO[ Go to top ]

    Hibernate can not complies to JDO, because

    > Hibernate does not change byte code.

    Is it really said in JDO spec that JDO compiliant implementation has to change byte code? I don't think so. Correct me, if I'm wrong.
  12. Hibernate vs. JDO[ Go to top ]

    Is it really said in JDO spec that JDO compiliant implementation has to change byte code? I don't think so. Correct me, if I'm wrong.


    The JDO spec says that every persistent class loaded by a PersistenceManager must implement PersistenceCapable. More specifically, *any* PersistenceManager of whatever JDO implementation can expect that a persistent class *already* implements PersistenceCapable when it gets loaded. Therefore, the class files of all persistent classes have to contain PersistenceCapable implementations.

    One could simply implement PersistenceCapable in one's object model to achieve this, there wouldn't be any need for byte code modification then. As this would be very intrusive, all major JDO implementations post-process the persistent class files at *compile time*. When the class files get loaded at runtime, they already contain PersistenceCapable code.

    This strict requirement for PersistenceCapable classes at compile-time to achieve portability between JDO implementations has the drawback that it enforces a post-processing step on compile. In contrast, Hibernate uses *run-time* byte code enhancement of persistent instances via CGLIB. No need to modify the class files, or the class loader for that matter.

    IMHO, the compile-time PersistenceCapable requirement is useless. If I intend to replace my JDO implementation, I don't expect to be able to drop it into my application. I don't mind having to apply an *implementation-specific post-processor* on my application's class files, as long as my source code is not affected.

    This would allow for more persistence implementation strategies. If a JDO implementation chooses not to apply any compile-time post-processing at all but to enhance the byte code for specific instances via CGLIB at runtime (like Hibernate), it would be free to do so. If it doesn't even use the PersistenceCapable interface or a JDO StateManager at all because it chooses dirty detection via snapshot comparison, that could be fine too.

    At the moment, the JDO spec mandates a specific persistence *implementation strategy*, not just an API and lifecycle semantics. That may be the biggest hindrance towards wide adoption. No persistence tool with a powerful own API, be it Hibernate or TopLink, will throw away its foundation just to be compliant with some specification.

    And of course, there's the reassociation issue: As long as there's no way to reassociate an object from a HTTP session or an external process with a JDO PersistenceManager to update it, it isn't well-suited for typical load-edit-store workflows in a web application or a 3 tier app with remote clients. I've pointed that out repeatedly.

    Finally, a personal preference: I like concise config files and fast development cycles for both API and implementation in general, and a powerful query language that allows to leverage relational concepts in particular. These are all remarkable Hibernate strengths that JDO implementations cannot compete with yet, and probably will never be able to, due to JDO's "object persistence" focus instead of Hibernate's/TopLink's "object/relational mapping" focus.

    Juergen
  13. Hibernate[ Go to top ]

    As somebody who has used Hibernate extensively, and has spent a lot of time with profilers and traces trying to optimize my data access plumbing, let me tell you that Hibernate is very efficient and very fast.

    Kinda spoils you actually. IMHO, the best open source O/R tool out there. IMHO of course.

    Sandeep.

    PS: I am in no way connected to the Hibernate project, except via my role as a user.
  14. Gavin on the JDO team[ Go to top ]

    I think there should be a good representation from all the key open source ORM projects. These folks have had a lot of feedback from users and besides, know what it takes to create a working persistence layer.

    Besides the last bunch of people you want to leave JDO in the hands of is Sun. These are the same guys who almost scuttled the project.

    Sandeep.
  15. Open source JDO representation[ Go to top ]

    I'm representing the XORM project (http://xorm.org/) on the JDO panel, and I am happy to say the attitude toward open source projects is all around a positive one from the several vendors here. I definitely think having a Hibernate expert involved would be great, if Gavin has the time and inclination for it.

    One item open for discussion is the adaptability of JDO to reflection-based architectures such as Hibernate. I'd like to see this accommodated if possible.

    Cheers,

    Wes
  16. Gavin on the JDO team[ Go to top ]

    Everyone I have talked to in the group would like Gavin to be working on this with us. He and Hibernate have the upmost respect.

    I have been very pleased to see what the group has to say for itself this week. This isn't the same old JDO group, and big things are being discussed for JDO 2.0. I think it will be a lot friendly, have features you "just needed", etc.

    It is cool that we have Oracle, Open source, and end user representation in the same room talking about all of these things. Let's hope something good comes out of it all :)

    Dion
  17. Gavin on the JDO team[ Go to top ]

    I think there should be a good representation

    > from all the key open source ORM projects.
    +1

    I agree. It would be nice to see Gavin on the expert group.
  18. JDO Implementation Strategy[ Go to top ]

    Juergen has a good point about JDO dropping the implementation strategy stuff. The main JDO spec should just be the user-visible requirements.

    If the JDO group wants to require an implementation strategy, it should split that into a different specification.

    In other words, there should be a single specification which defines only the user-visible behavior, allowing for the greatest implementation flexibility. This should be the main JDO spec.

    If necessary, there might also be a second specification which defines the implementation details/PersistentManager interface for those implementations which want to support that capability.

    That way, something like Hibernate could implement a JDO interface, but use the Hibernate implementation engine.
  19. JDO Implementation Strategy[ Go to top ]

    As I see it the spec does not prescribe an implementation strategy. All it requires is that the persistent classes, once they become visible to the runtime VM, implement the PersistentCapable interface. It is left to the implementation to decide how to achieve this. I dont even think they preclude a dedicated classloader solution.

    Of course this may still represent a design decision that goes against some other tool's architecture - but such is life, isnt it?
  20. JDO Implementation Strategy[ Go to top ]

    It just seems that an awful lot of the JDO spec is devoted to APIs that are not visible to the application programmer.

    PersistenceCapable, JDOImplHelper, StateManager could be eliminated entirely from the spec. I don't see any major value of those classes being defined in the spec.

    Of course, if JDO really wanted to be simpler, it would follow Hibernate's use of bean-style getters/setters instead of mucking with fields directly. getters/setters are made to be overridden.

    Each time I'm tempted to use JDO as an interface, a quick scan of the spec results in: "Ick. There's no way I'm implementing that junk." Which is a shame, since the high-level idea of JDO isn't all that bad.
  21. JDO Implementation Strategy[ Go to top ]

    Of course, if JDO really wanted to be simpler, it would follow Hibernate's use of bean-style getters/setters instead of mucking with fields directly. getters/setters are made to be overridden.


    Simpler? Maybe. But it's definitely not transparent to require getters and setters. I like to make my domain model as pure as possible without many distractions from the persistence framework. JDO allows me to do this.
  22. Simpler?[ Go to top ]

    Of course, if JDO really wanted to be simpler, it would follow Hibernate's use of bean-style getters/setters instead of mucking with fields directly. getters/setters are made to be overridden.<

    >Simpler? Maybe. But it's definitely not transparent to require getters and setters. I like to make my domain model as pure as possible without many distractions from the persistence framework. JDO allows me to do this.<

    Not wanting to wallow into any kind of controversy, I would argue that exactly the opposite is true. Directly persisting instance variables makes it necessary to implement a lifecycle callback interface (JDO InstanceCallbacks) if your class has a different _persistent_ data representation to its own _internal_ representation. OTOH, if you use getters/setters, you would simply never need to implement the InstanceCallbacks interface. (Hibernate has an interface like that, too, called Lifecycle - but its semi-deprecated because our users don't like having the domain model implement persistence-specific interfaces.)

    The classic example of this kind of thing is the ComplexNumber class, which might choose to be represented internally as |z|cis(theta), but persistently as x+iy. However, there are some more practical examples in this context.

    So, we argue that the getters/setters *abstract* the objects internal implementation from the persistence layer, *without* sacrificing transparency!

    And I would also argue that getters/setters are *quite* sufficiently transparent ;) My definition of POJO is "a JavaBean, but maybe not serializable if you don't want it to be".
  23. Simpler?[ Go to top ]

    Not wanting to wallow into any kind of controversy, I would argue that exactly the opposite is true. Directly persisting instance variables makes it necessary to implement a lifecycle callback interface (JDO InstanceCallbacks) if your class has a different _persistent_ data representation to its own _internal_ representation.


    You seem to believe that JDO InstanceCallbacks are intended to perform some mapping transformations. This is not the case. Mapping operations are to be performed by the JDO implementation, using mapping descriptors and/or customized mapper classes for instance. JDO InstanceCallbacks are more application-level triggers for managed/persistent instances : who should I notify before persisting ? What must be done before I'm deleted, etc.

    > (Hibernate has an interface like that, too, called Lifecycle - but its semi-deprecated because our users don't like having the domain model implement persistence-specific interfaces.)

    Yes they shouldn't have to, neither using Hibernate nor JDO.

    > So, we argue that the getters/setters *abstract* the objects internal implementation from the persistence layer, *without* sacrificing transparency!

    Such getters/setters follow an approach similar to the one used by EJB 2.0 (but EJB 2.0 persistence accessors are *really* abstract). To me this is problematic because is melts two different contracts : business and persistence (I don't want to expose getPassword() but I have to if I want my password to be persisted). Using implementation persistence allows let the developper free to choose its business interface (EJB 2.0 handles this problem by wrapping the entity implementation - with persitence accessors - into a component adapter which implements the business interface). It is true that getter/setters are made to be overridden, but for business purposes ! You can't be simpler my mixing contracts.
  24. wallowing.....[ Go to top ]


    You seem to believe that JDO InstanceCallbacks are intended to perform some mapping transformations
    <
    No. I do not.

    Did you actually read my post? I even gave an actual ComplexNumber example. (Suppose, for the sake of argument, ComplexNumber is an FCO.) This example can not be handled by the JDO model w/o implementing the InstanceCallbacks interface. It CAN be handled by the get/set model.

    How do you propose to implement this using "mapping transformations"? You can't, because the transformation b/w the two representations is the responsibility of ComplexNumber itself! It is part of the business model.

    Of course, in reality ComplexNumber is a SCO, but I was using this for an example that is widely known (I got it from the Eiffel book).


    >> who should I notify before persisting ? What must be done before I'm deleted, etc. <
    And: initialize persistent fields from transient fields.


    >> Such getters/setters follow an approach similar to the one used by EJB 2.0 <
    Actually they follow a *completely* different approach.

    * EJB2: nontransparent (the bean can't just write and read its own instvars)
    * JavaBeans: transparent (the bean may access instvars in normal Java style)

    Like, this is not even remotely similar! An EJB2 entity bean is an abstract class.....


    >> melts two different contracts : business and persistence (I don't want to expose getPassword() but I have to if I want my password to be persisted). <
    So, declare getPassword() as private. There. Fixed.

    For especially problematic objects, you can even HAVE two different interfaces, one for business, one for persistence - and be completely agnostic about which interface is closer to the POJOs own internal model. Of course, in actual practice this is rare.

    When mapping legacy data, getters/setters are a really "cheap" way to get out of the 1-to-1 correspondence b/w columns-instvars. Yes, there are other things you also need ("component" mappings, custom types) - but its nice to have a few different tools up my sleeve. This is just an extra layer of abstraction that helps me from time to time.



    Now, I don't believe that this stuff is especially important and worth turning into a religious war.
  25. wallowing.....[ Go to top ]

    Did you actually read my post? I even gave an actual ComplexNumber example.

    > (Suppose, for the sake of argument, ComplexNumber is an FCO.) This example
    > can not be handled by the JDO model w/o implementing the InstanceCallbacks
    > interface. It CAN be handled by the get/set model.

    For the record, embedded FCOs can be implemented quite nicely by the (current) JDO specification. InstanceCallbacks trickery is not at all necessary. Granted, the mapping to a relational database is defined by the vendor, but I know of at least one product (Kodo) that can map embedded FCOs into columns in the owning object's row. I do not really feel up to delving into detailed discussions about this topic (the 2.0 kick-off process was, among other things, exhausting). Suffice it to say that I think that the JDO 1.0 spec team made the right decision when deciding that O/R mapping was outside the scope of the 1.0 spec, and that the JDO 2.0 spec kick-off group made the right decision when deciding that O/R mapping (and other O/R features) was within the scope of the 2.0 spec.

    Also for the record, many JDO implementations (well, OK, Kodo at least) support mapping non-standard SCOs into meaningful, queryable data in the database. That is, if you wanted Kodo to handle fields of type java.net.URL, or your ComplexNumber, and treat them as SCOs, that is well within the bounds of Kodo's capabilities. Now, I think I can see a "but that's not in the standard!" coming. So I'd like to preemptively rant for a couple seconds:

    <rant>
    It seems as though we in the software space often decide that when comparing a non-standard product to a standards-based one, we should actually compare the non-standard product to the standard itself. I'm not sure why it happens, but I've seen this happen in lots of discussions on TSS about various different technology spaces. In reality, it's my opinion that when comparing a non-standard product to a standards-based one, we should compare them on their features. In other words, when comparing Hibernate to Kodo, we should not assume that things not handled by Kodo are not handled by Hibernate. Now, one of the features of Kodo is compliance with the JDO standard. This feature has a certain value to quite a number of people. Another of Kodo's features is the capability to deal with SCOs not defined in the JDO standard.

    I understand Gavin's problems with the fact that the JDO 1.0 spec requires a PersistenceCapable contract, and to that I just beg the community to wait around for a week or so until Craig (the JDO spec lead) has a chance to catch up on much-needed sleep and put together the 2.0 spec team kick-off meeting minutes.
    </rant>


    > Now, I don't believe that this stuff is especially important and worth
    > turning into a religious war.

    Agreed. Religious wars of any sort rarely lead to constructive behavior. This posting (of mine) is merely a clarification for the record (and a bit of a rant while I had the podium), so that future googlers will have more complete facts.


    -Patrick
  26. ick[ Go to top ]

    For the record, embedded FCOs can be implemented quite nicely by the (current) JDO specification. InstanceCallbacks trickery is not at all necessary. <

    You have _completely_, 100% missed the point I was trying to make but I can't really be bothered continuing this. Its my fault for using a misleading example. What I'm talking about is not the fine-grained "embedded" FCOs or SCOs etc (which, I agree, ComplexNumber _would_ be). I'm talking about a course-grained domain object with, for example, two different external representations - or with a different _internal_ representation (for computational purposes) to the persistent representation. I agree that these kinds of objects are relatively rare. In the common case there is hardly any difference between persisting properties or instance variables.

    The reason I used ComplexNumber here is it is an example of an object where the most convenient form for computational (ie. internal) purposes is r*cis(theta). But you would normally persist it as x + iy. x, y are "derived" properties from the POV of the class itself. But now scale that notion up to a coarse-grained _entity_ object with 5 or 10 properties, all _derived_ from some completely different internal representation.

    I have a particular use case in mind, but it is way too domain-specific to be understandable here. I'll try to write up something about this stuff on our Wiki ... just need to find some less domain-specific examples.
  27. JDO Implementation Strategy[ Go to top ]

    It just seems that an awful lot of the JDO spec is devoted to APIs that are not visible to the application programmer.

    >

    that internal API is a result of the requirement of binary portability of JDO persistent objects between implementations. IMO this a justifiable design decision made by the JDO spec.

    Considering the requirements the JDO spec decided to adopt (which I find, as I said, quite easily justifyable), I just dont see any other way. There must be an internal API (SPI) to achieve binary portability, and there must be code manipulation (be it source or binary) to support transparent in-memory transactions.

    thanks,
    Christian
  28. JDO Implementation Strategy[ Go to top ]

    [em]that internal API is a result of the requirement of binary portability of JDO persistent objects between implementations.[/em]

    Indeed. That's the whole point.

    Adding that feature with limited value significantly increased the complexity of the specification and severely constrained the potential implementations.

    Instead, that feature could have been made optional and simplified the spec tremendously.

    Similarly, JDO (and EJB-CMP) could have admitted that 80% of applications really only need a relational DB as the persistent store and created a specification aimed at solving that problem. Instead, both specs try to solve a more general problem that only, at most, 20% of applications care about.

    That's one of the main reasons Hibernate is a better solution. It's aimed squarely at solving the 80% well and not crippling itself trying to solve the 20% with a slightly different problem.
  29. JDO's Architecture[ Go to top ]

    Hi Scott,

    The JDO architecture has a number of important features:

    1. Transparent persistence, meaning that you don't have to write code in the data class (domain class) to have persistent things happen, like lazy loading, dirty tracking, transactional enlistment, etc.

    2. Binary compatibility, meaning that a class enhanced for one implementation is runnable with another implementation. This doesn't seem very important today, but it might become important. Imagine that you might store persistent objects in a variety of places, a very fast, but not too big datastore, versus a big-as-you-need but not so fast datastore. So, while the order is being constructed over a series of requests it might be stored in the fast datastore, and when it is placed, it might be stored in the big datastore. By pushing the data out to the datastore, you enable the greatest scaleability, but until the data becomes long-lived persistent data (a placed order) storing it in a fast datastore is preferable.

    3. Datastore architecture agnosticism. Again, the fact that relational dbs are the workhorses of the present doesn't mean that they are the best choice in all cases, or that they will always be the best choice for any particular case. So, unless you are a relational db vendor or unless you feel that your resume skill set is overly dependent on relational database skills, you do not have an interest in maintaining the hold that relational dbs have on enterprise data. JDO is about helping application developers, not about entrenching the architectures of different database vendors.

    I think these are wonderful features, and I would not like to seem them go. As an application developer, I want to use a standard persistence service for objects. I hope that someday JDO will become ubiquitous. Given the number of vendors that we have currently for JDO implementations and the number that are likely to be released in the next 12 months, I think we are well on our way.

    David
    :)

    <plug>
    To learn more about JDO 1.0 today, you might download a copy of the JDO Learning Tools, at http://jdo-tools.sourceforge.net
    </plug>
  30. JDO's Architecture[ Go to top ]

    Hi Scott,

    >
    > The JDO architecture has a number of important features:
    >
    > 1. Transparent persistence, meaning that you don't have to write code in the data class (domain class) to have persistent things happen, like lazy loading, dirty tracking, transactional enlistment, etc.

    It is a good feature, but most of popular tools implement it without code transformation, I do not think code transformation adds more transparence for persistence.

    >
    > 2. Binary compatibility, meaning that a class enhanced for one implementation is runnable with another implementation. This doesn't seem very important today, but it might become important. Imagine that you might store persistent objects in a variety of places, a very fast, but not too big datastore, versus a big-as-you-need but not so fast datastore. So, while the order is being constructed over a series of requests it might be stored in the fast datastore, and when it is placed, it might be stored in the big datastore. By pushing the data out to the datastore, you enable the greatest scaleability, but until the data becomes long-lived persistent data (a placed order) storing it in a fast datastore is preferable.

    It is a good feature too, but there is nothing to do with binary compatibility if tool doe's not depend on persistent class implementation.
      

    >
    > 3. Datastore architecture agnosticism. Again, the fact that relational dbs are the workhorses of the present doesn't mean that they are the best choice in all cases, or that they will always be the best choice for any particular case. So, unless you are a relational db vendor or unless you feel that your resume skill set is overly dependent on relational database skills, you do not have an interest in maintaining the hold that relational dbs have on enterprise data. JDO is about helping application developers, not about entrenching the architectures of different database vendors.
    >
    Yes, it is a very nice feature, but it must be better to implement JDBC driver
    for exotic datastore and use it with any kind of JAVA frontend.

    > I think these are wonderful features, and I would not like to seem them go. As an application developer, I want to use a standard persistence service for objects. I hope that someday JDO will become ubiquitous. Given the number of vendors that we have currently for JDO implementations and the number that are likely to be released in the next 12 months, I think we are well on our way.
    >
    > David
    > :)
    >
    > <plug>
    > To learn more about JDO 1.0 today, you might download a copy of the JDO Learning Tools, at http://jdo-tools.sourceforge.net
    > </plug>
  31. JDO's Architecture[ Go to top ]

    Hi Juozas,

    To achieve clarity, it is sometimes useful to focus on the big picture and sometimes it is useful to focus on one little detail. If you don't mind, I would like to take one little detail in our last exchange. You said, "I do not think code transformation adds more transparence for persistence."

    I am wondering what this means. Does it mean all of the following?

    1. One can persist data objects without instrumenting the code of the POJO class. In other words, no byte code enhancement by the persistence layer, no derivation from persistence layer defined class, no implementation of a persistence layer defined interface.

    2. One can lazily load the graph of persistent objects. In other words, if the class Owner has a reference to the class Dog (the myDog field), then when the POJO code in Owner makes use of the myDog field, the persistence layer will insure that it is loaded when needed, but not necessarily in advance, and without the application making any calls to the persistence layer to make this happen?

    3. A plain old JVM can be used.

    As you know, JDO can do all of these things, except that it needs byte-code enhancement. Pick the persistence layer that you favor, whether it be Hibernate, TopLink, CocoBase, Gemstone, or whatever, and tell us what it needs to make as much as possible of the three points above happen.

    Hoping for clarity, without flames,

    David
    :)
  32. JDO's Architecture[ Go to top ]

    Hi,
    It is nothing wrong in byte code manipulation and I use it myself,
     but way do we need this stuff in specification ?
    It is implementation strategy and it conflicts with implementation strategies like Hibernate,
     It has no problems with "lazily load" and "dirty detection" too.
      
    > Hi Juozas,
    >
    > To achieve clarity, it is sometimes useful to focus on the big picture and sometimes it is useful to focus on one little detail. If you don't mind, I would like to take one little detail in our last exchange. You said, "I do not think code transformation adds more transparence for persistence."
    >
    > I am wondering what this means. Does it mean all of the following?
    >
    > 1. One can persist data objects without instrumenting the code of the POJO class. In other words, no byte code enhancement by the persistence layer, no derivation from persistence layer defined class, no implementation of a persistence layer defined interface.
    >
    > 2. One can lazily load the graph of persistent objects. In other words, if the class Owner has a reference to the class Dog (the myDog field), then when the POJO code in Owner makes use of the myDog field, the persistence layer will insure that it is loaded when needed, but not necessarily in advance, and without the application making any calls to the persistence layer to make this happen?
    >
    > 3. A plain old JVM can be used.
    >
    > As you know, JDO can do all of these things, except that it needs byte-code enhancement. Pick the persistence layer that you favor, whether it be Hibernate, TopLink, CocoBase, Gemstone, or whatever, and tell us what it needs to make as much as possible of the three points above happen.
    >
    > Hoping for clarity, without flames,
    >
    > David
    > :)
  33. JDO's Architecture[ Go to top ]

    Hello Everyone

    I just landed back in London a few hours ago after attending the JDO 2.0 kick-off meeting. The event was very demanding but also most rewarding. I felt that the standard of the debate of JDO 2.0 proposed features was extremely high, which is not really surprising given the calibre of the attendees.

    I am still collating my own notes to feed back into Craig Russell's official minutes. These will be available soon enough for us to avoid discussing the specifics here until the minutes have been published.

    However I believe you, the community, will find that many of your criticisms and requests of JDO have been addressed.

    Two issues warrant clarification in the light of the present discussion. Firstly, a new JSR will be created for JDO 2.0 as Eric Samson intimated. Expect details to be available at the JCP shortly.


    Secondly, I PERSONALLY believe that JDO 2.0 will re-word the areas around PersistenceCapable such that this becomes an optional implementation strategy. (Note that I am not speaking on behalf of the JDO Expert Group here.) The spec should still detail the PersistenceCapable strategy and the binary compatibility guarantee which must apply across each vendor that chooses PersistenceCapable as the basis for their implementation. However the test for compliance is, and will remain, the TCK with any changes necessary to support the JDO 2.0 feature list. This leaves vendors open to select strategies based on compile-time enhancement (e.g. bytecode enhancer), run-time enhancement (e.g. ClassLoader based), reflection (e.g. Hibernate-style architectures) and Custom JVM (e.g. Gemstone-style architectures), as long as application-level functionality is supported as detailed in the JDO 2.0 specification.

    This should give a broader spectrum of Object Persistence and O/R Mapping products the option of becoming JDO-compliant if doing so is deemed a desirable strategy.

    Finally I'd like to thank all of the participants at the JDO 2.0 Kick-off Meeting for sacrificing time and revenue to attend, and their contributions and dedication to JDO.

    Kind regards, Robin.
  34. JDO Implementation Strategy[ Go to top ]

    As I see it the spec does not prescribe an implementation strategy. All it requires is that the persistent classes, once they become visible to the runtime VM, implement the PersistentCapable interface. It is left to the implementation to decide how to achieve this. I dont even think they preclude a dedicated classloader solution.


    It is not true, see "persistence aware" classes.
    PersistentCapable/StateManager is a mistake in specification.
    It is inpossible to implement JDO without source or byte code transformations and dictates an implementation strategy. Mapping file format was not a very good idea too.
    I think JDO specification is useless in practice for most of O/R mapping tool implementations and users at this time, but it must be possible to fix it (drop PersistentCapable,StateManager and add factory method to instantiate persistent classes).

    >
    > Of course this may still represent a design decision that goes against some other tool's architecture - but such is life, isnt it?
  35. JDO Implementation Strategy[ Go to top ]

    BTW
    please do not misunderstand it. I do not think PersistentCapable/StateManager and enhansement is a bad way to implement persistence, but it is useless in specification, It conflicts with existing O/R tool implementation strategies, Hibernate or XORM implementation strategies are not so bad too.

    > > As I see it the spec does not prescribe an implementation strategy. All it requires is that the persistent classes, once they become visible to the runtime VM, implement the PersistentCapable interface. It is left to the implementation to decide how to achieve this. I dont even think they preclude a dedicated classloader solution.
    >
    > It is not true, see "persistence aware" classes.
    > PersistentCapable/StateManager is a mistake in specification.
    > It is inpossible to implement JDO without source or byte code transformations and dictates an implementation strategy. Mapping file format was not a very good idea too.
    > I think JDO specification is useless in practice for most of O/R mapping tool implementations and users at this time, but it must be possible to fix it (drop PersistentCapable,StateManager and add factory method to instantiate persistent classes).
    >
    > >
    > > Of course this may still represent a design decision that goes against some other tool's architecture - but such is life, isnt it?
  36. JDO Implementation Strategy[ Go to top ]

    <Juozas>
    > please do not misunderstand it. I do not think PersistentCapable/StateManager and enhansement is a bad way to implement persistence, but it is useless in specification, It conflicts with existing O/R tool implementation strategies, Hibernate or XORM implementation strategies are not so bad too.
    </Juozas>

    JDO is not about supporting existing O/R tool implementation strategies, but existing datastores. I think PersistentCapable/StateManager has great value and was subject of JDO 1.0. Now, JDO 2.0, can improve its support to better RDBMS strategies and many other datastores.

    Forum for JDO 2.0 discussion
    http://www.jdocentral.com/forums/index.php?s=bc3abde5d64b9d4aa9fb0a4737d2c196&act=SF&f=10
  37. JDO Implementation Strategy[ Go to top ]

    <Juozas>

    > > please do not misunderstand it. I do not think PersistentCapable/StateManager and enhansement is a bad way to implement persistence, but it is useless in specification, It conflicts with existing O/R tool implementation strategies, Hibernate or XORM implementation strategies are not so bad too.
    > </Juozas>
    >
    > JDO is not about supporting existing O/R tool implementation strategies, but existing datastores.

    I do not think it is a good way to ignore existing technologies and to try reinvent persistence and to experiment with "standard".

    >I think PersistentCapable/StateManager has great value and was subject of JDO 1.0. Now, JDO 2.0, can improve its support to better RDBMS strategies and many other datastores.

    Datasourse doe's not know about PersistentCapable/StateManager, it is not used by API user too. StateManager is a special kind of interceptor used by JDO implementation "helpers" only, is not it ?

    >
    > Forum for JDO 2.0 discussion
    > http://www.jdocentral.com/forums/index.php?s=bc3abde5d64b9d4aa9fb0a4737d2c196&act=SF&f=10
  38. Hibernate vs. JDO[ Go to top ]

    Well, it is not really true that you need to enhance at compile time. I wrote a classloader that enhances class at loadtime, if someone is interested in...
  39. Hi Francesco,

    You are quite right. Compile time byte code enhancement is the strategy generally preferred by today's JDO vendors, but the JDO 1.0 spec allows for any number of ways to get the implementation of the PersistenceCapable interface and the persistence-capable contract into the data class. Alternatives include load-time enhancement and data class code generation tools.

    David
  40. Re: Hibernate vs. JDO[ Go to top ]

    Hibernate can not complies to JDO, because Hibernate does not change byte code. (maybe it can be changed by new version of JDK - 1.5). It means Hibernate must have worse performance than JDO but it is more transparent technology. <

    All of this is wrong.
  41. Hibernate vs. JDO[ Go to top ]

    please dont start again the battle Hibernate vs. JDO.
  42. Re: Hibernate vs. JDO[ Go to top ]

    No, we don't want that (there's not much left to discuss). I just had to reply, because there's not a single coherent or correct statement in these two sentences...
  43. involvement[ Go to top ]

    I believe Gavin was invited. I don't know the reasons why he was not able to attend or whether he plans to join the expert group. <

    A couple of people spoke to me privately and I was noncommital. No-one has yet sent me any email on this topic.

    >> If Hibernate has plans to become JDO compliant in the near to medium future, now is definitely the time to influence the course of the 2.0 spec. <
    I've always been open to becoming involved in this. Feel welcome to take this offline.

    gavin at incubus dot de


    peace
  44. involvement[ Go to top ]

    Done.
  45. Yesterday, Craig Russell extended by e-mail a cordial invitation to Gavin to participate in the JDO 2.0 specification process. Not surprisingly, I have not yet heard Gavin's response. Like all members of the current JDO expert group, I hope it will be positive.

    David
  46. Hibernate ?[ Go to top ]

    I'ld rather see the JDO expert group join hibernate :-)
    Now that would be good news !

    Regards,
    Tom Baeyens
    Java Business Process Management (jBpm)
  47. Hibernate ?[ Go to top ]

    I'ld rather see the JDO expert group join hibernate :-)

    > Now that would be good news !

    Here here!
  48. Reflection in Hibernate[ Go to top ]

    Hi all,

    I am newbie to Hibernate, but I am curious about one question:

    The Hibernate uses the Reflection to invoke getter and setter at runtime, Is it efficient? It is said that refection method call is about 1000 times longer than the usual method call.

    Michael Xiang
  49. Reflection in Hibernate[ Go to top ]

    Hi all,

    >
    > I am newbie to Hibernate, but I am curious about one question:
    >
    > The Hibernate uses the Reflection to invoke getter and setter at runtime, Is it efficient? It is said that refection method call is about 1000 times longer than the usual method call.
    >
    > Michael Xiang

    Hibernate uses CGLIB that changes the bytecode at runtime adding the code needed to make it faster. This method is much faster than reflection.
  50. Hibernate uses CGLIB that changes the bytecode at runtime adding the code

    > needed to make it faster. This method is much faster than reflection.

    This is exactly what one part of JDO enhancement does, and can be done at class load time, just as Hibernate does. The other part is to insert field intermediation code in order to support lazy loading and dirty detection, replacing field accesses with method calls to check for field loading (on field read) and to set field dirty flags (on field write).

    Note that JDO currently requires that an enhanced class behave just as an unenhanced class in the absence of a PersistenceManager (before you call pm.makePersistent(Object). A few things can't be avoided, that, to me, are minor (see section 5.3 of the JDO 1.0 spec):

    * A little bit of extra code is executed to see whether or not the instance is being managed. It boils down to executing the line "if (stateManager == null) return;". How does Hibernate support lazy loading?

    * Added fields/methods are visible using reflection. I imagine the same is true in Hibernate.

    * Class metadata registration is executed at class load time.

    Note that debug line information is preserved by the enhancer. I'm beginning to dig into the Hibernate 2.0 docs, so I may have the answer before someone posts it -- I'm ok RTFMing, but if someone can comment for the benefit of all, that'd be awfully nice :)

    --matthew
  51. [snip]
    > This is exactly what one part of JDO enhancement does, and can be done at class load time, just as Hibernate does. The other part is to insert field intermediation code in order to support lazy loading and dirty detection, replacing field accesses with method calls to check for field loading (on field read) and to set field dirty flags (on field write).
    [snip]
    How does Hibernate support lazy loading?

    OK, I answered my own question, from the Hibernate 2.0.2 docs:
    <quote>
    11.1. Proxies for Lazy Initialization

    Hibernate implements lazy initializing proxies for persistent objects using runtime bytecode enhancement (via the excellent CGLIB library)...Note that the proxied class must implement a default constructor with at least package visibility.
    </quote>

    This sounds a lot like the JDO strategy. Hibernate seems to take a dynamic proxy approach, whereas JDO 1.x doesn't. JDO 2.0 is considering broadening the spec to address different implementation strategies, including dynamic proxies, pure reflection (no Hibernate-style enhancement for reflection optimization), AOP, and abstract beans.

    I noticed also that Hibernate has issues with polymorphism in this case:
    <quote>
    Firstly, instances of Cat will never be castable to DomesticCat, even if the underlying instance is an instance of DomesticCat
    </quote>
    JDO has never suffered from this problem.

    Am I misunderstanding or overestimating Hibernate's similarity to JDO? The docs describe much of what JDO standardizes with respect to enhancement.

    --matthew