*In a distinct difference from regular Java, GWT usually rewards you for being more specific about classes: if you are specific that you return ArrayList only, then GWT only makes a serializer for that, and you save client size. But if you return List<...>, and your classpath for the GWT compile includes all 8 of the vanilla Java "List" types, then GWT has to generate code to handle all of them, leading to code bloat * * * Does this have any run-time slow-ness is it just a compile-time slowness ?
Also, does it increase the ultimate size of the generated javascript? On Wednesday, May 2, 2012 7:35:36 AM UTC-7, Freeland Abbott wrote: > > Roughly speaking, the GWT serialization code---specifically, the part of > the generated server stub that serializes your response to send to the > client---is getting a type of object (PersistentBag) that it knows the > client code won't be able to decode, and is stopping as a result. > > In this case, PersistentBag is a List, and your interface says it might > return any kind of List known to the system. Either the compile of your > GWT app didn't know about the hibernate classes, to include a deserializer > for PersistentBag, or (perhaps at least as likely), the hibernate class is > using some of the features that GWT forbids (e.g. it may be reflective), > and so we can't generate a deserializer for it. You can compile with DEBUG > messages and search for the class name to see what the exact problem is. > But one of those two explains why it's "not included in the set." > > In a distinct difference from regular Java, GWT usually rewards you for > being more specific about classes: if you are specific that you return > ArrayList only, then GWT only makes a serializer for that, and you save > client size. But if you return List<...>, and your classpath for the GWT > compile includes all 8 of the vanilla Java "List" types, then GWT has to > generate code to handle all of them, leading to code bloat because, in > fact, you probably don't actually touch CopyOnWriteArrayList, for example. > And, to your problem, the server runtime may have List types that the > client didn't know about to generate code for, or list types that GWT just > can't handle (but it could handle many others, and doesn't know which > concrete types you might see). > > Since GWT can't prove there *is* an error at compile time, it won't > whine. But, using an interface type in your serialization, there *might* be > a runtime problem, and that's the error message you are seeing. > > You might do better to translate the persisted list into a vanilla > ArrayList, and express your RPC in those terms. Or you might use something > other than RPC as a transport, looking at JSON or RequestFactory as a way > to make the wire protocol lose the detailed Java type and just have a > JavaScript array as the underlying base. > > > >> -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
