Extents of extensibility ("is this thing on?")

David M. Lloyd david.lloyd at redhat.com
Thu Jul 19 09:38:15 PDT 2012


Thanks for your reply.  Responses inline.

On 07/19/2012 11:03 AM, Debasish Ray Chawdhuri wrote:
> The points are worth noting, but there are obvious reasons I think for
> making a language level change. For your stand point, you are only
> interested in enterprise systems, but the jigsaw project aims to solve a
> different problem, its beyond enterprise computing.

Though I do work at JBoss, this should not be taken to mean that I'm 
only looking at the enterprise/application server angle.  Thus I 
respectfully disagree with this point.  I have done enough research to 
convince myself at least that I have a strong understanding of not only 
the enterprise side of this problem, but also the OS side, the user 
side, and the platform side.  However, if there are points that you feel 
illustrate a lack of consideration for any particular angle of this 
problem, do point it out and we can discuss.

> So what would be the difference?
>
> 1. Compile time binding: We want to get rid of reflection. We also want our
> compiler to figure out errors.

This I have no problem with.  But, this also has nothing to do 
(technically speaking) with the actual implementation of putting module 
data in as a language construct.  Yes it needs to be a construct, but 
making it part of the JLS is cargo-cultism, or something: it's specified 
because it "feels right", but it doesn't solve any particular problem 
that cannot be better solved in other ways.

> 2. Module resolution: In your JBoss module, you still need to provide the
> jars in the classpath, some people don't like classpaths (that includes
> myself)

I think that peoples' problems with things like classpaths are not 
because of what they are, but because of how they have historically been 
used.  Modules have content.  Classpaths are simply a way of saying 
"here's the content".  You can call it by another name but you can't 
change what it is, and it's an essential concept to Jigsaw, JBoss 
Modules, OSGi and every other module system that can possibly exist. 
Without content, you have no module.

> 3. Installable Programs: Like yum(in Redhat Linux) or apt(in debian). You
> should simply be able to download and install a module just by knowing its
> name. It should automatically take care of its dependencies. Given where
> JavaFX is going (may be some day we would end up writing third person
> shooter games in java), it seems to be a good idea to make the installation
> process easier for the non-programmer, and it needs to be platform
> independent.

I agree.  We need a balance between ease of use and platform integration 
though.  It should be easy for OS distributors to distribute Java and 
its modules without having to completely sacrifice their own principles. 
  The installation process should be intuitive and idiomatic for both 
audiences: OS administrators who are most comfortable with their package 
system, and Java developers who are most comfortable with Java modules 
and toolchains.

> 4. Your module system would still work.

Well, thank you. :)

> 5. There are added performance advantages (but those alone would not make
> it reasonable to have Jigsaw): like pre-validation of classes during
> installation, pre-compilation into native code etc. This would of course
> bring down the time required to restart an instance since currently all the
> classes are verified and compiled (to native code) again.

These kinds of optimizations are important, but I don't think any of 
these things are specifically predicated on coding module definitions as 
part of the language, nor are any of these things excluded by including 
an extensibility API.  I have been, and will continue to be, critical of 
those "requirements" which, rather than give a requirement with use 
cases to back them up, instead give implementation directives without 
requirements to back them up.

Please be very aware: I am not arguing that JBoss Modules somehow 
replace Jigsaw - that argument would make no sense.  But I do think that 
a lot of the ideas in JBoss Modules are directly applicable to an SE 
module system, and in those cases I will continue to use JBoss Modules 
as an example of how I believe these problems could be solved more 
effectively than Jigsaw currently solves them.

> On Tue, Jul 17, 2012 at 9:34 PM, David M. Lloyd<david.lloyd at redhat.com>wrote:
>
>> Jigsaw still has one glaring hole in it which is a critical flaw: lack of
>> extensibility.
>>
>> There is no abstraction layer which would allow users to define their own
>> module loading and definition scheme.  This is directly related to the way
>> the module class loader, module, and module system APIs fit together.
>>
>> Note that this is tied directly to the flawed notion of having a
>> language-level construct for modules, which is ONLY done this way because
>> of the murky "requirement" that modules be "part of the language".  As is
>> often the case, this "feature" translates directly into a major constraint:
>> it is impossible to achieve the above.
>>
>> This requirement is senseless; I don't think more needs to be said, as the
>> burden of justification lies with the requirement author.  By opening up
>> module loading schemes to the user, the user can leverage the module
>> system's (presumably) fast and powerful linking layer for their own plugin
>> systems and containers - and this also "holds the door" open for a modular
>> progression for Java EE, which is something, I might add, that we have
>> already executed on with great success.
>>
>> We have a ModuleLoader API [1] which provides for one-way delegation
>> (think EE deployments delegating to the static boot module system), module
>> unloading (but only for *your* module loader), and run-time module
>> relinking, as well as being a touchstone for statistics and other run-time
>> class loading management information.  We provide a default "boot"
>> implementation which loads static module definitions off of the file system.
>>
>> This API works *really well* for our uses and also allows users to create
>> their own plugin schemes while still defining dependencies and filters in
>> all the same ways that they would for static modules - which really stands
>> to revolutionize how people write plugins.
>>
>> Please consider abstracting module loading out into a separate API
>> concept.  It is a good, solid approach.
>>
>> [1] http://docs.jboss.org/**jbossmodules/1.1.2.GA/api/**
>> index.html?org/jboss/modules/**ModuleLoader.html<http://docs.jboss.org/jbossmodules/1.1.2.GA/api/index.html?org/jboss/modules/ModuleLoader.html>
>> --
>> - DML
>>
>
>
>


-- 
- DML



More information about the jigsaw-dev mailing list