Re: limitations of Class.forName

From:

Robert Klemme <shortcutter@googlemail.com>

Newsgroups:

comp.lang.java.programmer

Date:

Fri, 02 May 2014 08:51:43 +0200

Message-ID:

<bsgtk1Fgig7U1@mid.individual.net>

On 02.05.2014 02:42, Roedy Green wrote:

When I first encountered Java, I was very excited about the notion
of interfaces and dynamic loading. I thought it would let people plug
in their own code to every conceivable utility.

There are two catches.

1. arranging that java.exe will look for your dynamic class in the
place where it is. It will not usually be bundled in the original
jar.

It's not only java.exe, but also java (on other platforms), java plugin etc.

2. arranging that java.exe will look for any auxiliary classes your
plugin needs in the place where they live.

A garden variety jar prevents java from looking anywhere else for
classes.

You can have a classpath header in the JAR manifest. You can use that
to do relative references, i.e. via same directory or URL that hosts the
referencing JAR.

I thought I would write a short essay on this. What techniques are
available?

See Arne's reply. Usually you configure the URL (or a directory name or
....) and create a classloader or classloaders that will look there.

I have always skirted the problem by putting all classes in the
original jar.

I don't think that's a good idea because it makes composing of an
application harder than necessary.

Also, various container systems have solved this already - you just need
to look how JEE containers and Tomcat are doing things.

Cheers

robert