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<[email protected]> 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. :-)
>
