Re: Dealing with Repository class.

Hi,
I think it is the best way to implement any class  lookup:
public static JavaClass lookupClass(String class_name, ClassLoader loader) {

if(class_name == null || class_name.equals(""))

throw new RuntimeException("Invalid class name");

class_name = class_name.replace('/', '.');

Key key = new Key(class_name,loader);

JavaClass clazz = (JavaClass)classes.get(key);

if(clazz == null) {

try {

InputStream is = loader.getResourceAsStream(class_name);

clazz = new ClassParser(is, class_name).parse();

class_name = clazz.getClassName();

} catch(IOException e) { return null; }

classes.put(key ,clazz);

}



>
> --- [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/
>
> --
> To unsubscribe, e-mail:   <mailto:[email protected]>
> For additional commands, e-mail: <mailto:[email protected]>