You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2016/06/03 09:13:16 UTC

[BCEL] Binary compatibility - approaches to solving the interface changes

I found the Clirr report I did on BCEL:

http://home.apache.org/~sebb/BCEL/clirr-report.html

This compares BCEL trunk with 5.2.
[The 5.2 code was shaded to align the package names.]

As can be seen, the main changes are additions to the Visitor interface.

There are several approaches to fix this:
- require Java 8 and add default implementations to the interface
- update the code to allow for missing methods when using the Visitor
  This requires catching the appropriate Exceptions when calling the
new methods.
- move the new methods into a sub-interface.
 This requires code changes wherever the Visitor is used.

[I suppose one could also drop the new methods entirely.
But I suspect that would remove too much functionality.]

The simplest is likely to be to use Java 8 (but it would need to be
checked out).

But will that exclude too many users?

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


Re: [BCEL] Binary compatibility - approaches to solving the interface changes

Posted by Emmanuel Bourg <eb...@apache.org>.
Le 3/06/2016 � 11:13, sebb a �crit :
> I found the Clirr report I did on BCEL:
> 
> http://home.apache.org/~sebb/BCEL/clirr-report.html
> 
> This compares BCEL trunk with 5.2.
> [The 5.2 code was shaded to align the package names.]
> 
> As can be seen, the main changes are additions to the Visitor interface.


Nobody implements directly the Visitor interface, that's insane there
are too many methods. Users extend the EmptyVisitor class instead. My
position is that it's safe to add the methods. If we can't agree on that
I'd prefer switching to Java 8 with default methods.

Emmanuel Bourg


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