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

Groups > comp.lang.java.programmer > #28344 > unrolled thread

limitations of Class.forName

Back to article view | Back to comp.lang.java.programmer

Contents

  limitations of Class.forName Roedy Green <see_website@mindprod.com.invalid> - 2014-05-01 17:42 -0700
    Re: limitations of Class.forName Arne Vajhøj <arne@vajhoej.dk> - 2014-05-01 21:15 -0400
    Re: limitations of Class.forName Robert Klemme <shortcutter@googlemail.com> - 2014-05-02 08:51 +0200
    Re: limitations of Class.forName Josip Almasi <joe@vrspace.org> - 2014-05-02 09:25 +0200
      Re: limitations of Class.forName Roedy Green <see_website@mindprod.com.invalid> - 2014-05-06 03:55 -0700

#28344 — limitations of Class.forName

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.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Computers are like Old Testament gods; lots of rules and no mercy. 
~ Joseph Campbell (born: 1904-03-26 died: 1987-10-31 at age: 83)

[toc] | [next] | [standalone]

#28347

On 5/1/2014 8:42 PM, 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.
>
> 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

[toc] | [prev] | [next] | [standalone]

#28350

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

[toc] | [prev] | [next] | [standalone]

#28351

On 05/02/2014 02:42 AM, 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.
>
> 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...

[toc] | [prev] | [next] | [standalone]

#28393

On Fri, 02 May 2014 09:25:53 +0200, Josip Almasi <joe@vrspace.org>
wrote, quoted or indirectly quoted someone who said :

>On 05/02/2014 02:42 AM, 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.
>>
>> 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...

Thanks every one for your contributions.  I have merged them into an
essay at http://mindprod.com/jgloss/classforname.html#LIMITATIONS
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Culture is your operating system. 
~ Terence McKenna (born: 1946-11-16 died: 2000-04-03 at age: 53)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web