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

问题描述

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

  public List< Serializable> myMethod（TransactionCall call）{...} 
  

但是我得到分析此方法时出现警告，然后rpc调用失败

 分析'my.project .package.myService'用于可序列化类型
分析方法：
 public abstract java.util.List< java.io.Serializable> myMethod（my.project.package.TransactionCall调用）
返回类型：java.util.List< java.io.Serializable> 
 [...] 
 java.io.Serializable 
验证实例化性
（！）检查所有符合序列化对象的子类型
  

看来我无法使用Serializable作为我的列表...我可以使用自己的接口来代替像AsyncDataInterface，它实现了Serializable接口），但事实是，我的方法将返回一个列表自定义对象和基本对象（如Strings，int ....）。

<所以我的问题是：

• 这是一种非常规的行为吗？ （我不明白为什么我不能在这种情况下使用这个接口）


• 有没有人有这种情况的解决方法？

解决方案

在RPC调用中传递对象时，在RPC接口中声明具体的参数类型是一种很好的做法。如果由于某种原因，您不能在RPC界面中使用具体类，尽可能使其具体。

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

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

  public的ArrayList< YourType> myMethod（TransactionCall call）{...} 
  

而非

  public List< Serializable> myMethod（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 wich qualify for serialization

It seems I can't use Serializable for my List... I could use my own interface instead (something like AsyncDataInterface, wich 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 standart behaviour? (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&lt; Serializable&gt;在RPC调用中？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！