Jigsaw prototype, take 2

[David M. Lloyd]

On 08/28/2013 11:27 AM, mark.reinhold at oracle.com wrote:
> I've created a new forest, http://hg.openjdk.java.net/jigsaw/jake, where
> we're going to explore a simplified approach to achieving the goals of
> this Project.  To start, it's just a clone of the current JDK 8 master.
>
> Among other things, we're going to see whether we can get away without
> introducing a distinct "module mode" as we have in the current prototype
> (which is incompatible, in some narrow yet deep ways, with long-standing
> behavior) and without doing dependence resolution (since build tools like
> Maven, Ivy, and Gradle already do that well enough).

I agree that having a separate module mode is yucky for several reasons, 
so I'm glad that the Jigsaw team has come to a similar conclusion.

I think however that it is a faulty assumption that build system 
dependency management can work for the runtime.  We've seen this 
firsthand in several different contexts.  The set of data is different, 
and the usage of the dependency information is radically different 
depending on whether you're compiling, testing, or running, and 
depending on what other components you have in the system and how you 
expect them to interact.  In addition, many best practices have emerged 
that (partially or wholly) contradict the original design intent of 
these systems (OSGi also falls into this category).

I think attempting to combine existing build system dependency systems 
with runtime dependencies in Java just isn't going to work without 
majorly changing the way these systems organize, store, and use this 
information.  I do however think that relying on an external dependency 
management mechanism of *some* kind is 100% the way to go - there is no 
need to build this kind of complex machinery into the language, 
especially given how quickly we've seen best practices change in this area.

> We remain committed, of course, to this Project's high-level goals:
> Create a modular and scalable platform, improve performance and security,
> and define a standard module system.
>
> As we work on this new prototype we'll take code from the old one where
> that makes sense, but we'll also take the opportunity to question earlier
> design decisions and generally clean things up.
>
> I urge onlookers to remember that this is just another prototype.  It is
> likely to evolve swiftly.  Its shape and content at any given point in
> time should not be treated as having any particular bearing on the final
> result of this Project.

I look forward to seeing how this progresses.

-- 
- DML