[jsr294-modularity-eg] Runtime model

[Bryan Atsatt]

Andreas Sterbenz wrote:
> Bryan Atsatt wrote:
>> Andreas Sterbenz wrote:
>>> Bryan Atsatt wrote:
>>>> Given a class that represents a superpackage at runtime:
>>>>
>>>> public class SuperPackage {
>>> We have not really gotten to details of the reflective API yet. Alex and I 
>>> will send out a proposal soon.
>> Wow. (Contrary to how I feel at the moment, I'll do my best to remain 
>> professional in my response here.)
>>
>> I've been operating under the assumption that this process is a 
>> *collaboration*. Apparently that is mistaken.
>>
>> I can only read your response to mean that you see the EG as nothing but 
>>   reviewers of the work product created by the spec lead(s). That 
>> certainly fits the pattern so far.
>>
>> If this is in fact your intention, please let us know. Then each of us 
>> will be able to make an informed decision about continuing to "participate".
> 
> Of course it is a collaborative process.

If so, is it unreasonable of me to expect a response to the model I 
described?

> 
> All I tried to say is that Alex and I have already been working on a 
> complete proposal for the reflective API for some time. It will soon be 
> ready and when it is, we will send it out. If you want to send out a full 
> proposal of your own, you are welcome to do so.

So... we can't discuss models in an informal way, only via full proposals?

> 
> As for the suggestion of changing the semantics of existing class files, 
> that is a rather fundamental issue. We can discuss the issues I raised, 
> but we all have to be aware that this is a language JSR. What we do needs 
> to be consistent with the principles in the current language 
> specifications and people's expectation of Java language programs that 
> they formed over the past 10 years. That limits our design space.

I understand. But there will be a long transition period in which legacy 
  code can be wrapped and exposed as modules. Glyn's use-case can easily 
be extended to include this one.

So I was exploring how this might be supported. Not that we have to, of 
course, but if it isn't feasible we can rule it out on that basis alone.

// Bryan

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