Avoiding same-package conflicts

Martin Lehmann martin.lehmann at gmx.de
Thu Oct 29 10:59:21 UTC 2015

Hi all,

I stumbled across the same "issue". 

> that having multiple versions of the same library isn't a best practice to say the least.
Full ACK. Bad practice.

I might have an (artifical?) use case where this might lead to some extra effort in migration, though:
Let's assume that two libraries D1 and D2 implement the same common API. For some historical reason, both libraries *ship* the interfaces classes of that common API.
This won't work (easily) without repackaging jar files (even if the common API classes would not even differ).

A --requires --> B, C
B --requires --> D1
C --requires --> D2
D1 and D2 both contain the same interfaces. Even if neither B nor C would *not* "requires public" D1 / D2, this would not work.

Too artifical? I actually thought of two logging implementations using & shipping the common slf4j interface classes. 

So we really need disjunct classes in *all* libraries now? Not even, if the redundant packages are not even exported (right?). Would it work in the "old" classpath?


-----Original Message-----
From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf Of Karl Sanders
Sent: Thursday, October 29, 2015 7:58 AM
To: jigsaw-dev at openjdk.java.net
Subject: Re: Avoiding same-package conflicts

Hi Alex,

indeed I'm on JDK 8 but at the moment I don't have different versions
of the same library in the classpath.
However sooner or later I will have to satisfy this requirement.
I can wait the year or so that separates us from the GA release of JDK
9 but I'm afraid that Jigsaw won't be able to help me.
Hence my questions.

Also, just for the record, I understand that having multiple versions
of the same library isn't a best practice to say the least.
But I'm afraid that this is one of the cases where the library vendor
can't modify the current code to fit my requirements and extracting
the part that I need from an older version and refactoring it into a
separate library would be quite an undertaking.

Thanks for your time.


On Thu, Oct 29, 2015 at 1:03 AM, Alex Buckley <alex.buckley at oracle.com> wrote:
> Hi Karl,
> Serious question: does your Java SE application expect that different
> versions of the same library are placed on the classpath in JDK 8?
> Alex
> On 10/28/2015 1:34 PM, Karl Sanders wrote:
>> Hi,
>> I'm trying out the JDK 9 EA with Jigsaw.
>> I created two modules, A and B, which are required by module C.
>> Modules A and B contain a non-exported package with the same name.
>> After compiling each module separately I start module C and get a
>> java.lang.reflect.LayerInstantiationException saying that modules A
>> and B contain a package with the same name.
>> In light of this behaviour I have two questions.
>> - Is it correct to say that for a simple Java SE application to work
>> with this configuration the only solution, in the realm of what will
>> be provided with the GA version of JDK 9, is through the concept of
>> layers of modules?
>> - In that case will there be some sort of out-of-the box functionality
>> to have this scenario work or will I have to write some non-trivial
>> code to manage these layers?
>> In other words, I have to use different versions of the same library
>> in a Java SE application.
>> Since Jigsaw is approaching I thought I could wait for it instead of
>> learning and having to deal with OSGi.
>> But from what I see by using only Jigsaw I won't be able to satisfy
>> this requirement.
>> At least not without writing some non-trivial code that I'm afraid is
>> above my skill level.
>> Cheers,
>> Karl

More information about the jigsaw-dev mailing list