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.reinh...@oracle.com wrote:
2013/8/28 15:50 -0700, Tim Boudreau <niftin...@gmail.com>:
On Wed, Aug 28, 2013 at 12:27 PM, <mark.reinh...@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
