DRAFT: Project Jigsaw: The Big Picture (part 1)

[mark.reinhold at oracle.com]

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