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

[Julien Ponge]

Thanks Mark for your feedback. Minor comments below. Hope they are constructive.

> 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.

Granted, such programming models are inherently complicated and most
problems are reminiscent of those encountered in concurrent
programming.

My point which may be hidden in my previous reply is that while I
agree that focusing on the most common problems is absolutely right,
there may be a chance to evolve the language+platform to also cope
with dynamics in a cleaner way that say, OSGi.

I have been using OSGi for some time. I can't blame it for making ways
around Java and the platform so as to provide dynamic modules. It's a
pragmatic solution for now, but it requires such a rigorous discipline
from the developer that it easily and often bites. However if you use
OSGi just as a static module system then it's quite easy to use and it
already does what Jigsaw promises.

> 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.

I still wonder if we couldn't come up with a clean and simple solution
as long as we have some latitude on evolving the specs. This is an
open question, really.

Jigsaw is indeed quite simple in its current form, but things like
views and local requires tend not to be that simple at first... plus
they somehow try to solve OSGI-esque problems (breaking isolation for
some "friend" packages, etc) ;-)

> 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.

Nice

> 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.

+1

> They're also much stronger than in OSGi, since access to non-exported
> types is specifically disallowed at run time by the JVM.

I don't get it. Do you mean that you cannot pass a reference of a
non-exported class instance from a module to another module? In this
case it would indeed be stronger than OSGi where you just cannot load
such classes, but you can still pass a reference that was allocated
from the originating module.

Cheers

-- 
Julien Ponge
http://julien.ponge.info/