[jsr294-modularity-eg] iJam

[Rok Strnisa]

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