Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type;
  b=hMemDljPabkbxRD2DbI7GkgJnLyLFyZPuhaWIOg+Z13V8oDNgkePjsG/XzoerzK0JdZe8kv3UqPo7w1M5GNR9HZuqUaZp09eiK3oVeEzs0uuo6wNYxT+YxnUx6so3OXOXDVU0ktg87Hp2aT4zAw6uRbqIX9hZ+T3Cz6UAmUpqrM=;
Message-ID: <533156.44805.qm@web33802.mail.mud.yahoo.com>
References: <1292659919.3679.22.camel@Nokia-N900-51-1>
    <1292664371.621218002@192.168.2.228>
  <1292672616.4256.5.camel@Nokia-N900-51-1>
 <1292693428.15723939@192.168.2.228>
Date: Sat, 18 Dec 2010 19:03:09 -0800 (PST)
From: Wade Chandler <hwadechandler-apache@yahoo.com>
Subject: Re: Space/outrigger suggestions
To: river-dev@incubator.apache.org
In-Reply-To: <1292693428.15723939@192.168.2.228>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

These are pretty much my feelings. 

Sim, yes, a branch would be good so we can play in for testing purposes. The 
code changes should be fairly small for studying impacts with the current impl 
as we are talking about changing the interface of JavaSpace/05 and probably 
MatchSet as well. In the case of MatchSet I think we would want it to be able to 
reflect  its purpose with class level generics as it works with the required  
Entry type returned from JS05 methods. Do them all for testing and planning and 
give everyone a chance to check it out; at least so we can look at it and decide 
from there.

I'm thinking once we have looked at it from that perspective and there is some 
consensus, then we probably will want to talk about impact on the Jini use cases 
overall. These changes will probably require a separate package to allow for 
full compile time backward compatibility with the old API. Essentially by doing 
that the old API will remain in place and the new generic versions can live side 
by side.

Thanks,

Wade

 ==================
Wade Chandler
Software Engineer and Developer
NetBeans Dream Team Member and Contributor


http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org


----- Original Message ----
> From: "jgrahn@simulexinc.com" <jgrahn@simulexinc.com>
> To: river-dev@incubator.apache.org
> Sent: Sat, December 18, 2010 12:30:28 PM
> Subject: Re: Fw: Re: Space/outrigger suggestions
> 
> I think perhaps there are two separate issues here.
> 
> Issue #1:
> Should  we use generics in javaspace methods?
> 
> Issue #2:
> Should we aggressively  typecheck within javaspace to prevent common errors 
>when using generics across  serialization boundaries?
> 
> The second issue is largely independent of the  first, given that users are 
>already free to use generics within their Entries,  and have been able to do so 
>since Java 1.5.
> 
> I think that the second issue  is what Peter is pointing to.   It is much more 
>complex than the first,  owing to type erasure, and carries a potential 
>performance penalties.  
>
> 
> The second issue is still worth looking into, however, given that there  is 
>potential for malformed objects to be inserted into javaspace, whether  through 
>accident or malicious intent.   I'm not entirely certain how far we  would get 
>with ASM.   Without ASM, reflection would enable us to do some of  these checks, 
>but not all.   Worth pondering, though.
> 
> Others may see  more connections between the two issues than I do.   But my 
>thinking is  that the use of generics in an API does not guarantee fully proper 
>use in  extreme circumstances.  
>
> 
> Indeed, the problem that was pointed out  using a collection within an Entry 
>has its root in the Collection and not the  Entry; the problem is, in short, 
>that a user of the generically typed collection  could change the reference 
>using a raw type with incorrectly typed  elements.   If the Collections API does 
>not guard against such behavior  (resulting in a class cast exception at 
>runtime), perhaps we would also be okay  if we let it slide.   Documentation 
>would be important,  naturally.
> 
> jamesG
> 
> -----Original Message-----
> From: "Peter"  <jini@zeus.net.au>
> Sent: Saturday,  December 18, 2010 6:43am
> To: river-dev@incubator.apache.org
> Subject:  Re: Fw: Re: Space/outrigger suggestions
> 
> The main problem is we need to  figure out a way to handle the unchecked type 
>casts.
> 
> Any ideas for a  handler?
> 
> If we check the bytecode for instanceof checks and type casts,  using ASM, we 
>could insert a type check and a handler that throws a checked  exception.
> 
> Perhaps it might be possible to do this with a reflective  wrapper proxy, to 
>wrap the exception in a RemoteException, at least the client  knows how to deal 
>with it and the service api is local code.
> 
> We'd need to  research where the compiler weaves in the class casts.
> 
> Currently generics  are not designed for mobile code, we need to figure out a 
>robust way of doing  it, if we are to support it, for me it's much easier to 
>just say generics aren't  supported in remote code for now.
> 
> Unless we can find a way to make  Generics and mobile code consistently 
>typesafe, it'll be a nightmare to  support.
> 
> Can we set up a place in skunk to experiment?
> 
> Peter. 
> 
> 
>