[Isolate-interest] JSR-121 aggregates and links (strawman 10)

[Pete Soper]

Godmar Back wrote:

 >> Are these Miles personal opinions or the opinions of the EG, and if


Except for us having described the cluster requirement as one having a 
"single administrative domain" I think Miles reflected the EG view very 
well.


 >> the latter, could someone point me at where you documented your
 >> reasoning?


It's behind passwords as a huge collection of text with a low signal to 
noise ratio.

The EG hasn't discussed opening up access to this and
we haven't been able to generate and maintain the design rationale 
document you desire. Glenn Skinner warned me about this day. But every 
significant aspect of the public review API design got discussed 
thoroughly, in some cases multiple times. We have older and wiser brains 
now but there is a strong foundation and these strawmen we've been 
sharing are refactoring/packaging exercises for the most part.

 >>> >
 >>
 >>>> > > Finally, if you have time/energy, I'd like to hear the complete
 >>>> > > rationale for avoiding checked exceptions in this last draft. 
  In what
 >>>> > > way do they strengthen the contract to the user?
 >>
 >>> >
 >>> > Think about somehow putting a checked exception onto "new", then 
run that
 >>> > thinking backwards.
 >>> >


 >> As for example in "new ClosedLinkException()"?  How do I run this
 >> thinking backwards?  Could you give an example that shows the
 >> differences between these two approaches?


Do you put try/catch around every use of "new?" I'll bet you don't, 
because you figure if an out of memory exception is thrown there is 
simply nothing to do anyway. You are relying on new to be reliable. I 
think we should rely on Sendable to be reliable too. The EG hasn't 
discussed this yet as we're all extremely busy with other work. Yes, an 
isolate representing a link endpoint closing that link is going to cause 
an uncoordinated send/receive operation at the other endpoint to fail. 
If that couldn't be accounted for by system design then try/catch could 
be used as a special case. What I'm exploring is whether the world will 
be a better place if Link send/receive do not define checked exceptions 
via "throws." This puts the burden on implementors and I think the 
analogy with heap is valid: a decent implementation won't throw out of 
memory until all kinds of things have happened to try to find available 
storage (e.g. two days ago I read a Hotspot team member discussing the 
possibility of the VM giving up some of its internal cached space as a 
last ditch tactic). Something similar can be done with Link so that a 
send/receive failure (failure, not "rug pulling exercise" via one end 
doing a close) is tantamount to system (aggregate) failure.

And speaking of aggregates, I need to stress that this term is a 
convenience for expressing "all isolates relating to a common ancestor" 
and the "nature" of the primordial isolate varies depending on who's 
discussing the subject. This seems absolutely right to me considering 
the research nature of the cluster implementation style.

Laurent wrote:


 >> However nice & OO  this is, it is problematic to the J2ME=20
 >> footprint-concious implementor.
 >> When talking to some of them last year, they got really nervous about
 >> adding even just a single class, especially when
 >> this one has little content (e.g., one or two methods). That really
 >> bloats the footprint for not  much
 >> in terms of functionalities.

Yes, and at JavaOne this year Bernd Mathiske really hammered on this 
topic. But there seem to be more fundamental issues with CLDC and I 
wonder if it needs to "grow into" exposure of isolate APIs when the 
security model is more clear and invocation of these APIs can be via 
Java (or maybe some CLDC impls have their launcher code implemented in 
Java now, so this evolution has already started?)

-Pete