There needs to be support for java.time in java.text.MessageFormat

[Xueming Shen]

On 12/01/2013 01: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:

The idea here is to encourage the use of java.time.format for java.time date/time
types, not the Message/DateFormat for the new JSR310 date/time. You should be
able to use DateTimeFormatterBuilder + ResourceBundles to obtain a DateTimeFormatter
for particular locale with customized localized message, for your JSR310 data/time.

Yes, I guess the <fmt:message> tag should support the java.time.format.DTF, if
the argument is a JSR310 date/time types.

That said, it might be desired to add the support of the JSR310 date/time
for the DateFormat, but it will not make jdk8.

-Sherman

> [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.
>
> 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.Bateman at 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. :-)