Jigsaw prototype, take 2

[Gregg Wonderly]

What I dislike the most about tightly bound modularization systems, is 
deployment and dependency analysis and "requirements" which create a giant slow 
down in development because things have to be "structured" in particular ways, 
in order for thing to meet the "systems" requirements.   In particular, I 
dislike anything which mandates non-circular dependencies and other "structural" 
requirements.  There are all kinds of concerns about not being able to compile 
separate modules with circular dependencies when you start from nothing but 
source.  That's my problem as a developer to resolve, not a modularization 
system.  .Net has this kind of nonsense deeply ingrained and there are all kinds 
of separate issues that this creates in and of itself.

Java has always supported doing something like

mkdir classes
javac -d classes `find . -name '*.java'`

and then using that 'classes' directory as your classpath for subsequent 
builds.  For super massive source trees, that find could of course, be a 
filtered, smaller list of interfaces, abstract classes and super classes which 
have the circular dependency issue.  And in fact tools can be used to find such 
circular dependencies, and to then create the "base.jar" needed to remove the 
circular dependency issue from the rest of the code base.

Please, oh please, let us keep the power of the classpath, the power of dynamic 
loading, and the flexibility of "roll your own classloader", and focus on 
providing a meta data approach that allows tools to help organize your needs 
into the use of the things which are the POWER of Java.

Gregg Wonderly


On 8/29/2013 10:55 PM, mark.reinhold at oracle.com wrote:
> 2013/8/28 15:50 -0700, Tim Boudreau <niftiness at gmail.com>:
>> On Wed, Aug 28, 2013 at 12:27 PM, <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.
>> Simplified how?
> That's partly answered in the very next paragraph:
>
>    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).
>
> That is, I admit, somewhat cryptic.  I'm writing up a longer note that
> will explain the background and the new approach in more detail.
>
> - Mark
>