Still driving off the cliff
David M. Lloyd
david.lloyd at redhat.com
Fri Feb 24 10:50:03 PST 2012
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.
--
- DML
More information about the jigsaw-dev
mailing list