openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <>
Subject Re: [VOTE] Turn off enhancement by subclassing as the default
Date Thu, 21 May 2009 13:19:21 GMT
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

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.
> [1]
> Regards,
> -mike
> 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
> >
> >

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