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

[Nick Williams]

On Dec 2, 2013, at 1:47 PM, Xueming Shen wrote:

> 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.

Nope.

MessageFormat is a universal i18n formatting class for messages that contain number, currency, percentage, date, and time parameters. If I have a message like this:

You last logged in on {0,date,long} at {0,time,long}. You have logged in {1,number} times.

I should be able to pass this message to a single method/class, supply parameters/arguments, and have the message formatted correctly. With MessageFormat, I can. The problem is that Java 8 now offers more date and time types, and MessageFormat was not updated to support those new types. That would be like adding a new primitive to Java (let's call it "extralong") and not updating MessageFormat to support that primitive. I shouldn't have to parse the message myself, pull out the date and time parameters, pass those to a java.time.format.DateTimeFormatter to format those parameters, replace them in the message, then pass the rest of the message to the MessageFormat to handle other parameters.

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

This isn't just about that tag. That tag doesn't support OR not support java.text.DateFormat or java.time.format.DTF. It supports MessageFormats. That's it. MessageFormat is part of the SE's core i18n support. If java.time can't work with MessageFormats, it's going to be a problem. The solution is for MessageFormat to support java.time.DTF.

> 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. :-)
>