gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Hovemeyer <dav...@cs.umd.edu>
Subject Re: [Fwd: BCEL breaks compatibility]
Date Mon, 05 Apr 2004 13:45:18 GMT
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 <niclas@hedhman.org>
> Reply-To: 	Gump code and data <general@gump.apache.org>
> Organization: 	Private
> To: 	Gump code and data <general@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


Mime
View raw message