jakarta-bcel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Davies <rich...@optevo.com>
Subject Re: Dealing with Repository class.
Date Tue, 16 Apr 2002 16:32:29 GMT

m.dahm@4flow.de wrote:

>>First, the problem I ran into.  There are several
>>instances in the BCEL code (and in the Quilt code)
>>which refers to static methods on the Repository
>>for finding information about a class:
>>   getSuperClasses
>>   getInterfaces
>>   instanceOf
>>   implementationOf
>>These methods all use the system classpath.  (Whereas
>>the ClassLoader I was developing used the 
>>What I would like to do, is two fold:
>>  Part 1 - Move those four methods onto the JavaClass
>>  object.  In most circumstances, at least one 
>>  JavaClass is available, and can be used for the
>>  query.
>That would be nice in that it would be more "object-oriented", however,
>the information needs to be gathered somewhere ...
It would also be more consistent with the standard Java APIs where 
java.lang.Class has similar
equivalent methods. When I first started using BCEL, the location of 
these methods in
Repository was a source of confusion for me.

>>  Part 2 - Remove the staticness of the Repository
>>  class, such that more than one Repository can exist.
>>  This will enable two BCEL programs to operate in
>>  the same JVM, which could be helpful as BCEL tasks
>>  end up in Ant scripts.
>That would be OK, but I think that a lot of code is relying on the
>"old" repository. I'd rather make it deprecated and replicate its
>code in a subclassable new repository.
>	Markus

To unsubscribe, e-mail:   <mailto:bcel-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:bcel-dev-help@jakarta.apache.org>

View raw message