openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Bauer" <>
Subject Re: [VOTE] Turn off enhancement by subclassing as the default
Date Fri, 05 Dec 2008 15:07:57 GMT
+1  Turn off subclass enhancement in trunk
0   Turn off subclass enhancement in 1.3.x

Since the 1.3.x stream has been available for some time, 2.0/trunk seems
like a better place to change default behavior.  But, I don't feel strongly
enough about it to oppose.  :-)


On Thu, Dec 4, 2008 at 6:25 PM, Kevin Sutter <> wrote:

> Hi,
> This is a tough decision, but one that I think we need to make.  If you
> have
> been following the dev mailing list, there have been several discussions
> [1]
> and JIRA Issues [2] about the fallback enhancement by subclassing that we
> put in place back in the 1.0.0 timeframe.  Although we succeeded in making
> the initial out-of-box experience easier for the newbie OpenJPA developer,
> we also masked the need for true enhancement for production usage.  So,
> unless we deem that this subclassing enhancement is critical to OpenJPA's
> acceptance and usage, I propose to turn this option off by default.  The
> ability to do this subclass enhancement will still be available via the
> openjpa.RuntimeUnenhancedClasses property, but the default will now be
> either "warn" or "unsupported" instead of "supported".  I would like to do
> this for trunk for sure and possibly the 1.3.x branch as well.  Please vote
> accordingly.  Thanks for your input.  Write-in comments are also welcome.
> [ +1 | 0 | -1 ]  Turn off subclass enhancement in trunk
> [ +1 | 0 | -1 ]  Turn off subclass enhancement in 1.3.x
> I am not proposing to turn it off in the other branches since those are not
> active development streams, but rather service streams.  We shouldn't
> introduce a change like this into a customer's service stream.  That is,
> for
> a customer to get 1.0.4 with this option turned off would be a surprise
> since they would only be expecting fixes.  Fine line in this case, but you
> get the picture.
> Thanks,
> Kevin
> [1]
> [2],

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