[jsr294-modularity-eg] iJam

[Bryan Atsatt]

Yes, that makes perfect sense.

Again, though, I worry that too many knobs will lead to more 
confustion/errors... Class Loading, to most developers, is already a 
black art, or at least something delved into only out of desperation. I 
do believe that this situation has to change, it has already begun to in 
the EE world. But for the SE world, going from the current hierarchical 
model to the module graph is going to be a huge shift!

To be clear, I do believe these kinds of knobs are important, I'm just 
not sure how to adequately prepare those of us who don't frequent the 
class loading depths...

// Bryan

Rok Strnisa wrote:
> Hi Bryan,
>
> To address the issue you mentioned, I have implemented a feature in  
> my prototype (changes not available online yet), where a user can  
> specify which class is *spare*. For example, suppose we have the  
> following two superpackages:
>
> superpackage A {
>    member foo;
>    export foo.T;
> }
>
> superpackage B {
>    member foo; // contains foo.W, which refers to type "foo.T"
>    import A;
>    spare foo.T;
> }
>
> In the above scenario, a type reference "foo.T" (in B::foo.W)  
> resolves to A::foo.T if A contains a public class foo.T. Otherwise,  
> the type reference resolves to B::foo.T (if B contains a class  
> foo.T). Removing the 'spare' directive, a foo.T in B overrides a  
> possible foo.T in A.
>
> Essentially, the class lookup function becomes:
> 1) search system classes
> 2) search own members (excluding spare ones)
> 3) search imports
> 4) search own spares
>
> Alternatively, one could have classes *spare* by default, unless they  
> are marked with *override*, though we feel this is less intuitive,  
> since override seems like a good default option.
>
> Also, the marking currently happens on individual classes, but one  
> can easily have it also (or instead) for whole packages.
>
> Comments and suggestions welcome.
>
> Regards,
> Rok
>
> On 18 Sep 2007, at 23:21, Bryan Atsatt wrote:
>
>   
>> 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
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070919/cc620a60/attachment.html