Well, surely there are some situations where there is a workaround possible to avoid or minimize code duplication. However there are things where I can not find an option.
* What if I have a basic exception class that will use the new constructor introduced in Java 1.7 with the two booleans but I also want to use the exception classes in shared code?
* What if I want to overwrite a method like printStackTrace(PrintStream) or the like but leave it alone in GWT emul?
* What if I have a class that has has its own Java serialization based on readObject/writeObject?
* etc.
For all these situations there is no easy solution. You might not have these often, but I do. Maybe you could argue that I do something wrong.
No matter how this would not really lead us anywhere.
I just wanted to point out some kind of (maybe exotic) demand and a suggestion or idea that come to my mind.
If I am the only one there is probably no good reason for additional support and I will live with my maintenance problems or implement my own tooling on top.
In case there are others having the same problem, just join in...
Thanks for all the suggestions so far...
Regards
Jörg
Am Dienstag, 29. April 2014 13:07:43 UTC+2 schrieb Thomas Broyer:
-- * What if I have a basic exception class that will use the new constructor introduced in Java 1.7 with the two booleans but I also want to use the exception classes in shared code?
* What if I want to overwrite a method like printStackTrace(PrintStream) or the like but leave it alone in GWT emul?
* What if I have a class that has has its own Java serialization based on readObject/writeObject?
* etc.
For all these situations there is no easy solution. You might not have these often, but I do. Maybe you could argue that I do something wrong.
No matter how this would not really lead us anywhere.
I just wanted to point out some kind of (maybe exotic) demand and a suggestion or idea that come to my mind.
If I am the only one there is probably no good reason for additional support and I will live with my maintenance problems or implement my own tooling on top.
In case there are others having the same problem, just join in...
Thanks for all the suggestions so far...
Regards
Jörg
Am Dienstag, 29. April 2014 13:07:43 UTC+2 schrieb Thomas Broyer:
On Tuesday, April 29, 2014 10:48:09 AM UTC+2, Jens wrote:Hm for simple things there is now @GwtIncompatible. Anything annotated with it will be ignored by the compiler.In other cases it might be possible to refactor classes so they take a constructor dependency (interface) which would be different for client and server (implementation).…or an utility class as small as possible that's then super-sourced (see SafeHtmlHostedModeUtils, SafeStylesHostedModeUtils and SafeUriHostedModeUtils for examples of that pattern)
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment