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

[mark.reinhold at oracle.com]

2011/12/22 9:37 -0800, julien.ponge at gmail.com:
> 2011/12/21 13:29 -0800, mark.reinhold at oracle.com:
>> 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. ...
> 
> 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.

As you say later on, this is an open question.  I'm highly skeptical
that a "clean and simple" design supporting fully-dynamic resolution
is possible, but I'd be happy to be proved wrong.

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

Me neither -- in fact it's impressive what OSGi can do given that
it's not deeply integrated with the underlying platform.

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

Perhaps, but only for the simplest of scenarios.

>> 2011/12/21 1:31 -0800, julien.ponge at gmail.com:
>>> 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.
> 
> +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.

No, I mean that if you somehow do get a reference to such an object
you won't be able to do anything with it.  The JVM's access-checking
machinery won't let you, in the same way and for the same reason that
it won't let you invoke a private method.

- Mark