Still driving off the cliff

[Rémi Forax]

On 02/24/2012 07:50 PM, David M. Lloyd wrote:
> On 02/24/2012 12:15 PM, Rémi Forax wrote:
>> On 02/24/2012 06:26 PM, David M. Lloyd wrote:
>>>> With Jigsaw then it's usually a 1-1 mapping between module and class
>>>> loaders but we do have complications in the platform and it remains to
>>>> be seen where that goes. In addition I'm not sure where the class 
>>>> loader
>>>> relationship will be specified or not.
>>>
>>> The *only* reason I can see that Jigsaw doesn't mandate that a module
>>> is a class loader is a module is so that platform classes can return
>>> "null" to getClassLoader and yet still be called "modules".
>>>
>>> This is such a very thin foundation on which to base decisions such as
>>> redefining what a module *is*, and consequently requiring two *modes*
>>> of operation (doesn't that seem really awful to anyone else?). If the
>>> platform *must* be considered a single class loader then it shouldn't
>>> be considered to be multiple modules - more like a single module with
>>> some optionally available "features". With this simple change you
>>> don't need to have a "compatibility mode" to run old-style
>>> applications, and you can consequently allow users to leverage a
>>> *huge* body of prior work.
>>
>> There are lot of program like profilers, debuggers, agents etc
>> that relies on the fact that there is a way to separate the platform
>> classes from
>> the application classes, this is usually done by checking if
>> getClassLoader returns null
>> on a class.
>> If you break this assumption a lot of code will just break.
>> So even in a module world, you need a way to separate platform code from
>> application code
>> (it should be better to even have a system which is able to separate the
>> application, from the container,
>> from the platform).
>>
>> I agree with David that we should not have a compatibility mode (at
>> runtime).
>> Instead of having getClassLoader() returning a module class loader,
>> getClassLoader() should still
>> return null for the platform class and jigsaw should add a new method
>> called getModuleClassLoader()
>> that returns the module class loader.
>
> Honestly I don't even see the need to actually divide the platform 
> into actual modules.  If the desire is to be able to express 
> dependencies on certain features of the platform which would be made 
> optional, then this can be done with module aliases or views or 
> feature dependencies or any number of other ways which don't carry 
> this cost.
>

I see at least 3 advantages:
- ease development of JDK (make integration easier)
- push incremental update (module == distrib packet)
- get ride of stupid legacy code (CORBA?)

Rémi