Re: [VOTE] Turn off enhancement by subclassing as the default

[Michael Dick <mi...@gmail.com>]

Resurrecting this old thread, since there seems to be some activity in the
associated JIRA issue [1]

The results were :

Turn off subclassing in trunk :
+1  Jeremy, Albert, me
+0  No one
-1   No one

Total +3

Turn off subclassing in 1.3.x  :
+1 Me
+0 Jeremy
-1 Albert

Total +0

Any other votes that I've missed?  Based on the "current" results we should
disable subclassing in trunk, 1.3.x is still under discussion..

[1] https://issues.apache.org/jira/browse/OPENJPA-651

-mike

On Tue, Dec 16, 2008 at 5:32 PM, Dianne Richards <di...@gmail.com> wrote:

> All - I've been looking into the Sun 1.6 registration of a transformer as
> mentioned by Patrick and here are the results:
>
> 1. The InstrumentationFactory does a
> Class.forName("com.sun.tools.attach.VirtualMachine") and uses the attach
> method of that class to load the agent.
>
> 2. When I ran it, the initial code in InstrumentationFactory worked. But,
> when I turned off support for RuntimeUnenhancedClasses, it failed later on
> in the process. The only thing my test case is doing is creating an
> EntityManagerFactory and an EntityManager. I'm assuming there are some
> later
> checks that can be enhanced to allow this to work, but I haven't gone that
> far yet.
>
> 3. HOWEVER, the VirtualMachine class is not in the default classpath. It's
> in the lib/tools.jar, which I had to manually add to the classpath in order
> to get this far. So, this is not an out-of-the-box solution.
>
> 4. I also tried this with the IBM jdk 6, since the tools.jar with this
> class
> is also shipped with it. When it tried to attach, I got an
> AttachNotSupportedException with the message "Unable to enqueue operation,
> pre-6.0 jvm.dll?" This doesn't sound too promising.
>
> On Tue, Dec 9, 2008 at 9:55 AM, Patrick Linskey <pl...@gmail.com>
> wrote:
>
> > Excellent question.  To be honest, I didn't know that we ended up with
> >> different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM.
> >>
> >
> > In Sun-ish 1.6 VMs, we can automatically register a class transformer on
> > the fly (see InstrumentationFactory). I don't remember all the subtleties
> of
> > the configuration and the implications on what we can do, but there are
> > definitely differences in the pathways, as we can directly mutate code
> > blocks in 1.6 environments (but maybe we can't add fields and methods?).
> >
> >  Has anybody spent any cycles on that approach?
> >>
> >
> > I haven't investigated one way or the other. I believe that there's a
> table
> > somewhere in the docs that spells out the differences between the various
> > approaches.
> >
> > -Patrick
> >
> >
> > On Dec 9, 2008, at 7:19 AM, Kevin Sutter wrote:
> >
> >  Hi Patrick,
> >>
> >> On Tue, Dec 9, 2008 at 1:11 AM, Patrick Linskey <pl...@gmail.com>
> >> wrote:
> >>
> >>  What is the impact of your proposal on people who are using Sun-ish 1.6
> >>> VMs, which have on-the-fly class redefinition support?
> >>>
> >>> Put another way, to what extent have you considered the differences in
> >>> flakiness between the 1.5-friendly subclassing approach and the
> >>> 1.6-needing
> >>> redefinition approach?
> >>>
> >>>
> >> Excellent question.  To be honest, I didn't know that we ended up with
> >> different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM.  I
> >> thought the reported problems were equally applied to both JVM versions.
> >>  Do
> >> we know that the 1.6 redefinition capabilities avoid the reported
> >> problems?
> >> Has anybody spent any cycles on that approach?
> >>
> >> Maybe something to think about is to turn off the subclassing support
> for
> >> the 1.5 JVM and leave the class redefinition support on for the 1.6 JVM?
> >>  I
> >> really don't know enough about these alternate approaches to make that
> >> kind
> >> of statement at this point.
> >>
> >> Other thoughts?
> >>
> >> Thanks,
> >> Kevin
> >>
> >>
> >>  -Patrick
> >>>
> >>> On Dec 4, 2008, at 4: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]
> >>>>
> >>>>
> >>>>
> http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
> >>>> [2]       http://issues.apache.org/jira/browse/OPENJPA-651,
> >>>> http://issues.apache.org/jira/browse/OPENJPA-650,
> >>>> https://issues.apache.org/jira/browse/OPENJPA-293
> >>>>
> >>>>
> >>> --
> >>> Patrick Linskey
> >>> 202 669 5907
> >>>
> >>>
> >>>
> > --
> > Patrick Linskey
> > 202 669 5907
> >
> >
>
>
> --
> Thanks - Dianne
>

Re: [VOTE] Turn off enhancement by subclassing as the default

[Rick Curtis <cu...@gmail.com>]

+1 Turn off subclass enhancement in trunk
+1 Turn off subclass enhancement in 1.3.x

-Rick
-- 
View this message in context: http://n2.nabble.com/-VOTE--Turn-off-enhancement-by-subclassing-as-the-default-tp1616140p2947145.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.

Re: [VOTE] Turn off enhancement by subclassing as the default

[Donald Woods <dw...@apache.org>]

+1 to turn of subclassing in trunk AND 1.3.x


-Donald


Michael Dick wrote:
> Resurrecting this old thread, since there seems to be some activity in the
> associated JIRA issue [1]
> 
> The results were :
> 
> Turn off subclassing in trunk :
> +1  Jeremy, Albert, me
> +0  No one
> -1   No one
> 
> Total +3
> 
> Turn off subclassing in 1.3.x  :
> +1 Me
> +0 Jeremy
> -1 Albert
> 
> Total +0
> 
> Any other votes that I've missed?  Based on the "current" results we should
> disable subclassing in trunk, 1.3.x is still under discussion..
> 
> [1] https://issues.apache.org/jira/browse/OPENJPA-651
> 
> -mike
> 
> On Tue, Dec 16, 2008 at 5:32 PM, Dianne Richards <di...@gmail.com> wrote:
> 
>> All - I've been looking into the Sun 1.6 registration of a transformer as
>> mentioned by Patrick and here are the results:
>>
>> 1. The InstrumentationFactory does a
>> Class.forName("com.sun.tools.attach.VirtualMachine") and uses the attach
>> method of that class to load the agent.
>>
>> 2. When I ran it, the initial code in InstrumentationFactory worked. But,
>> when I turned off support for RuntimeUnenhancedClasses, it failed later on
>> in the process. The only thing my test case is doing is creating an
>> EntityManagerFactory and an EntityManager. I'm assuming there are some
>> later
>> checks that can be enhanced to allow this to work, but I haven't gone that
>> far yet.
>>
>> 3. HOWEVER, the VirtualMachine class is not in the default classpath. It's
>> in the lib/tools.jar, which I had to manually add to the classpath in order
>> to get this far. So, this is not an out-of-the-box solution.
>>
>> 4. I also tried this with the IBM jdk 6, since the tools.jar with this
>> class
>> is also shipped with it. When it tried to attach, I got an
>> AttachNotSupportedException with the message "Unable to enqueue operation,
>> pre-6.0 jvm.dll?" This doesn't sound too promising.
>>
>> On Tue, Dec 9, 2008 at 9:55 AM, Patrick Linskey <pl...@gmail.com>
>> wrote:
>>
>>> Excellent question.  To be honest, I didn't know that we ended up with
>>>> different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM.
>>>>
>>> In Sun-ish 1.6 VMs, we can automatically register a class transformer on
>>> the fly (see InstrumentationFactory). I don't remember all the subtleties
>> of
>>> the configuration and the implications on what we can do, but there are
>>> definitely differences in the pathways, as we can directly mutate code
>>> blocks in 1.6 environments (but maybe we can't add fields and methods?).
>>>
>>>  Has anybody spent any cycles on that approach?
>>> I haven't investigated one way or the other. I believe that there's a
>> table
>>> somewhere in the docs that spells out the differences between the various
>>> approaches.
>>>
>>> -Patrick
>>>
>>>
>>> On Dec 9, 2008, at 7:19 AM, Kevin Sutter wrote:
>>>
>>>  Hi Patrick,
>>>> On Tue, Dec 9, 2008 at 1:11 AM, Patrick Linskey <pl...@gmail.com>
>>>> wrote:
>>>>
>>>>  What is the impact of your proposal on people who are using Sun-ish 1.6
>>>>> VMs, which have on-the-fly class redefinition support?
>>>>>
>>>>> Put another way, to what extent have you considered the differences in
>>>>> flakiness between the 1.5-friendly subclassing approach and the
>>>>> 1.6-needing
>>>>> redefinition approach?
>>>>>
>>>>>
>>>> Excellent question.  To be honest, I didn't know that we ended up with
>>>> different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM.  I
>>>> thought the reported problems were equally applied to both JVM versions.
>>>>  Do
>>>> we know that the 1.6 redefinition capabilities avoid the reported
>>>> problems?
>>>> Has anybody spent any cycles on that approach?
>>>>
>>>> Maybe something to think about is to turn off the subclassing support
>> for
>>>> the 1.5 JVM and leave the class redefinition support on for the 1.6 JVM?
>>>>  I
>>>> really don't know enough about these alternate approaches to make that
>>>> kind
>>>> of statement at this point.
>>>>
>>>> Other thoughts?
>>>>
>>>> Thanks,
>>>> Kevin
>>>>
>>>>
>>>>  -Patrick
>>>>> On Dec 4, 2008, at 4: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]
>>>>>>
>>>>>>
>>>>>>
>> http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
>>>>>> [2]       http://issues.apache.org/jira/browse/OPENJPA-651,
>>>>>> http://issues.apache.org/jira/browse/OPENJPA-650,
>>>>>> https://issues.apache.org/jira/browse/OPENJPA-293
>>>>>>
>>>>>>
>>>>> --
>>>>> Patrick Linskey
>>>>> 202 669 5907
>>>>>
>>>>>
>>>>>
>>> --
>>> Patrick Linskey
>>> 202 669 5907
>>>
>>>
>>
>> --
>> Thanks - Dianne
>>
>