Need better class file support in vfs

[starksm64]

It turns out its a pain to determine the name of a class file identified by a vfs visitation. There can be any number of parents that are not part of the package name, for example:
jmsrar/jms-ra.jar/org/jboss/resource/adapter/jms/inflow/JmsActivation.class

In the AnnotationMetaDataDeployer I'm working on I just ended up using the javassist ClassFile to read the bytes to get the name. This slows down startup time another 50%, and its already too slow. There are other ways to better track what package roots could be, based on the classpath, and maybe that is all that could be done. I was thinking that VirtualFile should support attributes/annotations such that the classpath roots could be annotated to simplify such class file type of processing.

[adrian.brock]

I don't understand why this is difficult?
You already know the root you are visiting from the getClassPath(),
so isn't it just a case of removing it.

Of course, some of the roots maybe nested inside the root you are visiting
(nested deployments), but it should be fairly easy to detect this and ignore
them since you will visit that specific root anyway?

i.e. in your example where you have
jms.rar/jms.jar/package/some.class

So the roots in the getClassPath() woud be
jms.rar
jms.rar/jms.jar

When visiting jms.rar you would ignore the jms.rar/jms.jar because that is in the classpath.
When you visit jms.rar/jms.rar you simply remove the root from the path:
{jms.rar/jms.jar/}package/some.class

[starksm64]

Right, I have to go to external information to determine this. What I was suggesting is that when the classpath roots are identified, the corresponding VirtualFile be annotated as such so that one can just walk up the parents of a .class VirtualFile until its root is found.