Hello,
Please review the change for JDK-8048123. This change removes all the
era definitions in ${java.home}/lib/calendars.properties. (The property
file will eventually be gone later.) The major change is that any new
era of the Japanese calendar should now be defined using new property
"jdk
It seems that the system property only supports one additional era.
Given that Japanese eras are based on human lifetimes, that seems an
invalid assumption.
Stephen
On 22 July 2014 08:06, Masayoshi Okutsu wrote:
> Hello,
>
> Please review the change for JDK-8048123. This change removes all the er
The assumption here is that it's enough to support one additional era
until the era is added to the built-in eras in update releases.
Masayoshi
On 7/22/2014 4:52 PM, Stephen Colebourne wrote:
It seems that the system property only supports one additional era.
Given that Japanese eras are based
On 22/07/2014 08:06, Masayoshi Okutsu wrote:
Hello,
Please review the change for JDK-8048123. This change removes all the
era definitions in ${java.home}/lib/calendars.properties. (The
property file will eventually be gone later.) The major change is that
any new era of the Japanese calendar
On 7/22/2014 9:49 PM, Alan Bateman wrote:
There are a couple of @SuppressWarnings values that I don't recognize,
are these warnings that javac emits?
These are what netbeans complained and suggested. So I assume that these
warnings are all from javac.
Other minor comments in passing. The cha
On 22/07/2014 14:06, Masayoshi Okutsu wrote:
:
Other minor comments in passing. The changes to
LocalGregorianCalendar.parseEraEntry highlight that it is still using
StringTokenizer, there might an opportunity to use String split here
instead.
But split() uses regex, which I think is too exp
A Japanese Emperor might only reign for one day or one week, which is
far less time than a JDK update. It seems to me that one additional
era is quite a risk to be baking into the JDK.
Stephen
On 22 July 2014 09:05, Masayoshi Okutsu wrote:
> The assumption here is that it's enough to support
You are right. Those could happen in theory. As far as I checked, there
are two eras which are shorter than one year, 朱鳥 in 686 (Julius) and
天平感宝 in 749 (Julius). Both have only a few months. So I wouldn't say
it's quite a risk, especially under the current rule, one era per emperor.
One issue
Okutsu-san,
I have one question. It looks like if the user specifies the additional
era syntactically incorrect, it throws a RuntimeException. Should it
just be ignored, as the spec reads "If the given era is invalid, such as
the since value before the beginning of the last predefined era, the
Hi,
Please review the tzdata2014e [1] integration fix to JDK9:
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.00/
Two issues with JSR310 implementation were discovered during integration
process:
First issue is related to the internal representation of the '24:00'
value. The JSR310 imp
Thank you for catching it! I forgot to restore "return null;".
Masayoshi
On 7/23/2014 3:44 AM, Naoto Sato wrote:
Okutsu-san,
I have one question. It looks like if the user specifies the
additional era syntactically incorrect, it throws a RuntimeException.
Should it just be ignored, as the sp
11 matches
Mail list logo
