Converting plain JARs to Java modules
njbartlett at gmail.com
Wed Nov 9 08:46:54 PST 2011
I think this point is key: runtime dependencies are not necessarily
the same as build-time dependencies. In fact they are usually NOT the
same for various reasons, not least of which is that running a module
requires all of its transitive dependencies to be present whereas
building it only requires its first-level dependencies.
At runtime, dependencies MUST be based on packages... experience in
OSGi and Eclipse has shown that again and again. On the other hand,
build-time dependencies can be written at module level, indeed most
developers I have worked with tend to think about the "libraries" they
are using rather than the Java packages.
The mistake made in tools like Eclipse PDE was to tie these two
together: if the developer wanted to use package-level imports then
they had to maintain those package imports manually in the tool. This
became unmanageable so they switched to using module-level
dependencies, which made life easier at build time but was the wrong
answer for runtime.
The Java 8 Module System requirements document appears to be making
the same mistake when it talks about "fidelity across all phases",
though that may be a matter of interpretation.
On Wed, Nov 9, 2011 at 4:02 PM, Eric Johnson <eric at tibco.com> wrote:
> We've struggled with this question in conjunction with OSGi.
> We started out using OSGi's require-bundle - and got badly burned as certain
> Java packages moved around from bundle to bundle as we switched operating
> environments. Trouble really stems from Java's language design, more than
> anything else - language namespaces (a.k.a. packages) aren't associated with
> a JAR, but have a separate logical existence. This means that at runtime at
> least, you need dependency information at a package level.
> You may want less fine-grained dependencies at other times (say, for
> example, packaging for the Linux platform). At least if you have
> package-level information, you can likely generate correct dependency
> information at the module level, but definitely *not* the other way around.
> On 11/9/11 3:04 PM, David M. Lloyd wrote:
>> I'll just state now that using packages as a dependency unit is a terrible
>> idea, and not some architectural revelation. That way, Peter's wrath will
>> be largely directed at me. :-)
>> On 11/09/2011 08:02 AM, Peter Kriens wrote:
>>> I agree that tools are needed but we must be careful to not expect tools
>>> to stopgap an architectural issue. I think it is important to first do good
>>> architectural design leveraging existing tools (e.g. the Java type system)
>>> before you try to add new tools. It is such a pity (but all to common) that
>>> a design allows for classes of errors that would be impossible with a
>>> slightly different design.
>>> Kind regards,
>>> Peter Kriens
>>> On 9 nov. 2011, at 14:49, Alan Bateman wrote:
>>>> On 09/11/2011 13:04, Peter Kriens wrote:
>>>>> The issue is that maven problems are not caused because maven is bad or
>>>>> that pom authors are stupid. The reason is that the module-to-module
>>>>> dependency architecture in maven (and Jigsaw) is error prone ...
>>>> This thread started out with someone asking about adding module
>>>> declarations to existing JAR files, and in that context, I agree it can be
>>>> error prone without good tools. I think things should be a lot better when
>>>> modules are compiled.
More information about the jigsaw-dev