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