• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to handle all these jars?

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello there,

i am having trouble keeping all the jars for my project handeled. The problem is that some jars contain classes that other jars contain too but in other versions. For example the apache axis2 libs contain various versions of the class javax/xml/namespace/QName.class . So how can i be sure what version will be used on runtime and will this work correct. Is there some sort of best practice or guide on how to manage the dependecies. Or am i just missing something here?

thanks in advance
 
Rancher
Posts: 1337
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is it really part of several jars? It's part of the XML APIs jar, which is not needed on Java 5 or Java 6 because those classes are all in the core JRE. But not even that should cause problems, because those XML classes would be loaded through a higher-level classloader, and the XML APIs file that comes with Axis would never be used.

Are you just wondering what might happen, or are you facing an actual problem?
 
Bartender
Posts: 2661
19
Netbeans IDE C++ Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the Ranch, Mathias.
 
Mathias Schmidt
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i wasnt aware of the fact that this class is now part of java 5/6, but its not just this class. If i would just take all my jars i need for my projekt and deflate them all, there would be about 15 classes in the same package and the same name. So i was wondering how i could be sure that this will cause no problems.
As an example: i write a class which uses the import de.xyz.abc and put 2 different classes with this name and package on the class path (in 2 seperate jars) which one does he use? Or does the JVM prevent this somehow?

Thanks for the replys
 
Lester Burnham
Rancher
Posts: 1337
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

i write a class which uses the import de.xyz.abc and put 2 different classes with this name and package on the class path (in 2 seperate jars) which one does he use? Or does the JVM prevent this somehow?


No, the JVM does not prevent this, and it can lead to problems, especially if -for example- the classpath contains different versions of some library.

The first thing to understand is the classloader hierarchy. Classes that are part of the Java class libraries are loaded by a higher-level classloader than classes loaded through the application classloader - which means that those classes in xml-apis.jar will never be used on a JRE that has them built in. "Higher level" means: that's where the JVM looks for classes first.
This can actually be a problem if you want to use a newer version of a library that ships with the JRE (like JAX-WS, JAXB and JAXP); there's an official workaround called endorsed directory, though.
In an app server -or servlet container- the hierarchy gets more complicated. There's the JRE's class loader, underneath that is the server's classloader, and then there are separate classloaders for each web app on an even lower level. This ensures that each web app can have its own version of everything, and not get in the way of any other application.

Now, you're asking about jar files that are on the same level in the classloader hierarchy - that can, and will, cause problems. Avoid it at all costs. Which of identically-named classes will be loaded may depend on the name of the jar file, and it may depend on other opaque factors. Generally it can cause rather cryptic error messages when it fails, about wrong method signatures, missing methods, abstract classes etc.

The high-end solution to dealing with library version conflicts is to use something like OSGi, which can handle different versions of the same library, and can control very precisely which code gets to see which versions. I can't tell from your description if that wouldn't be overkill, though.
 
Mathias Schmidt
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thank you Lester,

i guess the OSGI idea is a bit overkill right. Isnt there some other solution available or at least some tool to figur out wich classes or files may conflict with others? This must be a very common problem. Alone the libs from axis2 give me about 8 conflicting classes....
 
Lester Burnham
Rancher
Posts: 1337
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How did you determine which classes in which jars clash - some kind of tool?
 
Mathias Schmidt
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i just extracted all the jars to a folder and looked wich files he had to overwrite.
 
reply
    Bookmark Topic Watch Topic
  • New Topic