Distinquishing between interfaces and classes *before* loading?

[Steve Wampler]

I've got a simple class loader where I'd like to pass interfaces
to another class loader. Is there a way to tell (from the byte
codes, say) whether or not it's an interface?

Thanks!
-Steve

 

[Andrew Thompson]

I've got a simple class loader where I'd like to pass interfaces
to another class loader. Is there a way to tell (from the byte
codes, say) whether or not it's an interface?

boolean interface =
ClassLoader.findClass("fully.qualified.name").isInterface();

IFAIU

 

[Jesper Nordenberg]

I've got a simple class loader where I'd like to pass interfaces
to another class loader. Is there a way to tell (from the byte
codes, say) whether or not it's an interface?

http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#74353

/Jesper Nordenberg

 

[Chris Uppal]

I've got a simple class loader where I'd like to pass interfaces
to another class loader. Is there a way to tell (from the byte
codes, say) whether or not it's an interface?

If you are willing to mess with the bytecodes then you can find out absolutely
/anything/ you like.

The problem is that decoding the classfile structure is non-trivial. But
fortunately there are several freely available libraries around that will do
the hard work for you, such as Apache BCEL, and the GNU bytecode library.

Googling for:

java bytecode library

will turn up more leads.

-- chris

 

[Steve Wampler]

boolean interface =
ClassLoader.findClass("fully.qualified.name").isInterface();

IFAIU

Thanks, but I *think* findClass calls define class, which is
effectively loading the class. So (someone please let me
know if I'm wrong!!) by the time you get to invoking the
isInterface() method, you've got the class loaded.

-Steve

 

[Andrew Thompson]

....
Thanks, but I *think* findClass calls define class, which is
effectively loading the class.

*

I do not understand the subtle distinction..
You have delivered the bytes of the class
themselves through the class loader..
But you want to avoid creating an actual
Class with the bytes[].. Why?


* Yes, yes.. I noticed that '...*before* loading?'
bit in the subject *after* I had posted, it
pays to ensure every key word of a subject is
mentioned in the body as some people ignore
the subject and others miss it.

 

[Steve Wampler]

I do not understand the subtle distinction..
You have delivered the bytes of the class
themselves through the class loader..
But you want to avoid creating an actual
Class with the bytes[].. Why?

* Yes, yes.. I noticed that '...*before* loading?'
bit in the subject *after* I had posted, it
pays to ensure every key word of a subject is
mentioned in the body as some people ignore
the subject and others miss it.

Sorry!

I thought the statement that I wanted to "pass
interfaces to another class loader" covered it. The
normal ClassLoader implementation means that a
ClassLoader won't load a class if it's already been
loaded (I think). I want interfaces to be shared
between namespaces by having them loaded by a parent
ClassLoader, while classes found by the current class
loader are loaded immediately - effectively isolating
them within the namespace defined by that class loader.

Does that make sense now? I have a hack that works
by putting all 'shared' interfaces into a known location,
but that's really a pretty bad hack. I'm looking for
better alternatives.

 

[Steve Wampler]

http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#74353

Most excellent! Thanks.

 

[Steve Wampler]

....
The problem is that decoding the classfile structure is non-trivial. But
fortunately there are several freely available libraries around that will do
the hard work for you, such as Apache BCEL, and the GNU bytecode library.

Thanks, Chris. BCEL does *exactly* what I need!

My thanks to all who offered suggestions. After looking
at the class file definitions and discovering that the
access fields come after the constant pool info mess, I
decided it would be easer to use someone else's (BCPL)
parser...