Re: [groovy-dev] breaking change for GroovyResultSet

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] breaking change for GroovyResultSet

tugwilson

On 17 Jan 2007, at 20:32, Jochen Theodorou wrote:

> Hi,
>
> I changed GroovyResultSet into an interface and added some dynamic  
> proxy logic to keep it running. This way the build should work  
> under 1.6 now.
>
> But it is a breaking change, since the former class is now a  
> interface. What do you think?

This breaks because GroovyResultSet no longer extends ResultSet and  
so it's possible that this will break Java code - is that so?


Is there any other reason for breakage?


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Re: [groovy-dev] breaking change for GroovyResultSet

Jochen Theodorou
John Wilson schrieb:

>
> On 17 Jan 2007, at 20:32, Jochen Theodorou wrote:
>
>> Hi,
>>
>> I changed GroovyResultSet into an interface and added some dynamic
>> proxy logic to keep it running. This way the build should work under
>> 1.6 now.
>>
>> But it is a breaking change, since the former class is now a
>> interface. What do you think?
>
> This breaks because GroovyResultSet no longer extends ResultSet and so
> it's possible that this will break Java code - is that so?
>
>
> Is there any other reason for breakage?

it breaks because GroovyResultSet was a class and is no longer one. It
shouldn't make a difference for most useres. People extending
GroovyResultSet would have to change their code to

class Foo extends GroovyResultSetExtension implements GroovyResultSet

or

class Foo implements GroovyResultSet

And People who want to create instances of GroovyResultSet now have to
write:

new GroovyResultSetProxy(rs).getImpl()

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Re: [groovy-dev] breaking change for GroovyResultSet

tugwilson

On 18 Jan 2007, at 08:18, Jochen Theodorou wrote:

> John Wilson schrieb:
>> On 17 Jan 2007, at 20:32, Jochen Theodorou wrote:
>>> Hi,
>>>
>>> I changed GroovyResultSet into an interface and added some  
>>> dynamic proxy logic to keep it running. This way the build should  
>>> work under 1.6 now.
>>>
>>> But it is a breaking change, since the former class is now a  
>>> interface. What do you think?
>> This breaks because GroovyResultSet no longer extends ResultSet  
>> and so it's possible that this will break Java code - is that so?
>> Is there any other reason for breakage?
>
> it breaks because GroovyResultSet was a class and is no longer one.  
> It shouldn't make a difference for most useres. People extending  
> GroovyResultSet would have to change their code to


We considered keeping it a class and not implementing ResultSet  
(which would also break some Java code). The modified class could  
implement invokeMethod and dispatch these calls to the Metaclass of  
the delegate ResultSet. This would mean that Java 6 methods would be  
available from Groovy.

The above mechanism has the advantage of being a very small change  
(perhaps 10 lines of code).

What are the pros and cons of the two solutions?

I think the proxy solution may introduce less breakage than the one  
above - is it worth the extra complexity?


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Re: [groovy-dev] breaking change for GroovyResultSet

Jochen Theodorou
John Wilson schrieb:
[...]
> We considered keeping it a class and not implementing ResultSet (which
> would also break some Java code). The modified class could implement
> invokeMethod and dispatch these calls to the Metaclass of the delegate
> ResultSet. This would mean that Java 6 methods would be available from
> Groovy.
>
> The above mechanism has the advantage of being a very small change
> (perhaps 10 lines of code).

and you want to keep these hundreds of methods of the pattern:

public X Y(...) {
   return getResultSet().Y(...)
}

you really want to?

> What are the pros and cons of the two solutions?

Ye Old:
   pro:
     * it is like 1.0
   con:
     * does not compile on java6 and most possibly results in runtime
errors if the java6 methods are called.
     * requires explcicit maintining of the methods to keep it in sync
with ResultSet

The Proxy:
   pro:
     * it is a ResultSet to Java, so any Java method working on
ResultSets can be used directly.
     * any metohd can be used, from Java and from Groovy
     * compiles on any java we traget
     * no maintining of the methods needed unles we want to overwrite
something
   con:
     * may break 1.0 code
     * slower than the old version

the MetaClass:
   pro:
     * compiles on any java we traget
     * allows Groovy to call java6 methods
   con:
     * may break 1.0 code
     * we loose compatibilty to ResultSet
     * slower than the old version
     * requires explcicit maintining of the methods to keep it in sync
with ResultSet


> I think the proxy solution may introduce less breakage than the one
> above - is it worth the extra complexity?

I think it is.

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

[groovy-dev] Re: Re: [groovy-dev] breaking change for GroovyResultSet

tugwilson

On 18 Jan 2007, at 08:56, Jochen Theodorou wrote:

> John Wilson schrieb:
> [...]
>> We considered keeping it a class and not implementing ResultSet  
>> (which would also break some Java code). The modified class could  
>> implement invokeMethod and dispatch these calls to the Metaclass  
>> of the delegate ResultSet. This would mean that Java 6 methods  
>> would be available from Groovy.
>> The above mechanism has the advantage of being a very small change  
>> (perhaps 10 lines of code).
>
> and you want to keep these hundreds of methods of the pattern:
>
> public X Y(...) {
>   return getResultSet().Y(...)
> }
>
> you really want to?
>
>> What are the pros and cons of the two solutions?
>
> Ye Old:
>   pro:
>     * it is like 1.0
>   con:
>     * does not compile on java6 and most possibly results in  
> runtime errors if the java6 methods are called.
>     * requires explcicit maintining of the methods to keep it in  
> sync with ResultSet

The maintenance business is no big deal - IDEs do this for you  
trivially.

>
> The Proxy:
>   pro:
>     * it is a ResultSet to Java, so any Java method working on  
> ResultSets can be used directly.
>     * any metohd can be used, from Java and from Groovy
I think this is a big win

>     * compiles on any java we traget
>     * no maintining of the methods needed unles we want to  
> overwrite something
>   con:
>     * may break 1.0 code
>     * slower than the old version
>
> the MetaClass:
>   pro:
>     * compiles on any java we traget
>     * allows Groovy to call java6 methods
>   con:
>     * may break 1.0 code
>     * we loose compatibilty to ResultSet
This is certainly a problem
>     * slower than the old version
>     * requires explcicit maintining of the methods to keep it in  
> sync with ResultSet
IDEs help a lot with this so it's no big deal
>
>
>> I think the proxy solution may introduce less breakage than the  
>> one above - is it worth the extra complexity?
>
> I think it is.


Ok thanks for the analysis.

I'm concerned that the proxy mechanism requires a quite substantial  
change to the system (4872=>8473).

I'm not sure that there was a general consensus that not being able  
to compile the system on JDK 1.6 was a big enough problem to make a  
major change to the system.

I'm sure that everybody agrees that not being able to run on JDK 1.6  
would be a show stopper but our current implementation does run on  
JDK 1.6.

If we kept our current implementation and did the invokeMethod  
delegation to the MetaClass of the delegated ResultSet we would get  
the following

pro:
    - trivial change to the 1.0 code base
    - will not break 1.0 code
    - all JDK 1.6 methods callable from Groovy when running on 1.6
   - runs at same speed as 1.0
con:
    - the Groovy system will not compile on JDK 1.6
    - Java code can call the pre JDK 1.6 methods on GroovyResultSet  
but not the JDK 1.6 methods (this will throw an exception)

what's your view on this vs the proxy stuff?


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Re: Re: [groovy-dev] breaking change for GroovyResultSet

Russel Winder
On Thu, 2007-01-18 at 09:52 +0000, John Wilson wrote:

> I'm not sure that there was a general consensus that not being able  
> to compile the system on JDK 1.6 was a big enough problem to make a  
> major change to the system.

Not being able to compile Groovy on Java SE 6 is a showstopper and total
blocker for me.  I have a hack to permit continued working but this
means I effectively have a personal fork and this is not good.

--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment