limitations of Class.forName

R

Roedy Green

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.

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.

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

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

Arne Vajhøj

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.

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.

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

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

It is hardly difficult to specify more than one jar in the classpath.

But for more advanced cases it is common to instantiate a
URLClassLoader with the URL for where to look for dynamic
loaded classes.

Arne
 
R

Robert Klemme

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
 
J

Josip Almasi

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.

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

Oh, but there's more.
Class.equals() will fail on classes loaded by different classloaders, as
will Object.equals().
That is, after you extend URLClassLoader as Arne said:)
Then, you can't unload a class just like that, as class loader keeps
references to all loaded classes. You need to unload that ClassLoader too.
That is, if you wish to reload plugins without jvm restart.
With custom URLClassLoader, watch carefully not to break specified
delegation model.
A garden variety jar prevents java from looking anywhere else for
classes.

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

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

OK then you wish only to customize application classloader.
Note that in JEE containers, classloaders have another important
function - context isolation.

Regards...
 
R

Roedy Green

Oh, but there's more.
Class.equals() will fail on classes loaded by different classloaders, as
will Object.equals().
That is, after you extend URLClassLoader as Arne said:)
Then, you can't unload a class just like that, as class loader keeps
references to all loaded classes. You need to unload that ClassLoader too.
That is, if you wish to reload plugins without jvm restart.
With custom URLClassLoader, watch carefully not to break specified
delegation model.


OK then you wish only to customize application classloader.
Note that in JEE containers, classloaders have another important
function - context isolation.

Regards...

Thanks every one for your contributions. I have merged them into an
essay at http://mindprod.com/jgloss/classforname.html#LIMITATIONS
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top