|Kevin Sutter||Dec 4, 2008 4:25 pm|
|David Jencks||Dec 4, 2008 5:51 pm|
|Michael Dick||Dec 4, 2008 7:29 pm|
|Jeremy Bauer||Dec 5, 2008 7:07 am|
|Albert Lee||Dec 5, 2008 7:21 am|
|Albert Lee||Dec 5, 2008 7:23 am|
|Patrick Linskey||Dec 8, 2008 11:11 pm|
|Kevin Sutter||Dec 9, 2008 7:19 am|
|Patrick Linskey||Dec 9, 2008 7:55 am|
|Dianne Richards||Dec 16, 2008 2:32 pm|
|Michael Dick||May 20, 2009 9:17 am|
|Rick Curtis||May 20, 2009 9:21 am|
|Donald Woods||May 20, 2009 9:44 am|
|Pinaki Poddar||May 20, 2009 3:45 pm|
|Michael Dick||May 20, 2009 7:40 pm|
|Kevin Sutter||May 21, 2009 6:19 am|
|Craig L Russell||May 21, 2009 5:17 pm|
|Michael Dick||Jun 10, 2009 11:27 am|
|Michael Dick||Jun 10, 2009 11:44 am|
|Subject:||Re: [VOTE] Turn off enhancement by subclassing as the default|
|From:||Kevin Sutter (kwsu...@gmail.com)|
|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 . 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 <mich...@gmail.com>wrote:
RuntimeUnenhancedClasses=unsupported is the proposed solution.
Currently there are 14 known issues  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 <ppod...@apache.org> wrote:
+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:
Sent from the OpenJPA Developers mailing list archive at Nabble.com.