[jsr294-modularity-eg] Simple Module System Proposal

[Paul Benedict]

Is the SMS going to mandate implementation-specific behavior beyond the Java
API? Will other OSS implementations of Java (e.g., Harmony) have to
implement both the new Module API plus SMS behavior? I am still trying to
gather why implementing the new yet-to-be-determined Module API isn't good
enough by itself.

Paul

On Mon, Sep 14, 2009 at 4:17 PM, Jim Colson <jccolson at us.ibm.com> wrote:

> Following this line of reasoning, it would appear that you would also
> believe that one choice is simpler than two and that where the
> specifications for that one were recorded were, in fact, also irrelevant.
>  Is that an option?
>
> JC (Mobile)
>
> On Sep 14, 2009, at 4:01 PM, "Bryan Atsatt" <bryan.atsatt at oracle.com>
> wrote:
>
> I missed that you intended SMS to be concrete; ok, so then we have three
> module systems. But that does not change my argument: for the sake of being
> able to write down partial module-system semantics in the JLS, we introduce
> a great deal of complexity. I question your 80% figure, but even granting it
> for the moment it seems to me that those same people would be just as well
> served by using a subset of Jigsaw or of OSGi, where they can then naturally
> and easily move to use more advanced features as required. Same descriptor
> syntax and file, same tool chain, same deployment artifacts, same runtime
> model: no major disruption when their needs stray beyond the lowest common
> denominator.
>
> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090914/463f5fe1/attachment.html>