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.
Peter.
