gwt - 使用 List<Serializable>在 RPC 调用中? [英] gwt - Using List&lt;Serializable&gt; in a RPC call?

问题描述

我有一个使用以下方法的 RPC 服务:

<块引用>

public ListmyMethod(TransactionCall call) {...}

但是我在分析这个方法时得到一个警告，然后rpc调用失败

<块引用>

分析可序列化类型的my.project.package.myService"

分析方法:公共抽象 java.util.ListmyMethod(my.project.package.TransactionCall 调用)返回类型:java.util.List[...]java.io.Serializable验证实例化(!) 检查所有符合序列化条件的 Object 子类型

似乎我不能将 Serializable 用于我的列表...我可以改用我自己的接口(例如 AsyncDataInterface，它实现了 Serializable 接口)但事实是我的方法将返回一个列表自定义对象和基本对象(例如 Strings、int ....).

所以我的问题是:

• 这是标准行为吗?(我不明白为什么在这种情况下我不能使用这个界面)
• 有没有人有解决这种情况的方法?

解决方案

当通过 RPC 调用传递对象时，在 RPC 接口中声明具体的参数类型是一个很好的做法.如果由于某种原因您不能在 RPC 接口中使用具体类，请尝试尽可能具体.

这是因为 GWT 编译器在发出 javascript 时必须考虑编译单元中 List 的所有可能变体.这包括在类路径中扩展 List 和 Serializable 接口的所有类.排列可能很大，这将影响您的编译时间以及应用程序下载大小.

所以最好的方法是将你的界面定义为

public ArrayListmyMethod(TransactionCall call) {...}

而不是

public ListmyMethod(TransactionCall call) {...}

那种方式编译器只需要为 ArrayList 和 YourType 扩展生成编译单元.好处是编译时间更快，编译的 javascript 文件更小，因此可以更快地下载您的应用程序.

如果您必须在 RPC 调用中返回大量不相关的对象，请尝试创建一个包装类并返回包装类的对象，并将返回值包装起来.在 RPC 方法定义中使用包装类.抵制将包装字段声明为 Object 或 Serializable 的冲动，您将否定使用包​​装器获得的所有序列化好处.相反，您可以为您希望通过 RPC 调用返回的每个具体类型定义一个 Wrapper 接口和一小组 Wrapper 实现.

I have a RPC service with the following method:

public List<Serializable> myMethod(TransactionCall call) {...}

But I get a warning when this method is analyzed, and then the rpc call fails

Analyzing 'my.project.package.myService' for serializable types

Analyzing methods:
public abstract java.util.List<java.io.Serializable> myMethod(my.project.package.TransactionCall call)
Return type: java.util.List<java.io.Serializable>
[...]
java.io.Serializable
Verifying instantiability
(!) Checking all subtypes of Object which qualify for serialization

It seems I can't use Serializable for my List... I could use my own interface instead (something like AsyncDataInterface, which implements the Serializable interface) but the fact is that my method will return a list custom objects AND basic objects (such as Strings, int....).

So my questions are:

• Is it a standard behavior? (I can't figure out why I can't use this interface in that case)
• Does anyone have a workaround for that kind of situation?

解决方案

When passing objects across RPC call's its a good practice to declare concrete parameter types in the RPC interface. If for some reason you cannot use concrete class in the RPC interface try to be as specific as possible.

This is because the GWT compiler while emitting javascript has to take into account all possible variants of List in the compilation unit. This includes all the classes extending List and Serializable interface in the class path. The permutations can be huge, which will effect your compile time as well as the application download size.

So the best approach is to define your interface as

public ArrayList<YourType> myMethod(TransactionCall call) {...}

rather than

public List<Serializable> myMethod(TransactionCall call) {...}

That way compiler has to generate compilation units for ArrayList and YourType extensions only. The benifit is in faster compile times and smaller compiled javascript files, hence faster downloads of your application.

In case you have to return a wide range of unrelated objects in your RPC call, try creating a wrapper class and return object of the wrapper class with the return value wrapped. Use the wrapper class in the RPC method definition. Resist the urge to declare the wrapped field as Object or Serializable, you will negate all serialization benefits you gained by using a wrapper. Instead you can define a Wrapper interface and a small set of Wrapper implementation for each concrete type you wish to return through your RPC call.

这篇关于gwt - 使用 List<Serializable>在 RPC 调用中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！