Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #29462

Re: dealing with ClassLoaders...

Show all headers | View raw

On Thu, 31 Jul 2014 19:40:18 +0000, Andreas Leitgeb wrote:

> All the classes of my app are principially loadable by the system's
> default ClassLoader (i.e. they are in the java.class.path).  Some Main
> class (mypackage.Main) of my app will even be loaded, and this class
> will then create a new Thread with a custom ClassLoader that is supposed
> to load all the other used classes of my app's packages (while still
> delegating loading of newly used system classes to its parent).
> 
> The classloader tutorials I skimmed so far seem to imply, that a custom
> classloader is only appropriate to enable classloading from sources that
> the system classloader cannot handle itself.
>
This sounds similar to something I've done a couple of times now when I 
wanted to put a number of related but separate programs and their 
supporting classes into a jar file and then, at runtime, select the one 
to be run via the command line.

The manifest Main-Class names single, top level launcher class. This is  
passed the name of the program to be run plus any options and arguments 
it needs via the argv[] array. The launcher class then does the following 
to launch the program:

   try
   {
      String fullAppName = PACKAGE + "." + argv[0];
      MAClassLoader  loader = new MAClassLoader();
      Class          target = loader.loadClass(fullAppName);
      MAApplication  app = (MAApplication)target.newInstance();
      String argList[] = new String[argv.length - 1];
      for (int i = 1; i < argv.length; i++)
         argList[i-1] = argv[i];
            
      app.run(argList);
   }
   catch (Exception e)
   {
      System.out.stderr.println(e.toString());
   }

I've omitted the rest of main() because it only does obvious, application-
specific stuff like showing help text when requested, validating the 
program name, etc. The program being run is responsible for validating 
the arguments passed to it.

MAApplication is a superclass which is extended by all the programs that 
can be run by the launcher. In this case they are all members of the same 
package so that the user only needs to input the program name. Here is 
MAClassLoader in its entirety:

package ma.internals;

/**
 * MAClassLoader loads the application.
 *
 * The only method used from the abstract parent ClassLoader
 * class is loadClass(String). As it is not abstract and
 * doesn't need to be overridden, this class definition is null.
 *
 * Its only purpose is to convert the abstract ClassLoader
 * declaration into a non-abstract class.
 */
public class MAClassLoader extends ClassLoader
{
   
}

I run programs with this type of command:

   java -jar /usr/java/jarlib/jarfile.jar program arguments....

where 'program' is the program to be run and the arguments will be passed 
to it by the launcher.

I hope this is useful info.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-07-31 19:40 +0000
  Re: dealing with ClassLoaders... Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-31 20:44 +0000
    Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 14:22 +0000
      Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 21:10 +0000
        Re: dealing with ClassLoaders... Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-01 17:32 -0400
          Re: dealing with ClassLoaders... Joerg Meier <joergmmeier@arcor.de> - 2014-08-02 01:21 +0200
          Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-02 00:00 +0000
        Re: dealing with ClassLoaders... Martin Gregorie <martin@address-in-sig.invalid> - 2014-08-01 21:45 +0000
          Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 23:14 +0000
            Re: dealing with ClassLoaders... Martin Gregorie <martin@address-in-sig.invalid> - 2014-08-02 00:35 +0000
              Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-05 15:38 +0000
  Re: dealing with ClassLoaders... Silvio <silvio@internet.com> - 2014-08-01 13:31 +0200
    Re: dealing with ClassLoaders... Silvio <silvio@internet.com> - 2014-08-01 13:37 +0200
      Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 16:06 +0000
  Re: dealing with ClassLoaders... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-01 13:19 +0100
    Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 15:51 +0000
  Re: dealing with ClassLoaders... Josip Almasi <joe@vrspace.org> - 2014-08-01 15:55 +0200
    Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-04 15:12 +0000
      Re: dealing with ClassLoaders... Mike Amling <mamling@chaff.us> - 2014-08-04 19:53 -0500
        Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-05 15:16 +0000
      Re: dealing with ClassLoaders... Josip Almasi <joe@vrspace.org> - 2014-08-08 11:53 +0200
        Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-08 18:46 +0000
          Re: dealing with ClassLoaders... Josip Almasi <joe@vrspace.org> - 2014-08-10 13:22 +0200
            Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-12 17:16 +0000

csiph-web