16

Assume I have a project K

K depends lib.jar

In lib.jar , there is a class named x.y.z.Foo

If i create the same class x.y.z.Foo in K , then in this project when I create a instance of Foo , now will JVM use Foo in K rather than in lib.jar ?

And if it's unstable or depends on something , how to make sure that Foo should use K's version rather than lib.jar?

jackalope
  • 1,554
  • 3
  • 17
  • 37
  • 2
    It depends on which one is first in the class path and where it is instantiated. You can look into custom classloaders to solve this. – Andrew T Finnell Jan 05 '13 at 03:39
  • 3
    It sounds like you're looking to open a door to a world of pain, if not for yourself then for whoever may have to deal with your code afterwards. You should either spend some quality time reading up on this, or think about using OSGi or something similar, even if just creating a mega-bundle. If you decide to go your own way you should look into a similar well tread path to know what kind of unexpected bumps might await you (getting the right version in one spot may only be a small step). – Matt Whipple Jan 05 '13 at 03:47
  • http://stackoverflow.com/questions/8994147/what-are-the-implications-of-having-duplicate-classes-in-java-jar/8994188#8994188 – Dave Newton Jan 05 '13 at 03:51
  • 1
    That's what [JAR Hell](http://en.wikipedia.org/wiki/Java_Classloader#JAR_hell) is about. – Sergey Kalinichenko Jan 05 '13 at 03:51
  • Thanks all, and yes,that's may not be a graceful method , but i'm just looking for a solution to solve this problem – jackalope Jan 05 '13 at 04:11
  • An alternative, more standard approach that just popped in to my head (inspired by recent personal experience) would be to use AOP weaving. – Matt Whipple Jan 05 '13 at 13:28
  • @MattWhipple that must be another hell. – jackalope Jan 05 '13 at 13:32
  • @jackalope not if you take the time to work with it. It's perfectly maintainable and robust if done properly, and it avoids the opacity that puts the hell in jar hell. In this scenario it would be to also handle a wider range of modifications while mediating the risk of breaking existing client code which was compiled against the original version or is within another classloader. – Matt Whipple Jan 05 '13 at 13:50
  • @MattWhipple WOW, I'm sure that would be the hell of performance and mantainence. Tried AOP earlier. – jackalope Jan 05 '13 at 14:03
  • 1
    @jackalope Runtime performance is not impacted at all with build/load time weaving and only marginally with proper runtime weaving. Maintenance is largely what AOP is all about if done properly (even though this would not be its intended use, the maintainability wouldn't change). Both of these evidenced by AOP's widespread use in lightweight frameworks like Spring. It's obviously not a viable answer from your perspective but could be considered by someone else looking at this question. – Matt Whipple Jan 05 '13 at 15:11

1 Answers1

3

Java class loading behaviour in a standalone application (at least with no custom classloaders) is stable. Make sure that your k.jar (or path) comes before lib.jar in -cp java arg

java -cp k.jar lib.jar ...

or add dependencies to /META-INF/MANIFEST.MF of your K project as

...
Class-Path: lib1.jar lib2.jar
...

and run 

java -jar k.jar

k.jar classes will be loaded first

in Maven it is

<build>
    <plugins>
        <plugin>
            <artifactId>maven-jar-plugin</artifactId>
            <configuration>
                <archive>
                    <manifest>
                        <addClasspath>true</addClasspath>
                    </manifest>
                </archive>
            </configuration>
        </plugin>
         ...
Evgeniy Dorofeev
  • 133,369
  • 30
  • 199
  • 275