[jsr294-modularity-eg] Simple Module System Proposal

[BJ Hargrave]

[Forwarding to observer list since Alex is not an EG member.]
----- Forwarded by BJ Hargrave/Austin/IBM on 2009/09/17 17:01 -----

From:
Alex Blewitt <alex.blewitt at gmail.com>
To:
jsr294-modularity-eg at cs.oswego.edu
Cc:
Bryan Atsatt <bryan.atsatt at oracle.com>, BJ Hargrave/Austin/IBM at IBMUS
Date:
2009/09/17 16:56
Subject:
Re: [jsr294-modularity-eg] Simple Module System Proposal



Bryan wrote:
> I don't think most people care where the rules for modularity are 
> recorded, they just want to get their job done as simply as possible. 
> And it is hard to see how three choices is simpler than two, especially 
> when you consider the chasm that must be crossed when a transition is 
> forced.

This misses out a fairly important point in my opinion. The choice of 
which
module system to use (if you're developing everything yourself) is 
something
that's fully in your control. Whether you choose Jigsaw or OSGi or 
anything
else is up to you.

However, the vast majority of the Java ecosystem is not made up by full
integrators (that is, people who develop the entire stack themselves). 
Rather, many open-source libraries are consumed in the production of an
application, from logging to concurrency to collections to xml processors 
...
the list goes on.

The point of the SMS is to allow those library providers to generate a
standard format which can be consumed by either other simple SMS programs,
or be used in an OSGi environment, or be used in a Jigsaw environment.
The choice of a lowest common denominator is a trivial one to make for 
those projects wishing to have wide adoption of those libraries. The 
choice
is not between three; it's precisely one.

Regarding the classloader debate; if there is one classloader for all SMS
modules then we're in exactly the same situation as we are at the moment
with (for example) a general Maven build process. There is no need for a
separate SMS spec if that's the case, because we've already got that 
implemented.

Alex

PS Sending this to the list and to Bryan/BJ since I doubt it can go 
through
directly, and if not, to repost on my behalf.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090917/4b736096/attachment.html>