3 ms·
I am 100% sure Jigsaw will not let you to do that stupid thing. Import statement has no version information, so your program will load json-lib 1.0 or 1.2 and t
by lisivka 11y ago
I am 100% sure Jigsaw will not let you to do that stupid thing. Import statement has no version information, so your program will load json-lib 1.0 or 1.2 and then random errors will start to happen. It's called Dependency Hell: https://en.wikipedia.org/wiki/Java_Classloader#JAR_hell https://en.wikipedia.org/wiki/Java_Classloader#JAR_hell
- aardvark179 11y agoJigsaw will not let you do it in a vanilla configuration, but does allow for layers which do enable this. There is recognition that a single program should not hit this scenario but that app servers and similar may need to support it.
- mike_hearn 11y agoIt's not really only app servers and other plugin systems that need this. Dependency conflicts happen routinely when building all kinds of Java apps, just by depending on useful open source libraries. This is one of the pieces of feedback I sent to the Jigsaw team and I'm glad to see it appeared in Mark's list of issues to consider. Gradle's dependency tools help, but the best it can do is either flag an error or automatically de-conflict modules by always picking the newest version. If the version isn't fully backwards compatible, you can get deadlocked.
- aardvark179 11y agoI'm torn on this. On one hand the sort of multiple version support offered by OSGi can be very useful, but equally debugging and coverage tools can quickly become confused because they may not cope well with multiple classes with identical names, and that ignores the fun of conflicting native libraries. So for the first version I'd be happy to see this left to frameworks sitting above the module system, but I can appreciate other view points.