[rfc][icedtea-web] Fix to PluginMessage dates for PR2063

[Jie Kang]

----- Original Message -----
> >>
> >> Yes , I vote for v1 deffinitely.
> >>
> >> However - the sorting in consoel could not work for you - have
> >> youtried!?!?!?
> >>
> >> Tehre is:
> >>                   case 4:
> >>                       Collections.sort(sortedData, new
> >>                       CatchedMessageWithHeaderComparator() {
> >>                           @Override
> >>                           public int body(MessageWithHeader o1,
> >>                           MessageWithHeader o2) {
> >>                               return
> >>                               o1.getHeader().date.compareTo(o2.getHeader().date);
> >>                           }
> >>                       });
> >>
> >> You  had to got compley insane results....
> >>
> >>
> >>
> >> I think the fix must go deeper.
> >>
> >> What I consider as best fix is:
> >> in console ouput (in header is on) to have the  most correct "result of
> >> main[4]" //rfc
> >> However, the sorting operation must be done against originalTimeStamp .
> >> hmm.
> >> I would like to test,
> >> if there canbe case when the originalTimeStamp and p.date may have really
> >> different (eg by hours or
> >> more)  values....
> >
> > Hello,
> >
> >
> > Hmm. Well I did a patch that covers the sorting (attached), but I noticed
> > that itw-applet messages don't get localized:
> >
> > [jkang][ITW-APPLET][MESSAGE_DEBUG][Fri Nov 14 17:49:28 CET 2014]
> > [jkang][ITW-C-PLUGIN][MESSAGE_DEBUG][Fr Nov 14 17:49:08 CET 2014]
> >
> >
> > Should we also localize the java dates too? I think then version 2 will be
> > better, since the java date localization != strftime localization:
> >
> > e.g:
> > cs_CZ
> >      Út lis 04 09:02:52 EST 2014 : strftime format
> >      Út XI 04 09:02:52 EST 2014 : java date format
> >
> > I think it will be much harder to convert java date -> strftime date, as
> > opposed to strftime date/timestamp -> java date.
> >
> >
> > Ugh.. Or can we leave as is...
> >
> >
> >
> > Regards,
> >
> >
> >
> >>
> 
> Hi!
> 
> The patch looks almost good - *almost* :)
> 
> I really do not understand :
> +            p.timestamp = new Date(Long.parseLong(init[1]) /
> 1000).getTime();
> 
> Why to long to date  and then to long again???
> 
> Anyway - I think we should stay with date Instead of:
> 
> 
> -    public Date date = new Date();
> +    public String date;
> +    public Long timestamp;
> 
> I would go with
> 
> 
> -    public Date date = new Date();
> +    public String date;
> +    public Date timestamp;
> 
> 
> NIt:
> 
> +            p.date = main[4];
> +
> +
> imho one  \n is enough :)
> 
> 
> 
> After the long->date->long is fixed and
> -                            return
> o1.getHeader().date.compareTo(o2.getHeader().date);
> +                            return
> o1.getHeader().timestamp.compareTo(o2.getHeader().timestamp);
>                           }
> you are sure returns correct order, it seems to be ok for head. But please
> send one more times.

Hello,

I've added all the fixes you suggested. Thanks for the review! How does it look?


Cheers,

> 
> 
> J.
> 
> 
> 

-- 

Jie Kang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itw-pr2063-3.patch
Type: text/x-patch
Size: 3654 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141118/c71faec9/itw-pr2063-3.patch>