On 04/02/15 17:21, Christian Thalinger wrote:
-const jlong MAX_DIFF_SECS = 0x01; // 2^32
+const jlong MAX_DIFF_SECS = 0x01LL; // 2^32
Don’t use LL directly; we have a compiler-dependent macro for this:
CONST64
Hi Christian,
I have pushed the change as it was reviewed
On Feb 4, 2015, at 3:31 AM, Daniel Fuchs daniel.fu...@oracle.com wrote:
Hi,
Please find below a fix for:
8072450: 9-dev build failed on elinux-i586 and rlinux-i586
My fix for JDK-8068730 which was integrated from hs-rt into jdk9-dev
yesterday is causing a build failure in the
The spec is pretty clear:
the proleptic-year to check, not validated for range
Adding an exception to the spec would cause requests to add exceptions
to all other chronologies. Doing so, would be very negative to
performance (it would require having a non-public copy of the logic
elsewhere to
On 04/02/15 16:01, Peter Levart wrote:
On 02/04/2015 04:45 PM, Alan Bateman wrote:
On 04/02/2015 15:10, Weijun Wang wrote:
It should be checked, otherwise a non-initialized parent object comes
into being.
In general then permission checks in constructors are a bad idea but
we have an
The MINUTES, HOURS, and DAYS fields of TimeUnit are missing an @since 1.6 tag.
webrev: http://cr.openjdk.java.net/~sla/8072456/webrev.00/
http://cr.openjdk.java.net/~sla/8072456/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8072456
https://bugs.openjdk.java.net/browse/JDK-8072456
Approved. Good find. I made an effort to automatically find all the
missing @since back in the 1.6 days, but apparently it didn't find missing
added enum values.
jsr166 CVS updated.
On Wed, Feb 4, 2015 at 12:48 AM, Staffan Larsen staffan.lar...@oracle.com
wrote:
The MINUTES, HOURS, and DAYS
The platform specific directories in jtreg are going away in favor of a
platform-agnostic directory.
Small fix below.
Thanks,
/Staffan
diff --git a/test/Makefile b/test/Makefile
--- a/test/Makefile
+++ b/test/Makefile
@@ -267,8 +267,8 @@
EXTRA_JTREG_OPTIONS += -concurrency:$(CONCURRENCY)
On 04/02/2015 08:51, Staffan Larsen wrote:
The platform specific directories in jtreg are going away in favor of a
platform-agnostic directory.
Small fix below.
Thanks,
/Staffan
diff --git a/test/Makefile b/test/Makefile
--- a/test/Makefile
+++ b/test/Makefile
@@ -267,8 +267,8 @@
On 04/02/2015 08:48, Staffan Larsen wrote:
The MINUTES, HOURS, and DAYS fields of TimeUnit are missing an @since 1.6 tag.
webrev: http://cr.openjdk.java.net/~sla/8072456/webrev.00/
http://cr.openjdk.java.net/~sla/8072456/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8072456
Hi,
I think we should as consistent as possible about the functions being
side-effect free when applied to bulk operations. A method such as
computeIfAbsent can be viewed as a bulk operation in that it may perform two or
more dependent actions (they are just not as bulky as forEach).
It's
Hi,
Clarifying that Chronology.isLeapYear is specified only within the range
of the chronology
makes it possible to maintain the invariants with the calendar
computations and methods.
Best effort isn't testable except in an implementation specific way and
can't be relied on.
The other two
On 02/04/2015 05:19 PM, Chris Hegarty wrote:
On 04/02/15 16:01, Peter Levart wrote:
On 02/04/2015 04:45 PM, Alan Bateman wrote:
On 04/02/2015 15:10, Weijun Wang wrote:
It should be checked, otherwise a non-initialized parent object comes
into being.
In general then permission checks in
Hi Roger,
I think it looks fine.
If you wanted to and not necessary, you could use assertFalse vs assertEquals
in your test (more of a style choice )
Thank you for the javadoc as it is clearer that way
Best
Lance
On Feb 4, 2015, at 4:17 PM, Roger Riggs roger.ri...@oracle.com wrote:
Hi
Hi Stephen,
That covers the cases better.
The updated javadoc is:
http://cr.openjdk.java.net/~rriggs/xx/java/time/chrono/Chronology.html
http://cr.openjdk.java.net/~rriggs/xx/java/time/chrono/HijrahChronology.html
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
Roger
On Feb 4, 2015, at 9:44 AM, Daniel Fuchs daniel.fu...@oracle.com wrote:
On 04/02/15 17:21, Christian Thalinger wrote:
-const jlong MAX_DIFF_SECS = 0x01; // 2^32
+const jlong MAX_DIFF_SECS = 0x01LL; // 2^32
Don’t use LL directly; we have a compiler-dependent macro
Thanks Lance, I updated to use assertFalse.
On 2/4/2015 4:32 PM, Lance Andersen wrote:
Hi Roger,
I think it looks fine.
If you wanted to and not necessary, you could use assertFalse vs
assertEquals in your test (more of a style choice )
Thank you for the javadoc as it is clearer that way
Hi Roger,
I think I know what this is trying to say, but if possible, could you provide
the revised javadoc so it is easier to see the full context?
Best
Lance
On Feb 4, 2015, at 2:08 PM, Roger Riggs roger.ri...@oracle.com wrote:
Hi,
Clarifying that Chronology.isLeapYear is specified only
I think this might be clearer:
* Checks if the specified year is a leap year.
* p
* A leap-year is a year of a longer length than normal.
* The exact meaning is determined by the chronology according to the
following constraints.
* ul
* lia leap-year must imply a year-length longer than a non
On 02/04/2015 02:54 PM, Chris Hegarty wrote:
On 02/02/15 20:52, Alan Bateman wrote:
I'm happy with this approach. One outstanding point from the discussion
is whether the URLStreamHandlerFactory implementation will need to be
granted RuntimePermission(setFactory), if so then this will need
On 02/04/2015 03:29 PM, Peter Levart wrote:
On 02/04/2015 02:54 PM, Chris Hegarty wrote:
On 02/02/15 20:52, Alan Bateman wrote:
I'm happy with this approach. One outstanding point from the discussion
is whether the URLStreamHandlerFactory implementation will need to be
granted
On 04/02/2015 14:29, Peter Levart wrote:
:
I agree that this is the most appropriate way with which you can force
some provider's class code (the constructor) in the call stack so that
you get correct AccessControlContext to check against. But the name
starts to sound like German words. :-)
On 02/04/2015 04:45 PM, Alan Bateman wrote:
On 04/02/2015 15:10, Weijun Wang wrote:
It should be checked, otherwise a non-initialized parent object comes
into being.
In general then permission checks in constructors are a bad idea but
we have an established idiom that has the no-arg
Hi Stephen,
On 2/4/15 10:43 AM, Stephen Colebourne wrote:
The java.time code generally takes a lenient approach to methods that
return a boolean. For example, they tend to accept null inputs without
throwing an exception.
Seems like an odd design provision leading to some behavior that
would
Looks good overall.
Only comment is whether there should be a p tag after the /ul and
before Outside the range. The resulting javadoc looks like it needs
it, although I don't know what the OpenJDK house rule is for that
case.
Stephen
On 4 February 2015 at 21:17, Roger Riggs
I prefer this approach of discouraging/preventing side-effects via CME,
rather than allowing them. Keep the functions functional, as it were.
If there are situations where determining the mapping for one key
necessitates making additional changes to the Map, that should be coded
some other
On 02/04/2015 05:01 AM, Paul Sandoz wrote:
So i propose:
- the functions should be side-effect free.
...
- concurrent map implementations should, on a best-effort basis, detect
non-termination situations and fail with ISE.
We did this as part of changes to better detect recursive
On 5/02/2015 6:17 AM, Christian Thalinger wrote:
On Feb 4, 2015, at 9:44 AM, Daniel Fuchs daniel.fu...@oracle.com wrote:
On 04/02/15 17:21, Christian Thalinger wrote:
-const jlong MAX_DIFF_SECS = 0x01; // 2^32
+const jlong MAX_DIFF_SECS = 0x01LL; // 2^32
Don’t use LL
Looks good to me.
Masayoshi
On 2/4/2015 12:59 AM, Aleksej Efimov wrote:
Hi,
Could I have a review the latest tzdata2015a integration fix to JDK9,
please. The regression tests run and JPRT testing (jdk_other,jdk_util,
jdk_text, jdk_time test sets) shows no TZ related JDK9 failures.
Thank
Hi,
Please find below a fix for:
8072450: 9-dev build failed on elinux-i586 and rlinux-i586
My fix for JDK-8068730 which was integrated from hs-rt into jdk9-dev
yesterday is causing a build failure in the jdk9/dev nightly on two
platforms.
It appears that these platforms have a slightly
On 02/02/15 20:52, Alan Bateman wrote:
I'm happy with this approach. One outstanding point from the discussion
is whether the URLStreamHandlerFactory implementation will need to be
granted RuntimePermission(setFactory), if so then this will need to go
into the javadoc.
I think that we
Agreed. Updated in-place
http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html
-Chris.
On 04/02/15 14:44, Alan Bateman wrote:
On 04/02/2015 14:29, Peter Levart wrote:
:
I agree that this is the most appropriate way with which you can force
some provider's class code
It should be checked, otherwise a non-initialized parent object comes
into being.
On 2/4/2015 22:38, Peter Levart wrote:
Just a thought,...
Is JVM bytecode verifier checking that a constructor chains to super
constructor? If yes, we are ok. If not, specially crafted bytecode could
skip
Hi Stephen,
I also indicated in the Jira comments that it is misleading and
incorrect to return
false when it is not known that a year is or is not a leap year. All of
the other
HijrahChronology computations throw DTE for invalid dates and the same
may be
true for other Chronologies.
The
Looks good!
Thanks,
/Staffan
On 4 feb 2015, at 12:31, Daniel Fuchs daniel.fu...@oracle.com wrote:
Hi,
Please find below a fix for:
8072450: 9-dev build failed on elinux-i586 and rlinux-i586
My fix for JDK-8068730 which was integrated from hs-rt into jdk9-dev
yesterday is causing a
Reviewed!
Just to clarify for others - only nightly builds seem to be affected by
this due to use of very old gcc version. So developers should be
unlikely to see this. JPRT is not affected.
Thanks,
David
On 4/02/2015 9:31 PM, Daniel Fuchs wrote:
Hi,
Please find below a fix for:
8072450:
The java.time code generally takes a lenient approach to methods that
return a boolean. For example, they tend to accept null inputs without
throwing an exception.
Right now, this patch makes a subclass implementation incompatible
with the superclass spec. That cannot happen. Thus there are only
On 04/02/2015 15:10, Weijun Wang wrote:
It should be checked, otherwise a non-initialized parent object comes
into being.
In general then permission checks in constructors are a bad idea but we
have an established idiom that has the no-arg constructor invoking a
static method that does the
37 matches
Mail list logo
