commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [dbutils] binary compatibility
Date Wed, 04 Nov 2009 08:09:38 GMT
Dan Fabulich wrote at Dienstag, 3. November 2009 21:03:

> Jörg Schaible wrote:
>> Is it binary backward compatible?
> I think it is, but I'm not 100% certain; it's confusing.
> I ran clirr on dbutils-1.2 and my locally built 1.3-SNAPSHOT; it found one
> clear compatibility error which I just fixed (DBUTILS-61).  This is what
> it says as of r832529:


> All of the errors are complaints about covariant return types. In each
> case, something that used to return an Object now returns a more specific
> type (e.g. List or Object[]).
> But it's confusing, because Java handles covariant return types by
> generating replacement methods in the bytecode.  So there IS still a
> method that returns Object in the bytecode.
> For example, according to Jad, BeanListHandler.class decompiles like this:
>    public List handle(ResultSet rs) throws SQLException {
>      return convert.toBeanList(rs, type);
>    }
>    public volatile Object handle(ResultSet resultset) throws SQLException
>    {
>      return handle(resultset);
>    }
> Strangely, Clirr is reporting this as an ERROR that the method has
> changed, followed by an INFO remark that a new method was added that just
> happens to be exactly like the old method!  (I guess the new signature
> isn't exactly the same, since it is marked "volatile" ...?)
> I believe none of these errors are really errors.  I tested this by
> creating a subclass of KeyedHandler like this:
>    public class MyKeyedHandler extends KeyedHandler {
>      public boolean hit = false;
>      @Override
>      protected Object createRow(ResultSet rs) throws SQLException {
>        hit = true;
>        return super.createRow(rs);
>      }
>    }
> I used that to create a jar called "backcompat.jar"
> I then copied KeyedHandlerTest from 1.2 and changed it to refer to
> MyKeyedHandler.  I also added assertions that "hit" turned to true when it
> was invoked.  I ran the test against 1.2 and backcompat.jar and it passed;
> then I replaced the 1.2 jar with the 1.3 jar and it again passed, with no
> changes to backcompat.jar.
> So it seems to me that all of these errors aren't really errors, but
> rather bugs in clirr.

Maybe you can use the src tarball from 1.2, change group and artifact id to
something local, drop the Java source from main and add 1.3-SNAPSHOT as
dependency. Then you should be able to run with this POM the tests of 1.2
with code base of 1.3. I simply have currently no svn access (internal
problem) to checkout dbutils trunk otherwise I'd done this myself.

I think your conclusion is right, but we should be sure before releasing 1.3
as possible drop in for older versions.

- Jörg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message