I believe that I may have mis-stated what the problem actually is.
A simple example of the service that I would like to implement is as
follows.
public interface ActionService extends RemoteService {
<A extends Action<R>, R extends Result> R execute(A action);
}
So that I have type checking I would like to use the following async
version of this service.
public interface ActionServiceAsync {
<A extends Action<R>, R extends Result> void execute(A action,
AsyncCallback<R> callback);
}
However, when I try to do this I end up with the following errors during
validation of the generated units.
Adding '8' new generated units
Validating newly compiled units
[ERROR] Errors in
'generated://85B128B658575A411C689D206650AC89/net/teirney/gwt/rpc/client/ActionService_Proxy.java'
[ERROR] Line 11: The type ActionService_Proxy must
implement the inherited abstract method ActionServiceAsync.execute(A,
AsyncCallback<R>)
[ERROR] Line 23: Name clash: The method execute(Action,
AsyncCallback) of type ActionService_Proxy has the same erasure as
execute(A, AsyncCallback<R>) of type ActionServiceAsync but does not
override it
See snapshot:
/tmp/ActionService_Proxy63212959022588105.java
Ideally so that one does not loose the type safety of the
ActionServiceAsync by using the erased type I applied the patch (albeit
the patch may not be entirely correct).
There are certainly ways to get around the lack of type checking, such
as not using the Async interface directly but via a wrapper class that
applies the type checking for the caller. This is what is done in
gwt-dispatch to get around this problem.
It may well be by design that type parameters are not supported in the
Async interface by design and I may have missed that somewhere.
On 2010/06/03 14:35:09, Lex wrote:
I believe type parameters work fine. Can you give an example that
doesn't work?
I just tried modifying EnumTest to verify that at least in simple
cases, it
works.
The way this works relies on Java generics having been defined to have
compatibility with pre-generic Java. You can always erase a type and
use that
instead of the original, complex type--though of course losing the
benefits of
type checking. By using erased types, GWT's current implementation is
a bit
simpler.
That's the theory. Do you have an example of something you'd like to
work that
does not? If so, we can patch it as you describe. However, one more
thing that
needs to be done is to handle bounds on the type parameters. For this
facility
to be useful in practice, the type parameters will need to be bounded
anyway,
because otherwise the RPC interface will effectively specify that
objects must
be passed back and forth.
http://gwt-code-reviews.appspot.com/575801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
