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

[Debasish Ray Chawdhuri]

Thanks David, I will use the points index-wise, anyone can follow the
earlier chain.

1. I agree with you, in fact there has been a discussion in Jigsaw-dev
regarding other formats for module metadata and leaving the compiler alone.
I supported the idea of creating other formats like JSON. People even came
up with some small JSON parsers. But it did not pass the process [or not
taken so seriously I am not sure]. It would have been easier for other
build aware systems like Maven to use this metadata if the metadata is in
plain text form.

2. Yes I know the modules need content. The thing is now the JRE itself
would know where the content is kept instead of us having to tell it where
to find each part. This is by virtue of the idea of a default module
library. The content has been organized now.

3. I don't understand how it would break the OS's own package maintaining
system. Java will use java's tools, they would use theirs. It would be
similar, but they don't have to be covered in the same commands.

5. Yes I know that those are just added benefits not worth a whole language
level change, as I already mentioned in my first reply.

On Thu, Jul 19, 2012 at 10:08 PM, David M. Lloyd <david.lloyd at redhat.com>wrote:

> 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/**<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<http://docs.jboss.org/jbossmodules/1.1.2.GA/api/index.html?org/jboss/modules/ModuleLoader.html>
>>> >
>>> --
>>> - DML
>>>
>>>
>>
>>
>>
>
> --
> - DML
>



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