Detecting if a class is already known

Discussion in 'Java' started by Ross, Jul 29, 2011.

  1. Ross

    Ross Guest

    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?
     
    Ross, Jul 29, 2011
    #1
    1. Advertising

  2. Ross

    markspace Guest

    On 7/29/2011 9:47 AM, Ross wrote:

    > 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/docs/api/java/lang/ClassLoader.html#findLoadedClass%28java.lang.String%29>
     
    markspace, Jul 29, 2011
    #2
    1. Advertising

  3. Ross

    Lew Guest

    markspace wrote:
    > Ross wrote:
    >> However, I don't want to load classes that already exist

    >
    > 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.
    >
    >
    >> private boolean known( String className )

    >
    >
    > <http://download.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html#findLoadedClass%28java.lang.String%29>


    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?

    --
    Lew
     
    Lew, Aug 2, 2011
    #3
  4. Ross

    Arne Vajhøj Guest

    On 7/29/2011 12:47 PM, Ross wrote:
    > 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
     
    Arne Vajhøj, Aug 6, 2011
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Thorsten Meininger
    Replies:
    1
    Views:
    469
    Sudsy
    Oct 13, 2004
  2. Marco Herrn
    Replies:
    14
    Views:
    496
    Peter Otten
    Sep 16, 2003
  3. Gary Wessle

    objects known inside the class

    Gary Wessle, Aug 2, 2006, in forum: C++
    Replies:
    2
    Views:
    306
    Daniel T.
    Aug 2, 2006
  4. Pavel Shved
    Replies:
    11
    Views:
    545
    Pavel Shved
    Nov 12, 2007
  5. Mr SZ
    Replies:
    0
    Views:
    282
    Mr SZ
    Jun 29, 2009
Loading...

Share This Page