openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <>
Subject Re: OpenJPA 2.0 vs 1.2
Date Mon, 22 Mar 2010 20:12:01 GMT
Hi Russell,
There should be no reason to change code as you move from OpenJPA 1.2 to
OpenJPA 2.0.  We have had a few "testamonials" in our users and dev mailing
lists confirming this.  The JPA Expert Group really tried to allow for
binary compatibility as we move from JPA 1.0 specification to JPA 2.0.

The exceptions would be in the area of using features in OpenJPA 1.2 that
were beyond the JPA 1.0 spec and the new JPA 2.0 spec defined slightly
different behavior.  For example, in OpenJPA 1.2, we defined a detach()
method on our EM implementation that returned a detached version of the
entity object.  JPA 2.0 defined an in-place detach() method (no return
value).  If you were dependent on the copy aspect of detach(), then you
might need to modify your application or configuration to get the previous

We've attempted to document these type of situations in our manual [1].

Good luck and let us know your results!


On Mon, Mar 22, 2010 at 3:02 PM, Russell Collins <> wrote:

>  I could not find this information so I apologize if there has been a
> discussion and I missed it.  Basically what I am wondering is if OpenJPA 2.0
> is backward compatible with OpenJPA 1.2.  If I were to upgrade my OpenJPA to
> 2.0 would I need to change the code that I have to make it conform to the
> new 2.0 specification?
> *Russell Collins***
> Sr. Software Engineer
> McLane Advanced Technology
> 254.771.6419
> [image: signaturelogo]
> "Do or do not, there is no try." - Yoda
> ------------------------------
> CONFIDENTIALITY NOTICE: The information contained in this electronic mail
> (email) transmission (including attachments), is intended by MCLANE ADVANCED
> TECHNOLOGIES for the use of the named individual or entity to which it is
> addressed and may contain information that is privileged, confidential
> and/or protected as a trade secret. It is not intended for transmission to,
> or receipt by, any individual or entity other than the named addressee(s).
> If you have received this email in error, please delete it (including
> attachments) and any copies thereof without printing, copying or forwarding
> it, and notify the sender of the error by email reply immediately.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message