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. :-) Kevin [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12313257 On Wed, May 20, 2009 at 9:40 PM, Michael Dick <[email protected]>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] > > http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=12310351&sorter/order=DESC&sorter/field=priority&resolution=-1&component=12312835 > > Regards, > > -mike > > On Wed, May 20, 2009 at 5:45 PM, Pinaki Poddar <[email protected]> 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 http://ppoddar.blogspot.com/ > > > > http://www.linkedin.com/in/pinakipoddar > > OpenJPA PMC Member/Committer > > JPA Expert Group Member > > -- > > View this message in context: > > > http://n2.nabble.com/-VOTE--Turn-off-enhancement-by-subclassing-as-the-default-tp1616140p2949153.html > > Sent from the OpenJPA Developers mailing list archive at Nabble.com. > > > > >
