Identical classes names' in different jars.

[Prabh]

Hello all,
I'm running into an issue with class names in different jars and
wonder if you could give me an idea.

I've two jars installed to "C:\Program Files\AppFolder\JarsFolder"
from my application installer.

First jar: Jar1.jar
Second jar: Jar2.jar

Both of them have same class names, along the lines
"com.company.dept.proj.component.classname", but they're jarred up
into two diff. jars.

I added these two jars in the CLASSPATH variable and my app is running
into a few issues, I'm not sure why, maybe its because of the
conflicting classnames.
The classes are in jars with different names, but it still seems to be
the problem.

Is it also the case of these jars being installed to the same
location, if I installed them in diff. locations would it make more
sense?

Could anyone give me some pointers, please?

Thanks for your time,
Prabh

 

[Andrew Thompson]

Both of them have same class names, along the lines
"com.company.dept.proj.component.classname",

Why do people always describe these name clashes
as 'something like..'

Tell us what it *actually* is and we'll probably
advise that *neither* class should be called 'MyClass'..

 

[John C. Bollinger]

I've two jars installed to "C:\Program Files\AppFolder\JarsFolder"
from my application installer.

Both of them have same class names, along the lines
"com.company.dept.proj.component.classname", but they're jarred up
into two diff. jars.

I added these two jars in the CLASSPATH variable and my app is running
into a few issues, I'm not sure why, maybe its because of the
conflicting classnames.

A class is uniquely identified within a JVM instance by its fully
qualified name and the ClassLoader that loaded it. If the same
ClassLoader has two different options for loading a class with a
particular name (and different bytecode) then you are asking for
trouble. If there are many such duplicate classes then you are
_begging_ for trouble. Moving jar files around the filesystem is
unlikely to help you; you must ensure that all the classes are uniquely
identified within the VM by changing some class names (usually not
feasible), by removing duplicate classes, or by using multiple class
loaders.

If you are dealing with multiple versions of some third-party component
then you would do well to standardize on one version for this version of
_your_ software. In the case of many third-party dependencies to deal
with that may be tricky, but it is still probably the best solution most
of the time. The rest of the time you probably need to get creative
with ClassLoaders.


John Bollinger
(e-mail address removed)

 

[Hal Rosser]

put the classes in different packages (like com.yourName.YourPackageName )
and recompile
recreate the jars
then use the classes you need like

com.yourName.YourPackageName.ClassName x = new
com.yourName.YourPackageName.ClassName();

 

[Malcolm Dew-Jones]

Prabh ([email protected]) wrote:
: Hello all,
: I'm running into an issue with class names in different jars and
: wonder if you could give me an idea.

: I've two jars installed to "C:\Program Files\AppFolder\JarsFolder"
: from my application installer.

: First jar: Jar1.jar
: Second jar: Jar2.jar

: Both of them have same class names, along the lines
: "com.company.dept.proj.component.classname", but they're jarred up
: into two diff. jars.

The jar file names and locations are irrelevent, except for the setup of
how the running java system finds the classes.

: I added these two jars in the CLASSPATH variable

Which means that the running java system will be able to find the classes
in both files.

and my app is running
: into a few issues, I'm not sure why, maybe its because of the
: conflicting classnames.

I would assume that's the reason.

: The classes are in jars with different names, but it still seems to be
: the problem.

As I said, the names and number of the jar files are basically
irrelevent, except for the setup required for the running java system to
find them. Once it finds them then the only concern is what is in them.


: Is it also the case of these jars being installed to the same
: location, if I installed them in diff. locations would it make more
: sense?

No.

Why do you need two sets of classes that claim to be the same class?

: Could anyone give me some pointers, please?

Use either one jar file or the other (not both), or change the names of
the classes inside the jar file.