river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Fw: Re: Space/outrigger suggestions
Date Sat, 18 Dec 2010 11:43:36 GMT
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?


----- Original message -----
> Users are already capable of creating the problem case you outlined with the
> existing space implementation, and adding generics to the javaspace methods
> doesn't make it worse.
> The most compelling problem case I've thought of is this:
> GenericizedEntry<T extends Serializable> implements Entry {
>  T val = null;
> }
> space.read(new GenericizedEntry<String>());
> The "null" would fetch results of all types, which contradicts the principle of
> least surprise, and the generic would foul things up at runtime.
> However, again, this is already something that can happen with spaces.    Unless
> the user were to check both the top level type and underlying generic field
> before casting, the user would make the same mistake upon casting.
> On the other hand, if we assume the user were savvy enough to do the runtime
> check of both the type and any generic fields... then we might as well also
> assume they're savvy enough to use broadest available type if passing in a null
> field (in this case Serializable).    There are not likely many who would
> recognize one problem but not the other.
> If the user is going to be using generic-laden fields in their Entries, they
> need to have a fair knowledge of generics and/or trust in whoever is providing
> the entries they are reading.    The inclusion of generics in the interface
> methods will not change this, for good or ill.    (For that matter, neither does
> usage of generics on our part exclude the possibility of using raw types as a
> user.)
> ---
> At this point, I still favor the idea of including generics in the interface. 
> Upon consideration of these problem cases, we seem to already be facing the
> problems of type-erased generics in the language without reaping any of the
> benefits.
> I do, however, now fully see the need for a discussion of generic usage and
> expectations within space documentation.    We need to do that whether or not
> generics are in the interface, because those issues can already happen.
> jamesG
> -----Original Message-----
> From: "Peter" <jini@zeus.net.au>
> Sent: Saturday, December 18, 2010 3:11am
> To: river-dev@incubator.apache.org
> Subject: Fw: Re: Space/outrigger suggestions
> if you have a field in an Entry declared:
> public Collection<String> names;
> In bytecode, because of erasure, its type is Collection, this means I can take
> from the javaspace and set the field to contain a Collection that doesn't
> contain String's and the next time your code accesses it, a ClassCastException
> will occur.
> If your not using generics, you can check it's type before performing a type
> cast.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message