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

[David M. Lloyd]

On 12/23/2011 05:36 PM, mark.reinhold at oracle.com wrote:
> 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.

There needs to be a release valve for this equivalent to 
setAccessible(), else frameworks will be much more difficult to 
implement.  Anyway I'm not really sure there is a good reason to 
introduce this level of access checking.  It seems like feature creep to 
me - there isn't an obvious use case which is being fulfilled here which 
isn't adequately met today.


-- 
- DML