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]
>
>


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