Thursday, March 24, 2016

Re: Why can I not extend java.util.Date?

If you do extend Date, I would not use any 3rd party library calls that take a Date and may use Day of Week, as they might well explode on Sundays.  And that has the same problem as a util class, you may forget and make the call somewhere.  It's really a lose-lose situation.

You're not really saying what you're doing with the ISO DOW, but you do know that SimpleDateFormat supports the ISO enumeration, right?  Looks like "u" is the Monday = 1, Sunday = 7 version, though "F" may also work.

As for the Java 8 java.time support, it appears it is planned but not yet in-progress:

On Thursday, March 24, 2016 at 8:25:09 AM UTC-5, Stefan Falk wrote:
My main problem here is that on the server side everything is following the ISO standard MONDAY = 1, TUESDAY = 2, .. etc and since we only got Date on he client things can get mixed up. This is why I thought I could wrap/extend Date and just override the getDay() method in order to
  • have the mapping exactly where I need it and
  • get rid of all the deprecation warnings in my code as I use only MyDate
I agree with you.. Dates are very hard to handle and I really hate it actually ^^ That is even more a reason for me to get things straight with my client and server. Having to call another method from another util class is also just not what I am looking for - it can also be forgotten somewhere.

Speaking of Date .. will there actually be support for all of the fancy Date/Time stuff that came with Java 8? Again, like you said, working with Dates is very hard sometimes so imho it would be very important to get there with GWT. But I understand that this might also not be that easy and it must have a particular reason why it's not yet there.

On Tuesday, 22 March 2016 16:01:11 UTC+1, Chad Vincent wrote:
1) Dates are very, very, very hard.  Calendar idiosyncrasies, time zones, leap seconds...  Be 100% sure you need to actually extend Date before messing with it.
2) You are probably better off putting your method (presuming this is the only one) in a custom utility class instead of extending Date so you don't alter the functionality of any other libraries you use that aren't expecting DOW to be non-standard.
getCustomDay(Date date) {
if (date.getDay() == 0)
    return 7;
return date.getDay();

On Sunday, March 20, 2016 at 12:24:09 PM UTC-5, Stefan Falk wrote:
Working with Date is a nightmare.. so beforehand: Any advice regarding work with time and date in GWT are very welcome!

Why do my requests silently fail if I do this:

public class AwesomeDate extends java.util.Date {

  public final static int MONDAY = 1; 
  public final static int TUESDAY = 2; 
  public final static int WEDNESDAY = 3; 
  public final static int THURSDAY = 4; 
  public final static int FRIDAY = 5; 
  public final static int SATURDAY = 6; 
  public final static int SUNDAY = 7;

  public int getDay() { 
    switch(super.getDay()) { 
    case 1:
      return MONDAY;
    case 2:
      return TUESDAY;
    case 3:
      return WEDNESDAY;
    case 4:
      return THURSDAY;
    case 5:
      return FRIDAY;
    case 6:
    return SATURDAY;
      case 0:
      return SUNDAY;
    throw new RuntimeException();

and then

AwesomeDate fromDate = ..
AwesomeDate toDate = ..

myObjectEnter.request(fromDate, toDate, onSuccess, onFailure);


MyObject#request(Date from, Date to, OnSuccess<ResultDTO> success, OnFailure failure);

Because if I do that my request does simply nothing. It's not even getting sent off.. I have an object that takes care for parallel requests

 for (ParallelizableRequest<?> parallelizableRequest : this.childRequests) {

but that request that is using AwesomeDate is simply not being executed. In the JavaScript debugger I see that the list childRequests contains two elements but that's all I can tell.

Any ideas?

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
To post to this group, send email to
Visit this group at
For more options, visit

No comments:

Post a Comment