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:
[snip]
> 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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
