A common approach is to have three sets of types: "client", "server", and "shared'. The "client" and "server" are self-evident - these are types that exclusively belong to one runtime, and will never cross over to the other. Shared can be trickier - it must only use other shared types, or types/members that both GWT and JVM can handle.
In turn, both "client" and "server" code can depend on "shared" code. Historically, projects have been advised to use packages separating their classes into these three categories. Typically they would all be in the same base package, with the .gwt.xml module file as a sibling. That .gwt.xml file then would have <source path="client" /> <source path="shared" /> to make this relationship explicit. For at least the last 10+ years while Maven (and later Gradle) were growing in popularity, it has instead been suggested to actually split projects, so you have a shared project, and the client and server projects depend on shared. (Getting off-topic, but following through in the idea: The server project then typically depends on the client JS output, but not the client classes themselves.) This makes it easier to directly control the dependencies of that shared project, and avoid surprising yourself by having server code that depends on client classes, enforcing this separation. GWT-RPC isn't for everyone, though I happen to like it. The above advice is not exclusive to GWT-RPC, but can let you handle sharing business logic between JVM/browser runtimes. There are no specific extra rules to follow when applying to GWT-RPC, since the serialization mechanism is intended to roughly mirror java.io.ObjectOutputStream and friends - mark fields as transient to have them be skipped over, other fields on serializable types will be serialized. Data-Transfer Objects (DTOs) are a popular way to isolate serialized data from business logic, and while it isn't a requirement, you might find it to be a natural conclusion of the above suggestions. Finally there are some "tricks" you can do to get a different implementation of a type using @GwtIncompatible or super source, though any solution that requires two implementations of a type should be scrutinized to see if there's a better way to handle it. You'll find examples on stackoverflow, other public gwt codebases, or the mailing list, but if you can give more specifics we can give examples that may help shed light on your problem. On Saturday, December 14, 2024 at 6:01:55 PM UTC-6 [email protected] wrote: > > it needs a sources.jar during compilation. > > Got it. I added a sources jar but now I am getting many errors about > Log4j, getResourceAsStream, BufferedImage, etc. > > So, obviously, my code refers to a bunch of stuff that is standard to Java > but it outside the scope of GWT. > > I think I might have to write pared-down versions of my data classes just > for GWT or is there a better way to do it? > > Thank you, > Neil > > -- > Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com > We offer 30 year loans on single family houses! > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/f159674f-bee8-4dfc-a269-f7b52b058e34n%40googlegroups.com.
