atom feed19 messages in org.apache.openjpa.devRe: [VOTE] Turn off enhancement by su...
FromSent OnAttachments
Kevin SutterDec 4, 2008 4:25 pm 
David JencksDec 4, 2008 5:51 pm 
Michael DickDec 4, 2008 7:29 pm 
Jeremy BauerDec 5, 2008 7:07 am 
Albert LeeDec 5, 2008 7:21 am 
Albert LeeDec 5, 2008 7:23 am 
Patrick LinskeyDec 8, 2008 11:11 pm 
Kevin SutterDec 9, 2008 7:19 am 
Patrick LinskeyDec 9, 2008 7:55 am 
Dianne RichardsDec 16, 2008 2:32 pm 
Michael DickMay 20, 2009 9:17 am 
Rick CurtisMay 20, 2009 9:21 am 
Donald WoodsMay 20, 2009 9:44 am 
Pinaki PoddarMay 20, 2009 3:45 pm 
Michael DickMay 20, 2009 7:40 pm 
Kevin SutterMay 21, 2009 6:19 am 
Craig L RussellMay 21, 2009 5:17 pm 
Michael DickJun 10, 2009 11:27 am 
Michael DickJun 10, 2009 11:44 am 
Subject:Re: [VOTE] Turn off enhancement by subclassing as the default
From:Kevin Sutter (
Date:May 21, 2009 6:19:21 am

As some of you from private conversations, I've been waffling on this issue. At first, I was totally on the band wagon to turn the sub-classing support off by default (thus, the reason for the [VOTE] in the first place). But, when I see all of the questions being posted about how to do our enhancement processing, I have to question whether our enhancement processing is the correct way to go -- although it has been proven to kick butt on performance and reliability (as compared to our current sub-classing support).

As Mike has pointed out, we have several JIRA Issues related to the sub-classing support [1]. Although I would be in favor of the sub-classing support if we could the Issues resolved and get the performance inline with our enhancement processing, I just don't see anybody signing up for this piece of work. So, until that happens, I think our only alternative is to turn off the support in both 1.3 and trunk. The way we have it right now allows too many people feel a false sense of security. OpenJPA works out of the box with the simple "hello world" example, but then when they need to push it a little harder they start to run into problems and are required to use the enhancement processing. It's confusing for our customers.

For these reasons, at this point, I feel that we should promote the enhancement processing that works and performs. If and when we can demonstrate that the sub-classing support meets the same level of capabilities, then we can re-visit this issue.

Long explanation for +1 for turning off the sub-classing support by default on both 1.3 and trunk. :-)



On Wed, May 20, 2009 at 9:40 PM, Michael Dick <>wrote:

RuntimeUnenhancedClasses=unsupported is the proposed solution.

Currently there are 14 known issues [1] with unenhanced classes. I'm sure there are other unreported issues, and questions on the mailing lists that could have turned into issues, but that's largely academic.

I think the long term goal is to get to a single strategy : bytecode enhancement or subclassing. Once we've chosen one we should make that strategy as easy to use, functional and perform as well as possible. Maintaining two strategies is not cost effective. I have mixed feelings about which is the better strategy long term though.

The known issues with subclassing and behavioral differences lead me to think that it should be disabled by default at least until the known issues are resolved. The function need not be forgotten, but I don't think it's ready to be the default behavior yet.




On Wed, May 20, 2009 at 5:45 PM, Pinaki Poddar <> wrote:

Hi Kevin,

+1 on 1.3 if you mean "turn off" as openjpa.RuntimeUnenhancedClasses=unsupported.

I am rather ambivalent about trunk though.

Few more aspects that we should take note of: 1. We must recognize the core notion behind runtime enhancement is a strong and useful feature.

2. The available support has its flaws (which is the reason for this discussion being resurrected) -- but more importantly, we do not know the footprint of the incompleteness of this feature. Given that we run our test corpus on enhanced classes only, we basically wait till a user's report is diagnosed as yet another bug caused by this feature.

3. "Turning it off" has the risk of this powerful feature being "forgotten" -- if it turns out so, it will not be a desirable outcome.

----- Pinaki Poddar OpenJPA PMC Member/Committer JPA Expert Group Member

-- View this message in context:

Sent from the OpenJPA Developers mailing list archive at