river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: correctness, generics, and spaces
Date Thu, 02 Jun 2011 02:29:22 GMT
Patricia Shanahan wrote:
> On 6/1/2011 6:19 PM, Peter Firmstone wrote:
>> The argument for generics in remote interfaces is to reduce boilerplate
>> code, the argument against is, it introduces unchecked type casts. (See
>> earlier discussion)
>> Is there another way to reduce the boilerplate code, using annotations
>> perhaps?
> ...
> Could we use annotations to get rid of the "unchecked conversion"
> warnings? As I understand it, the compiler generates code that is type
> safe even if e.g. a collection contains references to objects of
> unexpected classes.
Normally in code compiled and linked at compile time, 
@SuppressWarnings("unchecked") would do the trick, since the compiler 
catches the error.

||However in code compiled separately no warning will be issued when 
linked at runtime, the compiler is not involved. Services and clients 
come together dynamically at runtime, so they miss out on compiler type 
checking.  No compiler errors will be issued, some code just works, 
other code doesn't and fails with a runtime exception.

EG, A Service interface method:

T get();

A service is compiled and type checked in bytecode to use:

Apple get();

The client is compiled and type checked in bytecode to use:

Orange get();

The client and service use the same service interface, but they are not 
compatible.  They might be compatible as Fruit and have the same method 
eat(), but they will fail at runtime as each is cast to it's own type.

Typically if only one developer knows about the service and clients, 
there are no issues, the unchecked type casts, never get cast to the 
wrong type.  Involve a group of developers working together on a 
project, then things will start to fail.

I believe an annotation that flags ASM to post process the byte code to 
add runtime type safety checks would do the trick.|

Then we can say, yes Generics are supported in remote code, you just 
need to add this @RuntimeServiceCheck annotation.

I can see the attraction to adding Generics to Javaspace, it looks like 
a collection after all.  But typically a Generic collection instance is 
a collection of a single common type, not many different types.

The other problem is the type being returned might not exist at the 
client, so it is loaded by the proxy ClassLoader, its type is not 
visible to the client, it needs to be cast to a common supertype, 
normally defined in the service interface, this problem is unfortunately 
more complex that it first appears.

So I'm hoping that some day we can come up with a simple tool so 
developers don't have to understand the details, if it isn't compatible, 
you catch a RemoteException and move on.


View raw message