[jsr294-modularity-eg] Simple Module System Proposal
hargrave at us.ibm.com
Thu Sep 17 17:02:35 EDT 2009
[Forwarding to observer list since Alex is not an EG member.]
----- Forwarded by BJ Hargrave/Austin/IBM on 2009/09/17 17:01 -----
Alex Blewitt <alex.blewitt at gmail.com>
jsr294-modularity-eg at cs.oswego.edu
Bryan Atsatt <bryan.atsatt at oracle.com>, BJ Hargrave/Austin/IBM at IBMUS
Re: [jsr294-modularity-eg] Simple Module System Proposal
> 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
This misses out a fairly important point in my opinion. The choice of
module system to use (if you're developing everything yourself) is
that's fully in your control. Whether you choose Jigsaw or OSGi or
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
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
PS Sending this to the list and to Bryan/BJ since I doubt it can go
directly, and if not, to repost on my behalf.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jsr294-modularity-observer