You can provide a dummy supersource implementation of SimpleDateTimeFormat so that it would compile.
On Jun 2, 12:12 pm, Ed Merks <ed.me...@gmail.com> wrote: > I'm busy refining EMF's support for GWT: > > http://wiki.eclipse.org/EMF/New_and_Noteworthy/Helios#Support_for_Goo... > > One of the problems I have is that I need to support converting date > instances to and from a string representation, in particular, one that > conforms to XMLSchema's dataTime format. I have that working nicely in > regular Java with SimpleDateFormat, but that's not supported by GWT. > So I ported it to use DateTimeFormat. That's working nicely too. But > now, after more testing, I realize that DateTimeFormat doesn't work on > the server, because it depends on locale stuff, which the server > doesn't support. That's unfortunate because the format I'm producing > isn't actually locale specific. In any case, what I really want is a > single library that works for both the client and the server. I get > the sense that I need two different implementations, a default one > that's good on the client, and a different one that works on the > server. > > There are many tricks I could play if this were all pure Java. I've > done similar things to make EMF work both within Eclipse and as stand > alone jars. But I'm all out of ideas for how to make this work with > GWT and I was hoping someone would have a good suggestion. As an > example of an approach I might use is: > > if (GWT.isClient()) > { > // Use DateTimeFormat} > > else > { > // Use SimpleDateFormat > > } > > That doesn't work of course because the GWT compiler will complain > about SimpleDateFormat even though that code path will never be taken > on the client. I thought the GWT compiler might prune out the > unreachable branch. If I could move the "else" part to a different > method and mark that whole method as to-be-ignored by the GWT > compiler, that would make me happy too, but I didn't find any > annotation that would direct the GWT compiler to ignore something. > > Another approach I could take is to inject different implementations > depending on where I'm running, client or server. That's certainly > feasible, but where to put the initialization code? To make it > easier, I could have a default implementation that works on the client > and then in the case of running on the server, initialization code > would inject one that works for the server. I could a call to such a > hook in every XyzServiceImpl, full Java is allowed there, but that's > easy to forget and kind of annoying. How could I ensure that such > server-specific, won't-compile-with-GWT, initialization code is > invoked once for the server? > > Any other ideas for how I could maintain a single source/library/ > project that adaptively works for both the client and the server based > on different implementation classes? -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
