river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Fw: Re: Space/outrigger suggestions
Date Sun, 19 Dec 2010 14:39:31 GMT
----- Original Message ----

> From: Peter Firmstone <jini@zeus.net.au>
> To: river-dev@incubator.apache.org
> Sent: Sun, December 19, 2010 2:39:41 AM
> Subject: Re: Fw: Re: Space/outrigger suggestions
> Ok thanks Nic, that's interesting, I stand corrected on erasure, seems
> it's  not entirely true.
> Any idea how we can enable runtime type checks for  Generics?
> So far we can get the type information, I know it's preserved  in
> bytecode from my experience with ASM and adding Generics support  to
> classdep, however, how does it stop me from setting the field  reference
> to another Collection, containing Integers, at runtime, then  returning
> it to the space?
> Even with James' proposed javaspace method,  which will work, the client
> typecast is unchecked, it relies on the javaspace  implementation to
> return the correct type, which means you must trust the  javaspace
> implementation.
> This places a significant burden on the  service implementor.
> What about Generics in other Service API?
> I  use Generics for it's added type safety, but type safety doesn't
> extend to  distributed code, since it is a compiler check (hint: I'd love
> to be pointed  to a runtime type checker for Generics)  I'd understand
> the attraction  of using Generic's if it was the case, but I'm failing to
> understand the  relevance of Generic's without type safety, could someone
> please explain it  for me?
> Or are we working on a tool to add type safety for Generic's  to
> distributed code?
> Sorry, the direction so far just appears to be,  add Generics to
> distributed code, without type safety checks, it seems type  checks might
> interfere with performance or  something.

To me this is not the concern of the impl. One should be using their own service 
API in these cases if they are using specific Enty class types. Now, in some 
purely dynamic system this may present a problem, but then again, that should be 
the concern of the implementer of the API which is using the spaces impl. For 
instance, if I'm writing a distributed application with a specific purpose, in 
most cases I can think of per domain concerns this is the case, I'm going to use 
a specific Entry type in the different distributed components, and thus the 
compiler will provide that safety for at runtime nothing will be accessing those 
Entries without knowing their specific types. I think this is something we 
should just warn about in documentation and explain the specifics; that is a lot 
to work around and possibly adding more overhead to the system. We should 
explain concerns from both views points: an unpredictable system capable of 
viewing and using types which are not known at compile time in the system 
components and where they are known. I believe most use cases are where they are 
known. Maybe I'm wrong. This is my own experience and point of view of course.



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


View raw message