Mailing-List: contact general-help@gump.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Gump code and data" <general@gump.apache.org>
Date: Mon, 5 Apr 2004 09:45:18 -0400
From: David Hovemeyer <daveho@cs.umd.edu>
To: BCEL Developers List <bcel-dev@jakarta.apache.org>
Cc: Niclas Hedhman <niclas@hedhman.org>,
        Gump code and data <general@gump.apache.org>
Subject: Re: [Fwd: BCEL breaks compatibility]
Message-ID: <20040405134518.GA7566@cs.umd.edu>
References: <40711A9D.1020704@antbuild.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <40711A9D.1020704@antbuild.com>
User-Agent: Mutt/1.4.1i

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