[jsr294-modularity-eg] Pain

Peter Kriens peter.kriens at aqute.biz
Mon Jul 13 02:51:36 EDT 2009


The sketch is a desperate attempt to concentrate the fuzziness to  
where we already have it, in runtime class loading and not let it  
creep into the JLS :-(

But I would obviously like to go further, it would be great if we  
could fully define the container!

Kind regards,

	Peter Kriens



On 10 jul 2009, at 21:19, Richard S. Hall wrote:

> On 7/10/09 2:54 PM, Alex Buckley wrote:
>> Richard S. Hall wrote:
>>> On 7/10/09 2:27 PM, Alex Buckley wrote:
>>>> Do other EG members agree with this mail? If so, how?
>>>
>>> For me, I share Peter's concerns that we are defining something  
>>> with only vague meaning and it will ultimately hurt Java's vision  
>>> of "write once, run anywhere". I would like it if we were defining  
>>> something more concrete.
>>
>> Do you not think that a standardized container and repository  
>> architecture, as suggested in Peter's mail, is exactly the "meta  
>> module system API" he complained about earlier?
>
> It could be...the devil is in the details. From my reading, it seems  
> like Peter is trying to give you more "out of the box", instead of  
> just defining a meta module system API.
>
> -> richard
>>
>> Alex
>> _______________________________________________
>> jsr294-modularity-eg mailing list
>> jsr294-modularity-eg at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg

_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg


More information about the jsr294-modularity-observer mailing list