Simplicity [was: Re: DRAFT: Project Jigsaw: The Big Picture (part 1)]

[Neil Bartlett]

Mark,

I appreciate your effort to document the current status of Jigsaw. Try
as I might, I cannot hold back from commenting on your assertion that
"the Jigsaw design is, so far, very much simpler than OSGi." Obviously
you will disagree, but I feel the exact opposite: the Jigsaw design is
already more complicated than OSGi, especially with the recent
addition of module views. If Jigsaw's goal is to create a module
system that is more easily understandable than OSGi, then it is
failing.

This is not intended as a flame. I acknowledge that the appearance of
complexity is highly subjective, and I would appreciate the opinions
of people who are not already inculcated in either of the OSGi or
Jigsaw camps.

Regards
Neil


On Wed, Dec 21, 2011 at 9:29 PM,  <mark.reinhold at oracle.com> wrote:
> 2011/12/21 1:31 -0800, julien.ponge at gmail.com:
>> I have a bunch of those except flames. So here they are, for what they're
>> worth.
>
> Thanks for your comments -- replies below.
>
>> ...
>>
>> Granted, a significant share of applications simply rely on avoiding
>> ClassNotFoundException. Nevertheless there is also a significant share of
>> applications that require some form of side-by-side versioning, dynamic (un)
>> loading and the ability to access functional units through a service locator of
>> some form. ...
>
> There are definitely important classes of applications that require
> fully-dynamic multi-version module resolution and service lookup with
> a rich lifecycle API.  That's a pretty complicated programming model,
> however, and it's not one that most Java developers need, nor is it
> required in order to modularize the platform itself.  In SE 8 we're
> therefore proposing just to solve the simpler, more-common problem,
> and to make sure that developers who actually need to use frameworks
> like OSGi can do so in a way that works well with the base platform.
>
>> ...
>>
>> Implementing a container within the JDK would be a mistake, but this does not
>> prevent from adding the support for adding/removing modules at runtime. Do you
>> have any public document discussing the possible approaches for your APIs
>> contracts?
>
> I completely agree that adding a container to the JDK would be a mistake,
> and we aren't proposing to do that.  You suggest that we could still
> support the general dynamic loading and unloading of modules at runtime,
> but that would add significant complexity to both the programming model
> (i.e., the specification) and the implementation.  The Jigsaw design is,
> so far, very much simpler than OSGi, and that's largely because we chose
> early on not to try to solve all the big problems that OSGi addresses.
>
> As to API documentation, we have some (admittedly sketchy) Javadoc right
> now; a forthcoming section of the "big picture" document will have more
> details, and we'll be fleshing out the Javadoc as we go.
>
>>     A module's `exports` declarations govern the [accessibility][acc] of the
>>     public types declared in the named packages.  It is thus enforced at both
>>     compile time, by the Java compiler, and at run time, by the virtual
>>     machine.
>>
>> Correct me if I'm wrong, but this is the same as OSGi export clauses, right?
>
> No, it's not.  Export declarations in Jigsaw are meaningful in all
> phases, whereas in OSGi they're pretty much just a run-time concept.
> They're also much stronger than in OSGi, since access to non-exported
> types is specifically disallowed at run time by the JVM.
>
>> I always felt like it was weird to have public classes that in reality are not
>> being made visible at the package level. In OSGi this leads to JARs / bundles /
>> modules that have public types not being really public depending on the runtime
>> context (classpath, OSGi, etc).
>>
>> Why not rely on the compilation unit visibility? Like introducing a "module
>> protected visibility" without managing it at the module metadata level? I tend
>> to think that "module protected class Foo { }" is cleaner than "public class
>> Foo { }" only to be made "hidden" in module-info.java by not having a
>> corresponding exports clause.
>
> We've considered that.  If we were starting from scratch today, such a
> general module-accessibility modifier could well be the way to go.  With
> countless lines of existing Java code out in the wild, however, our take
> is that if developers have to modify all their source code and rebuild
> their libraries and systems in order to take advantage of modularity (or,
> equivalently but less robustly, run tools over their existing binaries),
> then that would be a significant barrier to adoption.
>
>>     The `public` modifier makes the types imported into `bar` from `foo`
>>     available to any other module that depends directly upon `bar`.
>>
>> It may be just me, but I don't find it explicit to have "requires public foo"
>> meaning that the module re-exports from foo. 'reexports foo" as a separate
>> clause may be more readable, although slightly less concise.
>
> I agree that that's arguably more Java-like.  It's really a matter of
> syntax, so we're going to go with what we have for now; this can easily
> be revisited later on.
>
>>     In this case any other module that depends upon either `bar` or `baz`
>>     will be able to use public types exported by `foo` without depending upon
>>     `foo` itself
>>
>> Can't this lead to unexpected types visibility at runtime depending on which
>> module was actually resolved as a dependency? Wouldn't it be useful to be
>> defensive regarding what imports bring you in crappy modules by having the
>> possibility of filtering?
>>
>> Or maybe the "permits" clause could be used just for that?
>
> No, `permits` wouldn't work for that.
>
> Whether a module should be able to filter the types that it re-exports is
> an interesting question; I'll make a note of it.
>
>>     A non-default view can, finally, also declare an entry point different
>>     from that of its containing module's default view, ...
>>
>> You may want to add a sentence and/or example to say how "java -m Foo" can pick
>> one view or the other.
>
> Good point; I'll do that.
>
>>     Services
>>
>> What you have here sounds good in principle, especially using ServiceLoader,
>> but we again get to the point of dynamics.
>>
>> On one hand you have a nominal static module system and a mechanism to bind to
>> services provided by modules in a decoupled fashion. Great. On the other hand
>> you seem not to be willing to have full dynamic modules + services + lifecycle
>> notifications although you seem to intend that there will be an API to still
>> load them dynamically… which means that Jigsaw may likely end up being
>> half-baked here… meaning that people will hack on top of that or resort to
>> solutions like OSGi which will most likely not be 100% 2-ways compatible and
>> have their own issues.
>
> Our aim is that Jigsaw be "baked enough" that container-type applications
> can be built on top of it, and can load and unload independent modular
> components or applications.  Developers who really need rich dynamism
> should go use OSGi or a similar framework.
>
> - Mark