Shared DateTimeFormat throws NoClassDefFoundError exception server side due to usage of client code

[dankurka]

Originally reported on Google Code with ID 7671

Found in GWT Release (e.g. 2.4.0, 2.5.0 RC):

2.5.0-rc1

Encountered on OS / Browser (e.g. WinXP, IE8-9, FF7):

N/A (server side)

Detailed description (please be as specific as possible):

com.google.gwt.i18n.shared.DateTimeFormat.getDefaultDateTimeFormatInfo() depends on
a client side class com.google.gwt.i18n.client.LocaleInfo() causing NoClassDefFoundErrors
when used server side.

There is a comment in the method

    // MUSTFIX(jat): implement

This looks like a known issue but I couldn't find a defect open that tracks this problem.

Shortest code snippet which demonstrates issue (please indicate where
actual result differs from expected result):

One way to reproduce this is to have a unit test that executes:

    import com.google.gwt.i18n.shared.DateTimeFormat;
    import com.google.gwt.i18n.shared.DateTimeFormat.PredefinedFormat;
    ...
    DateTimeFormat.getFormat(PredefinedFormat.DATE_LONG);

Workaround if you have one:

N/A

Links to relevant GWT Developer Forum posts:

N/A

Link to patch posted at http://gwt-code-reviews.appspot.com:

N/A

Reported by jeraymond on 2012-09-15 00:48:43

[dankurka]

Reported by t.broyer on 2012-09-15 01:00:45

• Labels added: Category-I18N

[dankurka]

Yes, there is a patch in progress to make all of the i18n APIs usable on the server.
 Unfortunately, I was unable to finish it before I left Google and things have been
very hectic getting up to speed at my new job (at Square).  So, it definitely isn't
going in 2.5, but I expect I will have time to finish it up in about a month.

Until then, you can use the shared APIs to future-proof your code, but they can only
be used on the client.

The work-in-progress (definitely not ready to use right now) is at http://gwt-code-reviews.appspot.com/1775803/

Reported by jat@jaet.org on 2012-09-15 01:12:56

• Status changed: Accepted
• Labels added: Type-Feature

[dankurka]

Thanks for the info. Looking forward to the final patch.

Reported by jeraymond on 2012-09-15 01:41:28

[dankurka]

Issue 7809 has been merged into this issue.

Reported by jat@jaet.org on 2012-11-27 15:00:42

[dankurka]

I am going through issues trying to decide what should go into gwt 2.5.1 any updates
on this one yet?

Reported by kurka.daniel on 2012-12-15 18:24:40

[dankurka]

This is too big a change for a point release anyway, but it will probably be after Christmas
before it is ready.

Reported by jat@jaet.org on 2012-12-15 19:04:15

• Status changed: Started

[dankurka]

Out for review at https://gwt-review.googlesource.com/1550

Reported by jat@jaet.org on 2013-01-02 06:50:14

• Status changed: ReviewPending

[dankurka]

Reported by jat@jaet.org on 2013-01-09 22:51:50

• Labels added: Milestone-2_6, ReleaseNote-Major

[dankurka]

Issue 8091 has been merged into this issue.

Reported by t.broyer on 2013-07-22 11:46:54

[dankurka]

Reported by t.broyer on 2013-07-22 11:52:36

• Blocking: #8263

[dankurka]

Work has stalled and this isn't going to make 2.6.

Reported by skybrian@google.com on 2013-11-12 21:12:50

• Status changed: Started
• Labels removed: Milestone-2_6

[dankurka]

My coworker has just lost 4 hours to find out that this is not working on the server.
A comment in JavaDoc would be helpful in order to avoid using this class on the server
side. (Because it is in "shared" package one can think this will work on server without
problems.)

Reported by marko.krajnc@cursor.si on 2014-11-04 17:39:55

[dankurka]

Can any project member give an update on this problem?

Reported by BreandanDalton on 2014-11-06 13:24:02

[dankurka]

As mentioned above, the solution to this is the full patch supporting i18n in shared
code.  It was out for review earlier this year but was deemed too large a change for
2.7,  but will hopefully make it into 3.0 once 2.7 is finished.

Reported by jat@jaet.org on 2014-11-06 15:05:32

[tiberiughioca]

What it the status of this issue? Is there a workaround for it?

[Anthrac]

The problem still is not fixed in 2.10.

Both methods public static DateTimeFormat getFormat(String pattern) and protected static DateTimeFormat getFormat(String pattern, DateTimeFormatInfo dtfi) internally call LocaleInfo.getCurrentLocale().getDateTimeFormatInfo(), which is in the client side's code and does not work on server side.

Workaround: Use new DateTimeFormat(format, new DefaultDateTimeFormatInfo()) {}; Then there is no caching, but is also works on server side, and caching easily can be done by the caller (p. ex. define it as a constant).

[niloc132]

Unfortunately, the in-progress patch at http://gwt-code-reviews.appspot.com/1775803/ (along with all other code and review content) is lost to us - we requested a dump of the old database back when the instance was running but python 2.7 was no longer supported, and the Googlers with access were not able to share it.

At this point, the best way forward will probably be one of the gwt-i18n forks being feature complete (remaining work: getting closure-compiler to correctly optimize out unused locales and cldr data, and generating implementations for Messages), so that all of this can run on GWT2, J2CL, or the JVM. Alternatively, the workaround described appears to behave.

For those who are using this, how are you defining the expected locale on the server, just statically creating the DefaultDateTimeFormatInfo_{locale goes here} as needed?

---

EDIT: I didn't read carefully enough, the patch was correctly moved to to googlesource, see https://gwt-review.googlesource.com/c/gwt/+/1550. The tail end of the review says that not everything works properly, and the page itself reports conflicts (which might just be out of date CLDR data... unfortunately, the script that updates that is also lost within Google), but it might be the kind of thing that could be merged up to date and tested. I've pushed the branch to my github fork, see https://github.com/niloc132/gwt/tree/7668-in-progress-patch.