Discussions

News: New high performance ORM for Java: Ujorm

Bookmark and Share Get thread feed

  1. New high performance ORM for Java: Ujorm (18 messages)

    • Posted by: Paul Ponec
    • Posted on: September 01 2009 10:23 EDT
    Let me to introduce a new open source ORM framework for Java called Ujorm. I have created the ORM solution especially for a rapid development of persistent layer, however the first performance tests show that some types of SELECT query are very fast in comparison to its competitors. Next features are: the type safe parameters in the query, small memory footprint and the minimum size of the entire solution. After the publication of UJO architecture it became clear that it would be difficult to gain the favor of developers, without more services. Therefore I started to form a new ORM solution that would evaluate its interesting features and I believe now this result has much to offer. I hope that you will not be angry if I compare my solution with the popular Hibernate. The motivation presentation is here: http://ujoframework.org/presentation/ The test results are listed in the presentation as well as a description of the test environment. See a description of test actions:
    • single select - a one big select for all order items (with a condition)
    • empty selects - 2000 selects with the empty result - where a condition contains different parameter values
    • multi select - many different selects to emulate a server application or statements with no optimization
    • insert - insert 2000 orders, 14000 items and 1 user
    • delete - execution many statements to delete all table rows
    • update - modify and save a loaded BO
    Your suggestions and comments are welcome. If you are interested to cooperation please contact the author at: ujoframework(at)gmail.com . ORM home page: http://ujoframework.org/orm/ Link to the source code: https://sourceforge.net/projects/ujoframework/files/ Link to FAQ: http://ujoframework.org/dokuwiki/doku.php?id=orm_faq Pavel
    Reply to this

    Threaded Messages (18)

  2. better performance?[ Go to top ]

    Although I have no experience comparing different OR solutions on exactly the same database, I would expect that the database is the major factor in the performance. Can you elaborate why Ujorm is faster than Hibernate/EclipseLink for example? Peter Veentjer Multiverse Software Transactional Memory. PS: I would remove the Google adds from the site. It reduces the professional appearance of the product imho.
    Reply to this Reply to original

  3. Re: better performance?[ Go to top ]

    Can you elaborate why Ujorm is faster than Hibernate/EclipseLink for example?
    I think the Ujorm has two main features which affect positively the performance:
    • the rapid build SQL query without parsing a text command
    • Ujorm does not use Java reflection when working with BO objects
    Reply to this Reply to original

  4. Re: better performance?[ Go to top ]

    Ujorm does not use Java reflection when working with BO objects
    and this argument is highly questionable as well, nowadays...
    Reply to this Reply to original

  5. Re: Ujorm does not use Java reflection[ Go to top ]

    and this argument is highly questionable
    I do not understand where you see the problem? Framework reads and writes data without a reflection. Verify it in the source code.
    Reply to this Reply to original

  6. Re: Ujorm does not use Java reflection[ Go to top ]

    and this argument is highly questionable

    I do not understand where you see the problem? Framework reads and writes data without a reflection. Verify it in the source code.
    I think the point was that avoiding reflection is a questionable goal. A lot of work has been put into making reflection very fast in the JVM. From what I understand, the overhead of reflection is pretty small in even 1.4.
    Reply to this Reply to original

  7. Re: Ujorm does not use Java reflection[ Go to top ]

    Framework reads and writes data without a reflection.
    This may be a little off topic, but what is it with you developers lately? Is misusing articles the new 'hip' style of wRiTInG? What about just: "The framework reads and writes data without reflection" ?
    Reply to this Reply to original

  8. Re: Ujorm does not use Java reflection[ Go to top ]

    the tests need to me elaborated. we need to try is on different databases with different combination. initial look for the framework seems interesting.
    Reply to this Reply to original

  9. Quick comments[ Go to top ]

    Can you elaborate why Ujorm is faster than Hibernate/EclipseLink for example?

    I think the Ujorm has two main features which affect positively the performance:
    • the rapid build SQL query without parsing a text command
    • Ujorm does not use Java reflection when working with BO objects
    I'm sure Ujorm can perform better at certain situations, but for the record:
    • Hibernate can run without parsing text-commands in runtime (Criteria API or NamedQueries)
    • Hibernate can avoid reflection on BOs by using Getters/Setters (access="property")
    Reply to this Reply to original

  10. Re: Quick comments[ Go to top ]

    Hibernate can avoid reflection on BOs by using Getters/Setters (access="property")

    11. Doesn't Hibernate use reflection to call getters and setters?
Reply to this Reply to original

  • JPA[ Go to top ]

    One of the reasons why Sun and the JSR/JCP process created JPA was to remove company-specific implementations and create a single standard that supported company-specific extensions. This allows companies to design to a single API (at least in theory, although in practice, you end up using specific extensions anyways, but JPA 2.0 hopefully will fix some of that). Not only does this make switching APIs easier, it also makes development easier when changing from one product to another that uses a different implementation. As much as a improving performance is always a key point, unless it adheres to JPA, I don't think adoption will be strong. If you can adhere to the JPA spec and still gain performance, then I think the product definately has its value. Plus, existing products can more easily switch to take advantage of your product.
    Reply to this Reply to original

  • Re: JPA[ Go to top ]

    • Being a standard (or a proposed one) is not per-se sufficient to justify its adoption. JDO/2 was also a candidate (a far better one, in my opinion) to be the standard ORM technology. It did not win the match vs. Hibernate and JPA is a shallow, lame, broken copy of Hibernate.
    • Standards have often been surpassed by independent research: dependency injection (PicoContainer, Spring, etc.) are a very good proof of this statement. JEE5 had to catch up with them, not the other way around.
    • JPA is bound to POJOs. The approach this framework attempts is instead to support other technologies. Dynamic SDOs are a nice example of where this framework could fit: SDO DMS, for example.
    Ciao, Alessandro
    Reply to this Reply to original

  • Re: New high performance ORM for Java: Ujorm[ Go to top ]

    I like Ujorm. No XML, no bytecode generation at runtime, it's easy to understand and debug... How would you do self-joins? I mean an join from a table to itself. The Criterion API is good. In my own small ORM tool (JaQu, http://h2database.com/html/jaqu.html) I plan to implement 'decompile the condition'. Example: final Person p = new Person(); db.from(p).where(new Filter() { public boolean where() { return p.id == x && p.name.equals(y)); }}).selectCount(); (Unlike in regular Java, you could also use p.name == y). The 'decompile' approach is specially nice for Scala. Not so much for Java that doesn't support closures. JaQu already supports this syntax: Customer c = new Customer(); List waCustomers = db.from(c).where(c.region).is("WA").select();
    Reply to this Reply to original

  • Re: New high performance ORM for Java: Ujorm[ Go to top ]

    I cannot understand why a query should not be written in the Standard Query Language, but written in that manner! IMHO it should be more readable and concise: SELECT COUNT(*) FROM PERSON P WHERE P.ID =:X AND P.NAME = :Y Than: final Person p = new Person(); db.from(p).where(new Filter() { public boolean where() { return p.id == x && p.name.equals(y)); }}).selectCount(); or not? Hibernate support the getQuery() and getSQLQuery() functions, and it is very useful for people that likes the good old SQL. Bye Michele
    Reply to this Reply to original

  • Re: New high performance ORM for Java: Ujorm[ Go to top ]

    why a query should not be written in [SQL]
    Good question. It should be written in SQL (Structured Query Language). The problems are: - auto-complete in the IDE - type checking performed by the compiler - protects against SQL injection So the question is how to integrate the SQL DSL into the host language (Java for example). JaQu tries to do that, it is not perfect (only 80% LINQ). With Scala you could probably get 95% LINQ.
    Reply to this Reply to original

  • Re: New high performance ORM for Java: Ujorm[ Go to top ]

    How well does it integrate with Wicket?
    Reply to this Reply to original

  • Re: join from a table to itself[ Go to top ]

    The solution is a mapping a BO to the native SQL query by a @View annotation now. I will try to develop some alternative way in a future release.
    I like Ujorm
    Thank you, I appreciate it.
    Reply to this Reply to original

  • Re: New high performance ORM for Java: Ujorm[ Go to top ]

    JTA supported? No? Bye... sorry to sound rude, but it is as easy as that...
    Reply to this Reply to original

  • Transaction scope[ Go to top ]

    All database DML statements can be seen as temporary until they are committed. Ujorm supports commitment with the Ujorm Session.commit() . Method Session.rollback() is used to remove operations performed since the previous commit or rollback. Use this method when an exception occurs or when the program detects some error condition or error in the data. For a parallel transaction use a next session. See a JDBC 2.0 documentation for more information.
    Reply to this Reply to original