Re: Dealing with Repository class.

--- [email protected] wrote:
> Hi,
> 
> > STEP 1 --
> > ---------
> >   Create a new class 
> >      "org.apache.bcel.util.ClassRepository"
> 
> That's actually what I meant.
> 
> >   Modify JavaClass objects to hold reference
> >      to ClassRepository
> 
> Hmm, I don't think they should reference the
> repository since they
> have not necessarily been created this way.
> 

I was thinking the ClassRepository as being 
analagous to the ClassLoader in Java.  It is
helpful to have around the JavaClass, because
the "ObjectType" and "ArrayType" need to have
some visibility on the Repository the class
was created from.

(If you are staring at a Method, and run into
an Exception.  The repository the method came
from, is the only repository where you will
find the exception.)

Unfortunately, I've been working only on the
ClassLoader side of things.  I had not thought
that JavaClasses are buildable outside of the
Repository.

> > STEP 2 --
> > ---------
> >   Deprecate ClassPath class.
> 
> Why? I think it may be still useful.
> 
It appears to me that the ClassPath is mainly
just duplicating the functionality of existing
ClassLoaders.  If there is anything it can
do that a ClassLoader doesn't, I'd like to know.

> >   Deprecate Repository class.
> > 
> >   Rewrite Repository class to use the default
> >   ClassRepository.
> 
> Ok.
>  
> >   Move the following methods to JavaClass:
> >     getSuperClasses
> >     getInterfaces
> >     instanceOf
> >     implementationOf
> 
> That's ok for me.
>  
> >   Reimplement those methods with the stored
> >     ClassRepository
> > 
> > Step 3 and beyond -
> > -------------------
> >   Modify ClassLoader to use the new
> ClassRepository.
> > 
> >   Ensure ObjectType and ArrayType are aware of
> >     the ClassRepository.
> > 
> >   Identify areas of BCEL which currently use the
> >     deprecated methods, and fix.
> 
> I just wonder how much effort this may cause ...
> 
Modifing the ClassLoader to use the new 
ClassRepository is rather straightforward.  (Indeed
it is one of the reasons I would like this change,
so that BCEL ClassLoaders can get at the things 
other ClassLoaders can get to.)

ObjectType and ArrayType is also a very important
change.  (The first patch basically busted these.
They asked for information from the Repository, when
the JavaClass files were loaded from a ClassLoader
and not the Repository.)

The only other area of BCEL which uses the repository,
is in the Verifier.  I figure once everything is
worked out, the solution there should be pretty 
simple.

> 
> Cheers
> 	Markus
> 

I think BCEL should be capable of handling all of
the ClassLoader semantics.  In order to do this 
adequately, some seperation between ClassLoaders
is required (thus the potential for multiple 
ClassRepositories.)

I suppose what we can do, is to create a default
ClassRepository which handles creations of classes
outside of a ClassLoader context.  This Repository
would be accessed as a Singleton.

Additionally, there would be a factory method which
would create a ClassRepository based on a ClassLoader.
(Only one per loader, of course.)

On the JavaClass, the reference to a ClassRepository
could default to the default Repository.  This gives
it an area to attempt to resolve things such as 
superclasses and interfaces.

When a JavaClass is associated with a Repository, then
the repository link changes.  So, when a ClassLoader
based Repository loads a JavaClass, it is never 
returned in a state where the Repository is wrong.

DDP

(It looks better in code, than it does in English.)


__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/