Re: Dealing with Repository class.

[email protected] wrote:

>Hi,
>
>>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 
>>AntClassLoader.)
>>
>>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.
>
>Cheers
>	Markus
>