[Isolate-interest] JSR-121 aggregates and links (Strawman 9)

[Godmar Back]

Pete (and others interested in this discussion),

May I ask where the copy semantics is discussed? I downloaded
j2se_isolate-1_0-prd-spec.zip and look at the JSR-121 webpage, but I
might have overlooked it.  The documentation of the Link and Isolate
and IsolateMessage classes discuss at length how message objects are
copied, but not the semantics of copying, or was it felt that this was
outside the scope of JSR-121?

In general, is there some prose beyond the API specification that
summarizes the discussions in the EG and provides some rationale for
the designed API?

Another question regarding the process (I'm confessing total ignorance
here:) why is the bleeding edge of JSR-121 still a moving target?  I
thought that the API is by now finalized and ready for inclusion in a
future JDK?

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?

Thanks.

 - Godmar

On Tue, 28 Sep 2004 09:15:41 -0400, Pete Soper <psoper@pjs.east.sun.com> wrote:
> Hi Godmar,
>        Aggregate is given passing mention in the public review draft but the
> copy semantics of Link are well covered.
>        I suggest your students focus on the base package of the refactored
> APIs being developed by the 121 expert group. At the end of this message is
> my current proposal for EG discussion. I'm thinking very hard of a way to
> simplify Link so many of the upper layers become unnecessary. The public review
> draft can be used for spec reference until I've finished the new javadoc. This
> is somewhat of a moving target but I think the base package may be quite stable
> now and your students may find it exciting to be on the absolute edge. Also,
> I'll have a collection of simple tests contributed from four sources available
> for download as soon as I have time to find my old email.
>        This outline also reflects my argument to the EG for avoiding use of
> checked exceptions, to shift more responsibility into implementations and
> signal a very strong contract to users. (This was actually Doug Lea's position
> long ago). The EG will also notice I pulled StringMessage after realizing this
> would be a big mistake with respect to possible future interface hierarchies.
> Also, I've commoned out equals and hashCode into Sendable but am not sure if
> this is a good idea or not. I'm hoping Josh Bloch can give us advice.
> 
> -Pete
>