On 1/26/17 1:04 AM, Paul Sandoz wrote:
@SuppressWarnings({"unchecked", "rawtypes”})
Can we remove those with an appropriate adjustment to the test method
signatures?
Fixed.
We should be careful adding Integer.MAX_VALUE tests for BitStream as the can
consume lots of memory.
My suggestio
On 08/02/2017 00:08, Mark Sheppard wrote:
webrev has been updated as per feedback and suggestions:
http://cr.openjdk.java.net/~msheppar/8049375/test/webrev.02/
http://cr.openjdk.java.net/~msheppar/8049375/corba/webrev.02/
"(if any)" => "(, if any)", did you mean to add the comma? The rest of
t
Hi Mandy,
Thanks for all the suggestions!
On 07/02/17 20:03, Mandy Chung wrote:
Please find below a new webrev that incorporates your feedback.
http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.03/
I think this sentence is not needed.
216 * A {@code StackWalker} with this {@
Looks good!
-- daniel
On 07/02/17 20:06, Roger Riggs wrote:
Please review minor changes to the java.time.tck tests to avoid the use of
implementation details and the related opening of the modules.
The testng directive to open needed modules is now specific to the
java.time.test... tests.
Webr
Hi Team,
Please review small fix for test suite regarding module dependency.
BugID: https://bugs.openjdk.java.net/browse/JDK-8174194
WebRev: http://cr.openjdk.java.net/~skovalev/8174194/webrev.00/
--
With best regards,
Sergei
Hi Sergey,
LFMultiThreadCachingTest.java
Can you clarify the change in this file?
jdk.management requires java.management - so if the test failed with
--limit-modules when it required jdk.management then it's not going to
pass if it is changed to require only java.management.
Or is it that jdk
Hi Daniel,
Thank you for review.
Hi Sergey,
LFMultiThreadCachingTest.java
Can you clarify the change in this file?
jdk.management requires java.management - so if the test failed with
--limit-modules when it required jdk.management then it's not going to
pass if it is changed to require onl
On 08/02/17 14:13, Sergei Kovalev wrote:
Actually jdk.management is not required for this particular test.
java.management module is enough to pass the test.
Well, looks good to me then!
best regards,
-- daniel
> On Feb 8, 2017, at 3:36 AM, Daniel Fuchs wrote:
>
> Hi Mandy,
>
> Thanks for all the suggestions!
>
> On 07/02/17 20:03, Mandy Chung wrote:
>>> Please find below a new webrev that incorporates your feedback.
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.03/
>>>
>>
>> I think
> On Feb 8, 2017, at 6:13 AM, Sergei Kovalev wrote:
>
> Thank you for review.
>
>> On 08/02/17 13:51, Sergei Kovalev wrote:
>> WebRev: http://cr.openjdk.java.net/~skovalev/8174194/webrev.00/
>>
CheckPackageAccess.java
86 System.out.println(String.format(MODULE_TEXT, moduleName,
On 08/02/17 15:58, Mandy Chung wrote:
I disagree: the text starts by saying:
"By default reflection frames are hidden. The reflection
frames include […]"
209 * Shows all reflection frames.
This is the first sentence. line 216-217 repeats line 209.
but the sentence at lines 216-217 i
> On Feb 8, 2017, at 8:17 AM, Daniel Fuchs wrote:
>
>
> I have made this change in my workspace:
> http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.05/
>
>/**
> * Shows all reflection frames.
> *
> * By default, reflection frames are hidden. A {@code St
> On 8 Feb 2017, at 01:57, Amy Lu wrote:
>
> On 1/26/17 1:04 AM, Paul Sandoz wrote:
>> @SuppressWarnings({"unchecked", "rawtypes”})
>>
>> Can we remove those with an appropriate adjustment to the test method
>> signatures?
>>
>
> Fixed.
SpliteratorCollisions
—
232 testForEach(ex
Hi,
Based on some (offline) feedback and further testing, I've updated the
langtools patch. The new webrev is here:
http://cr.openjdk.java.net/~jlahoda/8173777/langtools.02/
Delta webrev compared to .01:
http://cr.openjdk.java.net/~jlahoda/8173777/langtools.02/delta/webrev/index.html
The chan
JShell changes to the memory file manager are unchanged in this update
and so still look good.
-Robert
On 02/08/17 12:46, Jan Lahoda wrote:
Hi,
Based on some (offline) feedback and further testing, I've updated the
langtools patch. The new webrev is here:
http://cr.openjdk.java.net/~jlahod
On 2/9/17 1:50 AM, Paul Sandoz wrote:
SpliteratorCollisions
—
232 testForEach(exp, s, (Consumer b) -> b);
Do you require the type declaration for the lambda function parameter?
It might be possible to use UnaryOperator.identity() in those cases.
Right :-)
Fixed in http://cr.openj
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8173957
webrev: http://cr.openjdk.java.net/~mli/8173957/webrev.00/
Thank you
-Hamlin
17 matches
Mail list logo
