On Dec 1, 2013, at 3:13 PM, Nick Williams wrote: > > On Dec 1, 2013, at 12:52 PM, Xueming Shen wrote: > >> On 12/1/13 10:29 AM, Nick Williams wrote: >>> I filed these bugs back in June. I noticed today that they were migrated to >>> the JIRA instance: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8016742 >>> https://bugs.openjdk.java.net/browse/JDK-8016743 >>> >>> I filed the bugs, though they say someone else did. It's frustrating that >>> suddenly I can't even comment on bugs I created, but that's beside the >>> point of this email... >>> >>> I'm dismayed to see that 8016743 has been scheduled for being fixed in JAVA >>> 9! What the heck!? If I can't use the new Java 8 Date & Time types in >>> Java's localization support, then what good are they!? I have to just stick >>> with java.util.Date for yet another two years because I can't localize Java >>> 8 Date & Time types in my i18n message formats. That's not the quality that >>> I normally expect out of the Java team. >:-[ >> >> java.time has its own formatting/parsing mechanism/support via >> java.time.format package, in which >> it does have l10n/i18n support for print/parsing the new java.time date/time >> types for various locales. >> Any particular reason you must use j.text.MessageFormat to print/parse the >> java.time date/time types? > > Yes: So that you can use message formats in ResourceBundles with java.time > types. For example: > > [resource bundle file contents] > some.message.key=You last logged in on {1,date,long} at {2,time,long}. > [/resource bundle file contents] > > And then, in a JSP (just one example use case): > > <fmt:message key="some.message.key"> > <fmt:param value="${model.lastAccessInstant}" /> > <fmt:param value="${model.lastAccessInstant}" /> > </fmt:message> > > Resource bundle messages _must_ follow the MessageFormat conventions. > MessageFormat only supports java.text.DateFormat. DateFormat only supports > java.util.Date. MessageSource needs to also support > java.time.format.DateTimeFormatter, otherwise you can't use java.time types > with resource bundle messages.
Sorry, I meant to say "MessageFormat needs to also support java.time.format.DateTimeFormatter, otherwise you can't use java.time types with resource bundle messages...". N > > Nick > >> >> -Sherman >> >>> >>> 8016742 is a slightly different story. It's higher priority than 8016743, >>> and although there is absolutely no update about it, it appears that MAYBE >>> it's scheduled for being fixed in Java 8? I have no idea what "tbd_major" >>> means. Note that a fix for 8016743 could potentially help fix 8016742. >>> >>> Is there anyone here that can shed some light on 8016742's status and why >>> the heck 8016743 isn't getting fixed until Java 9? >>> >>> If not, can someone point me to a more appropriate list that I can escalate >>> my frustrations on? These awesome new date & time types are useless if they >>> aren't supported in Java's i18n/L10n and JAXB components. >>> >>> N >>> >>> On Jun 17, 2013, at 8:17 AM, Nick Williams wrote: >>> >>>> On Jun 17, 2013, at 6:53 AM, Stephen Colebourne wrote: >>>> >>>>> On 17 June 2013 12:40, Alan Bateman <alan.bate...@oracle.com> wrote: >>>>>> On 17/06/2013 11:05, Nick Williams wrote: >>>>>>> Thanks. I have filed two different bugs for these two different >>>>>>> problems. >>>>>> Here they are: >>>>>> >>>>>> 8016743: java.text.MessageFormat does not support java.time.* types >>>>>> 8016742: JAXB does not support java.time.* types >>>>>> >>>>>> Note that JAXB is maintained in an upstream project (they periodically do >>>>>> source drops into OpenJDK). I don't know if support for java.time >>>>>> requires >>>>>> API changes or not but just to mention that JAXB is tied to a standalone >>>>>> JSR >>>>>> and I think they the requirement to be able to drop-in into jdk7 builds. >>>>> That could be a problem, but its really a process one. It shouldn't be >>>>> users that suffer as a result of issues like that (but there isn't >>>>> anything I can do about it other than wave my hands...) >>>>> Stephen >>>> ^^ What Stephen said. :-) >> >
