On 05/12/2015 07:41 AM, Peter Levart wrote:
Taking another look at this deadlock issue and the compatibility
concerns, I wonder if we should keep this change as a special
implementation for system properties rather than having this change to
java.util.Properties class. Properties is a Hashtabl
On 05/12/2015 01:43 AM, Brent Christian wrote:
Hi, Mandy. Thanks for having a look.
On 5/11/15 12:09 PM, Mandy Chung wrote:
~/WORK/8029891/plevartI'd like Daniel's suggestion to have the load*
method to putAll entries in one go after the input reader/stream/xml
file is loaded and parsed rath
> On May 11, 2015, at 4:43 PM, Brent Christian
> wrote:
>
> Hi, Mandy. Thanks for having a look.
>
> On 5/11/15 12:09 PM, Mandy Chung wrote:
>> ~/WORK/8029891/plevartI'd like Daniel's suggestion to have the load*
>> method to putAll entries in one go after the input reader/stream/xml
>> file
Option A: If the annotation @Documented is present on the declaration of
an annotation type T, then any @T annotation on an element is considered
part of the element's public contract.
Option B: The annotation type Documented is used to indicate that
annotations of a given annotation type (nam
Hi, Mandy. Thanks for having a look.
On 5/11/15 12:09 PM, Mandy Chung wrote:
~/WORK/8029891/plevartI'd like Daniel's suggestion to have the load*
method to putAll entries in one go after the input reader/stream/xml
file is loaded and parsed rather than adding one entry at a time.
I also like
Still a bit convoluted, but the mean time to comprehension is
significant less than that of the original.
-- Jon
On 05/11/2015 04:16 PM, Joseph D. Darcy wrote:
How about as a first sentence
"The Documented meta-annotation indicates whether or not annotations
of the annotation types it annot
How about as a first sentence
"The Documented meta-annotation indicates whether or not annotations of
the annotation types it annotates are considered part of the public
contract of the elements they in turn annotate."
(Admittedly still a bit convoluted.)
-Joe
On 5/11/2015 4:07 PM, Jonatha
Thanks Martin!
Yes, did that.
I also fixed indentation in some places and replaced StringBuffer with
StringBuilder.
Here's the updated webrev:
http://cr.openjdk.java.net/~igerasim/8074657/01/webrev/
Sincerely yours,
Ivan
On 12.05.2015 0:55, Martin Buchholz wrote:
Looks good.
(but I might g
Hello,
Some are of the opinion that the specification for the Documented
meta-annotation type could be clarified.
JDK-8053918: make the spec for @Documented comprehensible
http://cr.openjdk.java.net/~darcy/8053918.0/
Please review the patch below which aims to accomplish this.
Thanks
Looks good.
(but I might go further and coalesce string constants for readability)
On Mon, May 11, 2015 at 2:38 PM, Ivan Gerasimov
wrote:
> Hi all!
>
> grep found a few places, where a space is missing.
>
> Would you please help review this cleanup fix?
>
> BUGURL: https://bugs.openjdk.java.net
Hi all!
grep found a few places, where a space is missing.
Would you please help review this cleanup fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8074657
WEBREV: http://cr.openjdk.java.net/~igerasim/8074657/00/webrev/
Sincerely yours,
Ivan
I have to take over this fix.
The latest webrev from the review thread above (with a few minor
changes) is here:
http://cr.openjdk.java.net/~igerasim/8071571/00/webrev/
Would you please review/approve the fix at your convenience?
Sincerely yours,
Ivan
Hi Alan,
For MAX_RUN_LENGTH, the constant was used to limit the size of a run when the
numbers were equal. We treat equal numbers as part of the same run and do not
require such a limitation.
We have created a consolidated test based upon your feedback and Sunny will
work on getting a new revi
On 05/11/2015 06:52 AM, Daniel Fuchs wrote:
Please find below a fix for:
8079773: java/util/logging/LogManager/TestLoggerNames.java
The issue arises from a race condition in the test logic.
The test calls LogManager.getLoggerNames(), reset, and adds
and remove loggers concurrently - mostly f
Hi Brent,
On 05/04/2015 09:11 AM, Brent Christian wrote:
Hi,
Please review this fix, courtesy of Peter Levart (thanks!), that I
would like to get in.
https://bugs.openjdk.java.net/browse/JDK-8029891
http://cr.openjdk.java.net/~bchristi/8029891/webrev.0/
Thanks for taking this on. I haven'
On May 11, 2015, at 9:49 AM, Andrew Haley wrote:
>> One point is that the regression tests are much more tractable to run.
>
> Well, yeah. I have to confess that I did not run the TCK tests for
> this bug, so you may have a point...
Makes one wonder whether some portion of those tests ought t
On 05/11/2015 05:46 PM, Brian Burkhalter wrote:
>
> On May 11, 2015, at 9:25 AM, Andrew Haley wrote:
>
>>> It would be good to extend the test coverage. In this case it was caught
>>> by JCK so not an OpenJDK test.
>>
>> Well, that's something of a philosophical issue: should we really
>> dupli
On May 11, 2015, at 9:25 AM, Andrew Haley wrote:
>> It would be good to extend the test coverage. In this case it was caught
>> by JCK so not an OpenJDK test.
>
> Well, that's something of a philosophical issue: should we really
> duplicate TCK tests in our regression test suite? Also, I must
On 05/11/2015 04:39 PM, Alan Bateman wrote:
> On 11/05/2015 15:14, Andrew Haley wrote:
>> I mixed up my nextPutIndex and nextGetIndex. Sorry.
>>
>> http://cr.openjdk.java.net/~aph/8079459/
>>
>> This is also the cause of Bug
>> https://bugs.openjdk.java.net/browse/JDK-8079860
>>
> This looks good
On May 11, 2015, at 4:14 PM, Andrew Haley wrote:
> I mixed up my nextPutIndex and nextGetIndex. Sorry.
>
> http://cr.openjdk.java.net/~aph/8079459/
>
> This is also the cause of Bug https://bugs.openjdk.java.net/browse/JDK-8079860
>
Oops, i missed this in review. Looks good.
Paul.
Please review clarifications and updates to the proposed Precess API.
A few loose ends in the ProcessHandle API were identified.
1) The ProcessHandle.parent() method currently returns null if the
parent cannot
be determined and the ProcessHandle.of(PID) method returns null if the
PID does not
On 11/05/2015 15:14, Andrew Haley wrote:
I mixed up my nextPutIndex and nextGetIndex. Sorry.
http://cr.openjdk.java.net/~aph/8079459/
This is also the cause of Bug https://bugs.openjdk.java.net/browse/JDK-8079860
This looks good, easy to miss when looking at a big patch.
It would be good t
I mixed up my nextPutIndex and nextGetIndex. Sorry.
http://cr.openjdk.java.net/~aph/8079459/
This is also the cause of Bug https://bugs.openjdk.java.net/browse/JDK-8079860
Andrew.
Please find below a fix for:
8079773: java/util/logging/LogManager/TestLoggerNames.java
The issue arises from a race condition in the test logic.
The test calls LogManager.getLoggerNames(), reset, and adds
and remove loggers concurrently - mostly for the purpose of
validating that no CME will b
24 matches
Mail list logo
