You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by David Hovemeyer <da...@cs.umd.edu> on 2004/04/05 15:45:18 UTC
Re: [Fwd: BCEL breaks compatibility]
On Mon, Apr 05, 2004 at 10:36:45AM +0200, Antoine Lévy-Lambert wrote:
> -------- Original Message --------
> Subject: BCEL breaks compatibility
> Date: Sat, 3 Apr 2004 21:54:05 +0800
> From: Niclas Hedhman <ni...@hedhman.org>
> Reply-To: Gump code and data <ge...@gump.apache.org>
> Organization: Private
> To: Gump code and data <ge...@gump.apache.org>
> CC: bcel-dev-subscribe@jakarta.apache.org
>
> Hi,
>
> On the 23 May last year (we are a bit slow), BCEL introduced a incompatible
> change in the CVS.
>
> Details;
> Source file: ./src/java/org/apache/bcel/classfile/JavaClass.java
>
> cvs -q diff -u -r 1.13 -r 1.14
> ./src/java/org/apache/bcel/classfile/JavaClass.java | grep "JavaClass
> getSuperClass"
> - public JavaClass getSuperClass() {
> + public JavaClass getSuperClass() throws ClassNotFoundException {
>
>
> which currently breaks the Avalon Fortress Gump build.
>
> Please advice the status of this particular change.
> Is it going in to a BCEL 6.0?
> Is it a mistake?
Disclaimer: I am not a BCEL developer, so I have no authority
to speak about official policy for the BCEL project. (I.e.,
I have no idea whether this change will be preserved in future
releases.) However, I was the person who submitted the patch that
introduced this incompatibility.
Originally, methods involving repository lookups returned null if
the class couldn't be found. There are two important problems with
this approach:
1. Some of the methods in org.apache.bcel.Repository() would
blindly dereference these null pointers, resulting in
NullPointerExceptions.
2. Some of the methods requiring class methods fundamentally
could not return an accurate result if a class lookup failed.
For example, Repository.instanceOf() and
ReferenceType.isAssignmentCompatibleWith() both return
boolean values. Returning "false" if a class lookup fails
is not a correct result.
Having all methods that perform repository lookups throw
ClassNotFoundException is a good solution. It makes it easy to write
code for the common case (where the lookup succeeds), and also
makes it easy to handle the case where the lookup fails (by
catching the exception).
The downside, of course, is breaking backward compatibility. But,
the original APIs were flawed, and the new behavior is (IMO) better.
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [Fwd: BCEL breaks compatibility]
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 05 April 2004 21:45, David Hovemeyer wrote:
> The downside, of course, is breaking backward compatibility. But,
> the original APIs were flawed, and the new behavior is (IMO) better.
Ok, thanks for the background.
In principal, I can do
try
{
return currentClass.getSuperClass();
} catch( Exception e )
{
return null;
}
in our code. I can't catch ClassCastException, since that is not compatible
with the 5.5 release that we officially depend on.
But it works with reasonable amount of comments - - for us.
Is this a change that are in many other method signatures as well, or just a
few?
If only a few, I would recommend the compatible approach of introducing a
seperate method where the exceptions are thrown, to keep the compatibility.
Well, once the BCEL community can decide and hopefully release, please (if you
remember) CC dev@avalon.apache.org, so we can update the hack.
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: [Fwd: BCEL breaks compatibility]
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 05 April 2004 21:45, David Hovemeyer wrote:
> The downside, of course, is breaking backward compatibility. But,
> the original APIs were flawed, and the new behavior is (IMO) better.
Ok, thanks for the background.
In principal, I can do
try
{
return currentClass.getSuperClass();
} catch( Exception e )
{
return null;
}
in our code. I can't catch ClassCastException, since that is not compatible
with the 5.5 release that we officially depend on.
But it works with reasonable amount of comments - - for us.
Is this a change that are in many other method signatures as well, or just a
few?
If only a few, I would recommend the compatible approach of introducing a
seperate method where the exceptions are thrown, to keep the compatibility.
Well, once the BCEL community can decide and hopefully release, please (if you
remember) CC dev@avalon.apache.org, so we can update the hack.
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org