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