Detecting if a class is already known

[Ross]

Hi all.

I'm building a plugin loader. I want this loader to be able to load
from .jar files, which may contain multiple classes per plugin. So,
all of these classes need to be loaded in.

However, I don't want to load classes that already exist, e.g. I don't
want there to be the possibility of plugins loading classes which
would conflict with classes already part of the application.

I can easily check if classes are already present in the classpath by
using a method such as:

private boolean known( String className )
{
try
{
Class c = Class.forName( className );
return true;
}
catch( ClassNotFoundException cnfe )
{
return false;
}
}

This will cause a plugin to be rejected if it includes any class which
can be found. But, since plugins should really contain classes defined
in a unique package, I don't think this will cause a problem.

Is there a better way of identifying if plugins are redefining
existing classes, or otherwise creating a potential problem? Or, is
there no possibility of a potential conflict due to the way that
custom classloaders work?

 

[markspace]

However, I don't want to load classes that already exist

This is already covered by the ClassLoader docs. You can also search
for a tutorial how it all works, but basically you overload findClass
and don't touch the other methods and it all works out. loadClass
automatically searches for existing classes first, then only calls
findClass if it needs too. IIRC.

private boolean known( String className )

<http://download.oracle.com/javase/7...Loader.html#findLoadedClass(java.lang.String)>

 

[Lew]

This is already covered by the ClassLoader docs. You can also search

And by the default classloader behavior.

for a tutorial how it all works, but basically you overload findClass
and don't touch the other methods and it all works out. loadClass
automatically searches for existing classes first, then only calls
findClass if it needs too. IIRC.




<http://download.oracle.com/javase/7...Loader.html#findLoadedClass(java.lang.String)>

I'm not even sure he needs to do anything new to the classloader. The default classloader action is to not load a class it already has. So what new is needed?

 

[Arne Vajhøj]

I'm building a plugin loader. I want this loader to be able to load
from .jar files, which may contain multiple classes per plugin. So,
all of these classes need to be loaded in.

However, I don't want to load classes that already exist, e.g. I don't
want there to be the possibility of plugins loading classes which
would conflict with classes already part of the application.

I can easily check if classes are already present in the classpath by
using a method such as:

private boolean known( String className )
{
try
{
Class c = Class.forName( className );
return true;
}
catch( ClassNotFoundException cnfe )
{
return false;
}
}

This will cause a plugin to be rejected if it includes any class which
can be found. But, since plugins should really contain classes defined
in a unique package, I don't think this will cause a problem.

Is there a better way of identifying if plugins are redefining
existing classes, or otherwise creating a potential problem? Or, is
there no possibility of a potential conflict due to the way that
custom classloaders work?

The problem you are trying to avoid will never happen.

You should not load every class but only load the plugin
"start" class.

In case of the same class being in more than one plugin:

If plugins use same classloader then it will be loaded
once from the first definition in classpath.

If the plugins use different classloaders then it will
be loaded as independent classes (classes in memory are
implicit prefixed with classloader) for each plugin.

If your plugins may end up being heavy and using lots of
stuff which would increase the risk of conflicts (the realistic
scenario is that one plugin uses framework ABC in version X
and another plugin uses framework ABC in version Y), then
you should consider multiple classloaders.

Arne