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

[Debasish Ray Chawdhuri]

And I hate this mailing list because the mails don't come with a reply-to
address. I sent the mail to your address by mistake.

On Thu, Jul 19, 2012 at 10:40 PM, Debasish Ray Chawdhuri <
debasish.raychawdhuri at gmail.com> wrote:

>
>
>
> 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]
>>
>>
>
>
> --
> Debasish Ray Chawdhuri
> http://www.geekyarticles.com/
> [A collection of advanced articles on java]
>
>


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