[jsr294-modularity-eg] iJam

[Bryan Atsatt]

This seems to be more of a 277 issue, but...

I am all for enabling flexibility like this, as there are certainly 
situations that require it; the servlet spec introduced the 
"child-first" search order recommendation to address this. However, 
having that as the *default* behavior was/is a disaster, as developers 
tend to bundle classes "just in case they are not available". This leads 
to unwanted duplications, which lead to ClassCastExceptions and 
LinkageErrors that are very hard for most to diagnose.

We want to promote class sharing as much as is reasonable, but support 
duplication where required; this proposal does that nicely.

Like any simple but powerful tool, I worry that it will be too easily 
mis-used; good documentation will certainly be important, but good tools 
even better.

// Bryan

Doug Lea wrote:
> I should have CC'ed this to 294 list...
>
>   
>> From: Doug Lea <dl at cs.oswego.edu>
>> To: Rok Strnisa <Rok.Strnisa at cl.cam.ac.uk>
>> Subject: Re: iJAM: a proposal for improvement of JAM
>>
>>
>> Rok Strnisa wrote:
>>     
>>> Dear Alex, Andreas, Doug, and Stanley,
>>>
>>> I wonder whether you saw an email we sent to the modules' mailing lists 
>>> a couple of weeks ago. Basically, we have written, formalized and 
>>> prototyped a proposal for improvement of the Java Module System (JAM). 
>>> The main document describing our work can be found here:
>>>
>>>   http://www.cl.cam.ac.uk/~rs456/iJAM/iJAM_doc.pdf
>>>
>>> The other documents, including the implementation and the formalization, 
>>> can be found on the project's website:
>>>
>>>   http://www.cl.cam.ac.uk/~rs456/iJAM/
>>>
>>> Comments and suggestions very welcome.
>>>
>>>       
>> Sorry for delay. (I've been triaging out almost everything
>> other than upcoming multicore stuff as I've been falling so
>> far behind on even that.)
>>
>> I just took a look and feel even worse about ignoring it first
>> time around because it is VERY nice! It took a couple of reads
>> to see that the non-reverse dfs was not only what you want, but the
>> key to cleanly supporting "import own M" and "import M as X".
>> (You might restructure this little paper a bit to give away
>> the punch line up front?)
>>
>> The only concern I have that I can't offhand dismiss is
>> whether there might be some weird
>> incompatibility with non-module-based class-loading (module and
>> non-module-based will need to co-exist). have you thought this
>> through?
>>
>> What do others think?
>>
>> -Doug
>>
>>     
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>
>