river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jgr...@simulexinc.com
Subject Re: Space/outrigger suggestions
Date Mon, 20 Dec 2010 21:12:02 GMT
Sim, I think I can summarize the debate thus far.

Two issues:
1) Should we use generics within the Javaspaces API?
2) There are currently corner cases for generics which do not work in a well-mannered fashion
with Javaspace.   Should we make changes to Javaspace to better account for these corner cases?

The argument for issue #1 is that it allows us to more fully match the method signature to
the specification, while also reducing boilerplate code for users.

The principle argument against issue #1 is that by utilizing generics within the API, users
may believe that issue #2 is dealt with.   That is, that by using generics at all, we're implying
that in all cases with generics we will do the least surprising thing.   And thus, the argument
is that we should deal with these corner cases first or drop the issue altogether.

Issue #2 exists regardless of action on issue #1, and so minimally a documentation change
will have to be made to explain foreseeable problems.

Other possible solutions to issue #2 include bytecode examination (which is not a certain
solution, but has been mentioned as something to investigate) or explicitizing the corner
cases in some way such that we might gain knowledge that would otherwise be lacking.   Bytecode
examination may have performance penalties, whereas explicitizing the corner cases would result
in a larger API either in terms of method arguments or methods.

If anyone feels that there's something I've left out, feel free to add to this summary.

jamesG

-----Original Message-----
From: "Sim IJskes - QCG" <sim@qcg.nl>
Sent: Monday, December 20, 2010 8:36am
To: river-dev@incubator.apache.org
Subject: Re: Space/outrigger suggestions

On 12/20/2010 08:50 AM, Peter wrote:
> I hope we can now refocus and all work together reimplementing
> Outrigger based on what we can agree on, rather than be distracted by
> one thing we can't.

I'm not sure to which issue we cannot agree on. I'm not even clear on 
which are the opposing views. I would like to consolidate the current 
consensus in a document for the website, even if it means that we have 
to document two opposing views. Generics is not going away as a topic, 
so we better document what we have right now.

Anybody in support for this method?

Gr. Sim





Mime
View raw message