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

[Debasish Ray Chawdhuri]

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. 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.
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)
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.
4. Your module system would still work.
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.



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
>



-- 
Debasish Ray Chawdhuri
http://www.geekyarticles.com/
[A collection of advanced articles on java]