[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