On Tue, 29 Jul 2014 11:44:56 +0100, sebb wrote:
On 29 July 2014 11:12, Jörg Schaible <joerg.schai...@swisspost.com>
wrote:
Gilles wrote:
[...]
== Java classloader ==
The Java runtime system only allows a single instance of a class
to
exist in a given classloader.
Classes are uniquely identified using the package name and class
name.
For example, the class {{{Utils}}} in the package
{{{org.apache.commons.example}}} can only appear once in a
classloader.
The classloader uses the classpath to find the classes needed by
an
application.
If the classpath contains more than one jar which contains the
above
Utils class, then the JVM will load only one of the instances.
If the class instances in the different jars are identical, then
this
is not a problem, but if there are two different versions of the
class, the classloader may choose the wrong one. And different
JVMs
may process the classpath in a different order.
Is that correct?
Excerpt from
http://docs.oracle.com/javase/8/docs/technotes/tools/unix/classpath.html:
-----
The order in which you specify multiple class path entries is
important.
The Java interpreter will look for classes in the directories in
the
order they appear in the class path variable.
-----
Gilles
[...]
If your jars are in the WEB-INF/lib folder of a web application ...
do you
know in which sequence the application server adds those jars to the
classpath ??
No idea, but not really relevant to this issue, as the user has full
control over which jars are in the folder.
The issue with the Maven classpath is that the contents depend on the
{gid, aid} pairs.
Maven must be given the correct info.
What I was referring to is your description of the Java classpath
processing:
the sentence seems to contradict the Oracle doc. [I.e. as you just
said, when
the classpath is set, it's the first occurrence of a class that will be
loaded,
independently (hopefully) of the JVM.]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
