JPOX announces 1.0 (JDO 1) and JDO 2 preview releases

Discussions

News: JPOX announces 1.0 (JDO 1) and JDO 2 preview releases

  1. Java Persistent Objects JDO (JPOX) is an Open Source implementation of the JDO specification for transparent persistence of Java objects. The aim of JPOX from the outset has been achievement of compliance with the JDO specification. This announcement is in 2 parts.

    Announcing the first full release of JPOX (version 1.0.0), providing a fully TCK compliant Open Source implementation of the JDO 1.0.1 specification. JPOX passes the TCK for both datastore and application identity. This version of JPOX provides
    • Support for schema generation, and existing schema
    • Support for object/relationship mapping for a wide range of situations.
    • Querying using JDOQL (including a large number of method extensions), or SQL (part of JDO 2.0).
    • Excellent support for the vast majority of RDBMS available on the market today.
    • Own byte-code enhancer
    • Pluggable framework for external caching
    • Release under an Apache style license
    Announcing the release of the next generation of JPOX (version 1.1.0-alpha-1) previewing many features of the JDO 2.0 (early draft) specification. With this release, in addition to the features of JDO 2.0 that were already available in 1.0.0, we also provide the following new
    features
    • the ability to attach/detach objects to/from the persistence graph, providing major usability benefits over JDO 1.0
    • the ability to use named queries
    • control over the uniqueness and result range of queries
    • the ability to define fetch groups
    • adoption of the JDO 2.0 Meta-Data definition
    New features will be added to this list in the near future as we move towards a fully compliant implementation of the JDO 2.0 specification.

    In addition to the zero cost of JPOX, and its Open Source nature, we also provide extensive documentation, and an online support community via our Forums (http://www.jpox.org/servlet/forum). Why not try out what could be the solution to your Java persistence problems.

    To find out more, please visit http://www.jpox.org

    The JPOX Team

    Threaded Messages (37)

  2. jpox rocks![ Go to top ]

    I'm using jpox with much satisfaction.

    I like very much jdo because it allows to write truly object oriented applications models: when needed a class can discover to be persistent (or transactional, at least) and get an handle to the persistence manager for database access.

    To have the application model be anaware of persistence is silly except for the most simple applications.

    On the contrary, it's important to write persistence aware code in the application model methods, where needed and well incapsulated. This way you don't have a data model and a separate business model. You have just one application model, with both data and behaviour. A true object oriented approach. Hibernate does not allow this, non easily at least. That's why I prefer jdo.

    Carlo
  3. Agreed![ Go to top ]

    Java Standard, open source, the documentation and support is outstanding, and its SQL-enabled.

    It's a no-brainer (but there's alot of really big brains out there ;-)

    Goodbye Hibernate, Toplink, Torque, IBATIS, Cayenne, ORB...
  4. jpox rocks![ Go to top ]

    On the contrary, it's important to write persistence aware code in the application model methods, where needed and well incapsulated. This way you don't have a data model and a separate business model. You have just one application model, with both data and behaviour. A true object oriented approach. Hibernate does not allow this, non easily at least. That's why I prefer jdo.Carlo
    Hi Carlo,

    Mind sharing with us how this is done? Are you talking about the data access layer when you mention the data model or is it just the domain model (POJOs)? If so does that means that you have the business logics and the data access logics merged in the business layer?

    I might be missing some point here but i don't quite understand the disadvantages of separating data model (data access is it?) from the business model. Could you explain more about the reason behind?

    Thanks in advance

    regards
  5. If so does that means that you have the business logics and the data access logics merged in the business layer?
    Yes, precisely.

    For example. Suppose I have classes Balance and Payment, than I may write in the method 'Balance.update (Payment payment)' the business code to actually update the database.

    <code>

    class Balance
    {
       Subject subject;
       Date date;

       public void update (Payment payment)
       {
           PersistenceManager pm = JDOHelper.getPersistenceManager (this);
           pm.makePersistent (payment);
           
           /* then udpate both the payment subject balance and
              and the payment counterparty balance
              ...
            */
       }
    }


    class Subject
    {
        public Balance getBalance (Date when)
        {
           PersistenceManager pm = JDOHelper.getPersistenceManager (this);
           Query query = pm.newQuery (Balance.class, "subject == s && date <= d");
           /* ... */
        }
    }

    </code>

    At least I like this way of doing it. Maybe not everyone. The fact is that when it comes to enterprise application the persistence logic cannot be separated from the business logic. In this way you put behaviour in the class its about, doing real object oriented programming. This is a good way to do code reuse. Otherwise you will end up with many BalanceUtils, SubjectUtils class whose name is the simptom of a problem. This is also good for simple and incremental testing.
  6. "
    public static PersistenceManager getPersistenceManager(java.lang.Object pc)
    Return the associated PersistenceManager if there is one. Transactional and persistent instances return the associated PersistenceManager.
    Transient non-transactional instances and instances of classes that do not implement PersistenceCapable return null.
    "

    Your service + domain object must be "managet" or this code will throw NullPointerException.
    This is not a good way for perfornmace reasons, you make your service "transactional" or "persistent", with all state management to execute query on the next service + domain object.
    Trust me OOP is not about this. This code are the same structs and procedures, but they are used in broken way.
  7. <blockquoteThis is not a good way for perfornmace reasons, you make your service "transactional" or "persistent", with all state management to execute query on the next service + domain object.Trust me OOP is not about this. This code are the same structs and procedures, but they are used in broken way.I'm surely a little naive.

    So I don't understand the performance problems, why OOP is not about this, and why structs and procederes are used in a broken way.

    I'd be grateful to you if you could explain it a little more.

    Thanks,
    Carlo.
  8. I think I was very clear, sorry if it is not (I am not JDO expert). As I understand form JDO documentation and you code, it will throw NullPointerException :

     new Balance(account).update(payment);

    To fix it you need to make "balance" instance persistent, do you need to load "balance" from database to add "payment" ?
    How it is better than class method "Balance.update(payment);" ?
  9. Yes of course, the balance is an instance lookup previously from the database, and it represents the balance at a certain date of an account. For example with a method
    class Account

    public Balance getBalance (Date when)
    {
        PersistenceManager pm = JDOHelper.getPersistenceManager (this);
        Query query = pm.newQuery (Balance.class, "account = a && date <= d);
        query.declareParameters ("Account a, Date d");
        Collection balances = (Collection) query.execute (this, when);
        ...
        /* if the balance does not exists I create it and then
           make it transactional, so that an eventual update(Payment)
           method would work */
         ...
    }
    Of course, now it is the Account instance that must be persistent or transactional. This in turn may have been looked up previously, and so on. This actually becomes a boostrap problem. You solve it by having the controller
    layer (ui) having a reference to the PersistenceManager, to do the first lookup.
  10. As I see you load object graph to memory form database to add single record. It is not very expensive to load record from DB, but nobody can make me do it.
    I think if I add record without object graph traversing then I do not break OOP too.
  11. Thanks for all the replies. This is what I like about TSS, cause you get all sorts of nice replies from people in different prespectives. :-)

    I think I am begining to see the point of having business artifacts in the domain objects as in Naked Objects (Thanks Jochen for pointing that out). Its a shame on me have missed the 5 series out.

    Now that I think of it, at times it is kind of hard to try to separate the business layer from the dao layer, deciding what to go into which and the ripples from layers which is kind of an unavoidable in layered architecture which i think could be minimized by making dao layer more fine grained.

    Just curious actually, are they many out there who practise the Naked Object or layered way?

    regards
  12. null return value != NPE[ Go to top ]

    "Transient non-transactional instances and instances of classes that do not implement PersistenceCapable return null."

    Your service + domain object must be "managet" or this code will throw NullPointerException.
    FTR, the JDOHelper.getPersistenceManagerFactory(Object pc) method will return null, and will not throw a NullPointerException.

    -Patrick

    --
    Patrick Linskey
    http://solarmetric.com
    SolarMetric Inc.
  13. null return value != NPE[ Go to top ]

    Yes, I am not idiot, but example code must throw it, if object is trancient. It is not any kind of JDO flaw, it is a bad use case. I am sure it is possible to write good code with JDO too, I saw some usefull features in JDO 2 (projection and SQL).
    I think the good way to use JDO is to implement wrapper for PM to return strong typed values and to use it as thread local service, but I do not need managed or persistent objects in this case, as I understand JDO can not update/insert/delete objects ( values ) without "managemet" at this time.
    I mean "management" is a stuff like StateManager or local cache.
  14. Avoid the bloat[ Go to top ]

    I might be missing some point here but i don't quite understand the disadvantages of separating data model (data access is it?) from the business model. Could you explain more about the reason behind?Thanks in advanceregards
    I'm not Carlo, but I'm inclined to try an answer.

    The disadvantages? That is easy to answer: Maintainability
    If your business model changes, chances are high that your data model
    also changes. So you have to do changes on at least two different places
    and make sure these play together.

    The change "pierces" through your layers, generating more work for each
    layer.

    It is far easier to just adapt a business model that is modelled after the Naked-Objects approach (see articles on TSS) - which directly affects
    the data stored and the UI - than to walk through a lot of different classes
    and packages (data objects, DTOs, presentation objects, session beans etc.)
    making sure each change is correct.

    I still have to see the advantages of n-tier-layers (n>3) in real life.

    I've been through all these growing pains, starting from POJOS, going over
    a hand-made "application server", going over to EJB using entity beans, back to
    JDO using a behavioural complete business model.
    The latter is by far and wide the easiest to maintain and to adapt
    to customer specific changes.
  15. Avoid the bloat[ Go to top ]

    I could not agree more.

    I would also add that layering the application ends representing the same concept multiple times in every layer, which is not a good symptom in my opinion.

    Thanks,
    Carlo.
  16. jpox rocks![ Go to top ]

    I had used Solarmetric JDO1.0 for a product development.But this time I am for JPOX, as open source would allow me to experiment longer.I see high recomendation from people for JPOX !!

    With JDO,data acess layer is a flat Persistent capabale component.The Business tier delegating the request to the Persistent capabale component to persist domain objects(POJO)

    Though with JDO1.0,complex queries can't be developed using JDOQL,so data acess layer required to write DB specific JDBC SQL queries.
    With JDO2.0,I am yet to explore the complex relationship queries.

    As Carlo said,with JDO,your application design model
    1)is truly Object oriented
    2)Allows developer to participate in the Data model design
    3)Portable across database
    4)Can be extended to run in Application server Environment
    5)Standard J2EE persistence mechanism ...rather than proprietary like Hibernate
  17. JDO Maturity[ Go to top ]

    The availability of TCK-compliant JDO 1.0.1 implementations from the open source community is yet another sign of the maturity of JDO technology, whilst the commitment by various vendors promptly to deliver previews of the forthcoming JDO 2.0 release speaks volumes about the comprehensiveness, specification-stability and implementability of the JDO 2.0 Early Draft.

    You can download the JDO 2.0 Early Draft from http://www.jcp.org/en/jsr/detail?id=243 - remember to send your comments to jsr-243-comments at jcp dot org and we will give due consideration to each comment we receive.

    Congratulations to all involved on the JPOX project.

    Kind regards, Robin.
  18. JPOX, JDO, Javapedia[ Go to top ]

    I added JPOX to Sun's Javapedia

    http://wiki.java.net/bin/view/Javapedia/JDO
  19. There has been much -animated, I may add, grin- talk lately about the Java persistence layer and it suffices to see how many threads are ongoing only on the serverside, to admit that there are apparently problems to be addressed. I believe those problems boil down to 2 serious issues: complexity and feature set. (dev args, so don't get me started on EJB vendor lock-in etc!)

    Almost nobody still denies EJBs are overly complex for the feature set they offer (and it doesn't look like the current 3.0 spec gets it right for that matter) while Hibernate, however addressing the complexity issue, looses on features... compared to JDO. (like: true OO-like Query Language, DS-type transparancy etc etc)

    For people sympathizing with the above and dying to try a JDO implementation (vulgar curiosity is always better reason though ;-), I got 2 words on JPOX: it rocks!
    Of all JDO implementations I tried, this one draws the line and, as far as I am concerned, this might as well be the implementation JDO can enter its 2.0 era with as its Reference Implementation.
    So... Keep up the good work guys (don't sleep, code! ;-)

    Ph
  20. After evaluating other open source offerings (Hibernate, Apache OJB) and then starting to use an early beta version of JPOX about 9 months ago, I've never looked back - JPOX is great! JDO is everything that Entity Beans *should* have been, and it's here now (rather than in 18 months time like EJB 3).

    And combined with the excellent open-source EclipseJDO plugin, it's even better.

    Keep up the great work JPOX team!
  21. I could not agree more. I'm using EclipseJDO e JPOX and I'm enthusiast about them. Perhaps the only thing that could refrain to use JPOX in the enterprise is that is does not support distributed transactions (or at least beta4 did not).
  22. Great Job![ Go to top ]

    Just wanted to congratulate the JPOX team for their efforts. I have no idea how Erik and Andy find the time to create this stuff.

    - great documentation
    - great support
    - it works

    I've been using JPOX along with Srping's JDO support with good results. I'm looking forward to trying the JDO 2 preview release but am not sure if Spring, in its current form, will able to handle JDO 2. I would think so if transactions and the PersistenceManager have not changed... though maybe new JDO 2 exceptions, if they exist, might need to be caught by Spring.

    I think JDO 2 and Spring together provide a sweet spot for doing persistence. Anyway I'll second the vote for having JPOX become the JDO RI. (I have no idea what that would entail). Again, keep up the good work!

    Paul
  23. Spring + JDO[ Go to top ]

    Congrats, JPOX team!

    Full disclosure -- I work for SolarMetric, the makers of Kodo JDO.

    There is actually a sample web application available (it's version 0.9, so it's still in development. But there's a lot that can be learned from it already.) that shows how Spring can be used with JDO. It's available at http://www.solarmetric.com (specifically http://solarmetric.com/springjdo/springjdo-release-0.9.jar). The sample was developed using Kodo JDO, but it should work well with JPOX, too, or any other compliant JDO implementation, with some minor configuration changes. During the development of this sample app the Spring guys made a bunch of JDO-related usability improvements, so look forward to that in the next Spring release.

    Spring and JDO work really well together. Some of the advantages include:

    * Both JDO and Spring promote a lightweight development process based on POJOs
    * Spring does your resource management
      - injects your PersistenceManagerFactory
      - injects your DataSources
    * Declarative transactions

    Plus, if one day you want to deploy your app into an appserver, into a Swing client, etc., no code changes are necessary!

    Thanks,
    Greg
  24. Great Job![ Go to top ]

    Just wanted to congratulate the JPOX team for their efforts. I have no idea how Erik and Andy find the time to create this stuff.- great documentation-
    I'm a new jpox user. Where's the documentation?? (I haven't found any)
  25. Documentation[ Go to top ]

    You can find it online or in the sourceforge file repository.
    Carlo.
  26. JPOX documentation[ Go to top ]

    I also tried to look at the documentation in the site. The pages are hidden somewhere without any link pointing to them. I finally found out by downloading jpox-docs from Sourceforge. This contains very detail documentation about using JPOX separately, with eclipseJDO an eclipse plug-in.
    check jpox-docs in http://sourceforge.net/projects/jpox/
  27. JPOX documentation[ Go to top ]

    For me at least the documentation starts at:

    http://www.jpox.org/docs/index.html

    From there two links, toward the top of the page, to each of the different versions of JPOX (for JDO 1 and JDO 2 preview) can be found:

    http://www.jpox.org/docs/1_0/configuration.html
    http://www.jpox.org/docs/1_1/configuration.html

    Paul
  28. Great Job![ Go to top ]

    I've been using JPOX along with Spring's JDO support with good results.
    I've personally not used JPOX in production yet, but I've used JPOX to test and improve Spring's JDO support. I've been pleasantly surprised by JPOX's matureness and in particular the documentation - kudos to Erik and Andy! I'm looking forward to playing with the new JDO-2-style attach/detach support - an eagerly awaited feature.
    I'm looking forward to trying the JDO 2 preview release but am not sure if Spring, in its current form, will able to handle JDO 2. I would think so if transactions and the PersistenceManager have not changed... though maybe new JDO 2 exceptions, if they exist, might need to be caught by Spring.
    Spring's JDO support will seamlessly work with JDO 2, as JDO 2 will be fully backward-compatible. The upcoming Spring release 1.1 introduces significant enhancements to the JDO support - like one-line operations and Open PersistenceManager in View support -, being even more prepared for leveraging JDO 2 features once they're available.
    I think JDO 2 and Spring together provide a sweet spot for doing persistence.
    Thanks for your kind words! :-) IMHO, JDO 2 will indeed be a compelling option for full-blown O/R mapping in Spring, alongside Hibernate. Spring is dedicated to continue providing first-class support for various data access strategies: JDBC, Hibernate, JDO, iBATIS SQL Maps, and - as of Spring 1.1 - also OJB's PersistenceBroker.

    Juergen
  29. Shame[ Go to top ]

    Shame about the name though ;-)
  30. Shame[ Go to top ]

    Shame about the name though ;-)
    This seems to be the fitting backend for the Kroupware project. ;-)
  31. XA Support?[ Go to top ]

    Hopefully I'm wrong, but from what i could see, there's no support for XA transactions (or javax.sql.DataSource in general) yet.
    For enterprise integration, this is a drawback, since JMS and JPOX can't be reliably used together in a single transaction.
    Will there be support for XA transactions, and if so, when?

    TIA
    Fokko
  32. XA Support?[ Go to top ]

    Yes,

    I remarked this before. It would be very important if JPOX supported XA transactions. This can actually refrain people from adopting JPOX in the enterprise.

    Ciao,
    Carlo.
  33. XA Support?[ Go to top ]

    Hopefully I'm wrong, but from what i could see, there's no support for XA transactions (or javax.sql.DataSource in general) yet.For enterprise integration, this is a drawback, since JMS and JPOX can't be reliably used together in a single transaction.Will there be support for XA transactions, and if so, when?

    TIAFokko
    We do provide javax.sql.DataSource connections, but not yet a XAResource. Now on the queue. Initially scheduled for august
  34. Nested transaction[ Go to top ]

    Does JPOX support Nested transaction?
  35. Nested transaction[ Go to top ]

    Does JPOX support Nested transaction?
    JPOX or JDO 1.0 don't support nested transactions.
  36. Congratulations on getting this release out and passing the TCK!

    Oliver Kamps
    www.fiftybar.com
  37. Span databases?[ Go to top ]

    Hi,

    I'm trying to link 3 physically different databases (Sybase, MS-SQL and PostgreSQL) to provide composite entities. There is information in all 3 databases that would fit into a single class. One database has the client's forename and surname split whereas the other has it stored as a single field.

    I've been playing with Hibernate and I know I can configure 3 datasources and then 3 classes. I was going to try and create a class with instances for each of the Hibernate objects and then route methods to the lucky instance.

    Would JDO be better at doing something like this?
    Is this approach completely wrong?

    Thanks
  38. Span databases?[ Go to top ]

    Copy all of your clients to one of them. You can use awk on crontab to automate this migration.