commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VFS] Analysis of binary compatibility breaks between 1.0 and 2.0; release strategy
Date Wed, 17 Nov 2010 10:54:49 GMT
On 17 November 2010 07:17, Ralph Goers <ralph.goers@dslextreme.com> wrote:
>
> On Nov 16, 2010, at 4:19 PM, sebb wrote:
>
>> On 17 November 2010 00:06, ralph.goers @dslextreme.com
>> <ralph.goers@dslextreme.com> wrote:
>>> I'm not sure why the tool didn't catch it, but a few methods now return
>>> Map<String, Object> where they previously returned Map. I didn't check
for
>>> generics other than "Map<".
>>
>> Surely these are equivalent at run-time?
>>
>> Generics are a compile-time feature.
>>
>
> See http://www.jroller.com/scolebourne/entry/java_generics_migration_compatibility and
then take a look at the several changes made to add generics to Comparable.  These changes
don't seem to be binary compatible. I'm surprised they didn't show up in the report you ran.

Maybe Clirr does not check fully - after all it was written before Java 5.

But I agreed that once generics are introduced, one needs to be
careful to ensure that source compatibility is also maintained.

Prior to Java 5, I think source compatibility was probably guaranteed
if the code was binary compatible. I don't think it is now.
[The reverse has never been the case - e.g. changing a void method to
return boolean won't affect recompilation, but will affect run-time as
the signature changes - so the method can no longer be found.]

There probably needs to be a tool to check source compatibility.

> I've found several other articles that describe how, under certain circumstances, type
erasure can result in a different type being used than existed in a prior, non-generified
version of the code. I've not fully inspected all teh changes to determine if any of those
cases are present.

Perhaps add the links to a Wiki page where we can collect any such info?

> I'm not suggesting we change these. Since we are adopting Java 5 I would prefer to change
these now and move forward.

To change or not to change? Sorry, cannot understand the last paragraph.

> Ralph
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message