Re: RFR: 8284780: Need methods to create pre-sized HashSet and LinkedHashSet [v17]

[Brian Burkhalter]

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess  wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   do it as naotoj said

`java.io` and `java.nio` look all right.

-

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8302

Re: RFR: 8286378: Address possibly lossy conversions in java.base [v3]

[Brian Burkhalter]

On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs  wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy 
>> conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not 
>> assignment compatible with the type of the variable, a cast is implied and 
>> possible lossy conversion may silently occur. While similar situations are 
>> resolved as compilation errors for primitive assignments, there are no 
>> similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the 
>> implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of 
>> the compound assignment.
>> Since these casts are truncating the value, there might be a different 
>> refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK 
>> modules).
>
> Roger Riggs has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Updated copyrights
>   Fixed cast style to add a space after cast, (where consistent with file 
> style)
>   Improved code per review comments in PollSelectors.

Marked as reviewed by bpb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8642

Re: RFR: 8286378: Address possibly lossy conversions in java.base

[Brian Burkhalter]

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs  wrote:

> PR#8599 8244681: proposes to add compiler warnings for possible lossy 
> conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not 
> assignment compatible with the type of the variable, a cast is implied and 
> possible lossy conversion may silently occur. While similar situations are 
> resolved as compilation errors for primitive assignments, there are no 
> similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the 
> implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of 
> the compound assignment.
> Since these casts are truncating the value, there might be a different 
> refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

IO, math, and NIO changes look fine.

-

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8642

Re: RFR: 8284853: Fix varios 'expected' typo

[Brian Burkhalter]

On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov  wrote:

> Found various typos of expected: `exepected`, `exept`, `epectedly`, 
> `expeced`, `Unexpeted`, etc.

Expect the Unexpeted.

-

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8231

Re: RFR: 8283800: Simplify String.indexOf/lastIndexOf calls

[Brian Burkhalter]

On Sun, 20 Mar 2022 12:45:34 GMT, Andrey Turbanov  wrote:

> In a few places String.indexOf/lastIndexOf methods are called with default 
> parameter for index: `0` for `indexOf`, length() for `lastIndexOf`.
> I propose to cleanup such calls. It makes code a bit easier to read. In case 
> of `indexOf` it even could be faster, as there is separate intrinsic for 
> `indexOf` call without index argument.

Marked as reviewed by bpb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7877

Re: RFR: 8274835: Remove unnecessary castings in java.base

[Brian Burkhalter]

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov 
 wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't 
> touch primitive types casts.

`java.io` change looks all right.

-

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5454

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v4]

[Brian Burkhalter]

On Wed, 22 Sep 2021 15:38:33 GMT, Pavel Rappo  wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Add missing "the"
>   
>   (Spotted by Brian Burkhalter.)

Marked as reviewed by bpb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5610

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[Brian Burkhalter]

On Tue, 21 Sep 2021 17:39:41 GMT, Pavel Rappo  wrote:

>> Would "wrappER" be better?
>
> We can either revert this part of the change or rephrase it. Mind you, 
> rephrasing might prove tricky because of non-local changes it might 
> introduce. There's one more occurrence of "wrapped exception" in this file: 
> https://github.com/openjdk/jdk/blob/19b6f49649a317e6b255aeb810c8d533119b93bb/src/java.base/share/classes/java/lang/Throwable.java#L548-L554

Instead of "common case where a wrapped exception is thrown from same method" 
could one write "common case where an enclosing exception is thrown from the 
same method"?

-

PR: https://git.openjdk.java.net/jdk/pull/5610

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[Brian Burkhalter]

On Tue, 21 Sep 2021 17:07:45 GMT, Pavel Rappo  wrote:

>> It does seem a bit strange to say "Throwing a wrapping"
>
> If we have two exceptions A and B, such that B is the cause of A, then A is 
> the wrapping exception (the one that wraps or the wrapper) and B is the 
> wrapped exception (the one that is being wrapped or the wrappee).
> 
> I noticed that the sentence was conflicting: it started with the "wrapped" 
> exception, but then in the "i.e." commentary in parentheses proceeded with 
> the wrappee exception. To resolve that conflict, I proposed to rephrase the 
> first part of that sentence. FWIW, my original suggestion elsewhere was to 
> use "wrapper".

Subjectively, "wrapping exception" would seem to be an exception in the process 
of wrapping something.

-

PR: https://git.openjdk.java.net/jdk/pull/5610

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[Brian Burkhalter]

On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo  wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Tweak wording for Throwable constructor parameters

src/java.base/share/classes/java/lang/Throwable.java line 68:

> 66:  * Further, doing so would tie the API of the upper layer to the details 
> of
> 67:  * its implementation, assuming the lower layer's exception was a checked
> 68:  * exception.  Throwing a "wrapping exception" (i.e., an exception 
> containing a

Are we sure that this should be "wrapping" and not "wrapped?" See also for 
example `java.security.cert.CertPathValidatorException.`

-

PR: https://git.openjdk.java.net/jdk/pull/5610

Re: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when converting stream to String

[Brian Burkhalter]

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov 
 wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is 
> cleaner than `new String(out.toByteArray())`. Also it's a bit faster because 
> of one less array copy.

Marked as reviewed by bpb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5355

Re: [jdk17] RFR: 8266345: (fs) Custom DefaultFileSystemProvider security related loops

[Brian Burkhalter]

On Thu, 8 Jul 2021 18:21:31 GMT, Sean Mullan  wrote:

> Please review this fix to use the platform's default file system to avoid 
> recursive policy initialization
> issues when a SecurityManager is enabled and the VM is configured to use a 
> custom file system provider.

Looks good.

-

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/232

Re: RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable

[Brian Burkhalter]

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon  
wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, 
> `java.math`, and `java.text` packages to make use of the `instanceof` pattern 
> variable?
> 
> Kind regards,
> Patrick

Looks good and builds cleanly: approved.

-

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2879

Re: RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0

[Brian Burkhalter]

On Fri, 12 Feb 2021 08:50:14 GMT, Matthias Baesken  wrote:

> There seems to be an early return in 
> Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 that misses freeing memory.
> 
> Sonar reports :
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8Cl0BBG2CXpcnjFu&resolved=false&severities=BLOCKER&types=BUG
> 
> Potential leak of memory pointed to by 'newBuf'
> I adjusted  the early return and added freeing memory .
> 
> 
> Btw. while  adjusting  Java_sun_nio_ch_sctp_SctpChannelImpl_receive0  , I 
> started  to wonder what happens to the allocated memory in  the same file in 
> handleSendFailed  (  if ((addressP = malloc(dataLength)) == NULL)   )   in 
> early return cases  incl. the CHECK_NULL , is there some deallocation missing 
> there too ?

This change looks fine. I don't know about handleSendFailed().

-

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2540

Re: RFR: 8250564: Remove terminally deprecated constructor in GSSUtil

[Brian Burkhalter]

On Tue, 5 Jan 2021 21:02:21 GMT, Joe Darcy  wrote:

> Back in JDK 16, two unintended default constructors were identified and 
> deprecated for removal. The time has come to remove them.
> 
> Please also review the corresponding CSRs:
> 
> JDK-8258521 Remove terminally deprecated constructor in GSSUtil 
> https://bugs.openjdk.java.net/browse/JDK-8258521
> 
>  JDK-8258522 Remove terminally deprecated constructor in java.net.URLDecoder 
> https://bugs.openjdk.java.net/browse/JDK-8258522
> 
> Calling a static method using an instance of a class, as done in the test 
> B6463990.java, is a coding anti-pattern that generates a lint warning; that 
> warning in enabled in the JDK build.
> 
> Thanks,

Looks good. CSRs also reviewed.

-

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1948

Re: RFR 8211360 : Change #if DEF to #if defined(DEF)

[Brian Burkhalter]

Hello Ivan,

Looks fine.

Brian

> On Aug 20, 2019, at 10:38 AM, Ivan Gerasimov  
> wrote:
> 
> It's a followup for JDK-8211146.
> 
> With that fix several C-preprocessor statements of form #elif __linux__ were 
> changed to more accurate #elif defined(__linux__).
> 
> grep found a few more occurrences of the same pattern, which also would 
> better be cleaned up.
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8211360 
> 
> WEBREV: http://cr.openjdk.java.net/~igerasim/8211360/00/webrev/ 
> 
> 
> Mach5 control build/testing went fine on all platforms.
> Would you please help review?

Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces

[Brian Burkhalter]

Hi Joe,

Looks fine.

Brian

On Aug 6, 2018, at 12:11 PM, joe darcy  wrote:

> Various interfaces in the JDK extend Serializable and declare 
> serialVersionUID fields. Such fields are ineffectual and 
> @SuppressWarnings("serial") should be applied to such fields to suppress 
> future planned serial lint checks (JDK-8202056).
> 
> Most of the affected files are in the security-libs area with a handful in 
> RMI and JNDI:
> 
> http://cr.openjdk.java.net/~darcy/8209024.0/
> 
> Patch below. I'll fix-up the copyright years before any push.

Re: RFR for 6443578 and 6202130: UTF-8 in Manifests

[Brian Burkhalter]

For more specifics about allowed attachment types see [1].

Brian

[1] http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-March/000378.html

On May 4, 2018, at 12:51 PM, Roger Riggs  wrote:

> Just a reminder that OpenJDK can *only* accept patches via cr.openjdk.java.net
> (as an author) or inline or attached in email.

Re: RFR: 8184208: update class="striped" tables for accessibility

[Brian Burkhalter]

On Jul 11, 2017, at 2:39 PM, Jonathan Gibbons  
wrote:

> Please review this auto-generated update to improve the accessibility of many 
> of the tables
> in the API docs for the java.base module.

Looks all right to me.

> All the modifiied tables have been visually checked with an accessibility 
> checker.

There does not however appear to be a visual difference between the JDK 9 
javadoc and the javadoc generated in a JDK 10 clone with this patch applied.

Brian

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

[Brian Burkhalter]

Not really. Will continue with it. I’m not sure whether Alan is done with it 
either.

Brian

On Sep 12, 2016, at 8:34 PM, Weijun Wang  wrote:

> Have you finished the deeper pass? :-)
> 
> Thanks
> Max
> 
> On 9/2/2016 8:18, Brian Burkhalter wrote:
>> At the API level and conceptually this all appears reasonable. I am
>> going to need to take a deeper pass over it all however to comprehend
>> the implementation at any kind of detailed level. The changes mentioned
>> in response to Alan’s comments all appear good.
>> 
>> Thanks,
>> 
>> Brian
>> 
>> On Sep 1, 2016, at 7:25 AM, Weijun Wang > <mailto:weijun.w...@oracle.com>> wrote:
>> 
>>> Webrev updated at
>>> 
>>>  http://cr.openjdk.java.net/~weijun/8164705/webrev.01
>>> 
>>> Most suggestions from Alan accepted, including:
>>> 
>>> 1. Using SharedSecrets.getJavaIOFilePermissionAccess() style instead
>>> of public functions.
>>> 
>>> 2. jdk.io.permissionsUseCanonicalPath=.
>>> 
>>> 3. samepath.sh rewritten in ReadFileOnPath.java.
>>> 
>>> Still using "ugly" method names. Thinking they are clear enough.
>> 

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

[Brian Burkhalter]

Only picky comments: not sure but maybe change:

1) vice versa -> and vice versa
2) When it’s set to true -> When true
3) just like before -> as before

Brian

On Sep 12, 2016, at 12:23 AM, Weijun Wang  wrote:

> BTW, please also review the release note at
> 
>   https://bugs.openjdk.java.net/browse/JDK-8165836
> 
> Thanks
> Max

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

[Brian Burkhalter]

At the API level and conceptually this all appears reasonable. I am going to 
need to take a deeper pass over it all however to comprehend the implementation 
at any kind of detailed level. The changes mentioned in response to Alan’s 
comments all appear good.

Thanks,

Brian

On Sep 1, 2016, at 7:25 AM, Weijun Wang  wrote:

> Webrev updated at
> 
>   http://cr.openjdk.java.net/~weijun/8164705/webrev.01
> 
> Most suggestions from Alan accepted, including:
> 
> 1. Using SharedSecrets.getJavaIOFilePermissionAccess() style instead of 
> public functions.
> 
> 2. jdk.io.permissionsUseCanonicalPath=.
> 
> 3. samepath.sh rewritten in ReadFileOnPath.java.
> 
> Still using "ugly" method names. Thinking they are clear enough.

hg: jdk8/tl/jdk: 2 new changesets

[brian . burkhalter]

Changeset: d3c4e8fe98c3
Author:bpb
Date:  2013-12-05 07:44 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3c4e8fe98c3

8029514: java/math/BigInteger/BigIntegerTest.java failing since thresholds 
adjusted in 8022181
Summary: Ensure the value returned by getLower() is unsigned.
Reviewed-by: darcy

! src/share/classes/java/math/BigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java

Changeset: 303f4bccfca2
Author:bpb
Date:  2013-12-05 07:45 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/303f4bccfca2

8029501: BigInteger division algorithm selection heuristic is incorrect
Summary: Change Burnikel-Ziegler division heuristic to require that the 
dividend int-length exceed that of the divisor by a minimum amount.
Reviewed-by: darcy

! src/share/classes/java/math/BigInteger.java
! src/share/classes/java/math/MutableBigInteger.java

hg: jdk8/tl/jdk: 8022181: Tune algorithm crossover thresholds in BigInteger

[brian . burkhalter]

Changeset: c138b0d33980
Author:bpb
Date:  2013-12-03 12:25 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c138b0d33980

8022181: Tune algorithm crossover thresholds in BigInteger
Summary: Change multiplication, squaring, division, and base conversion 
thresholds to values which retain performance improvement in most cases but 
with a a lower overall risk of regression.
Reviewed-by: darcy

! src/share/classes/java/math/BigInteger.java

hg: jdk8/tl/jdk: 8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to specify heap size

[brian . burkhalter]

Changeset: 92fb6baaebc4
Author:bpb
Date:  2013-11-04 08:05 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92fb6baaebc4

8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to 
specify heap size
Summary: Add @run tag to specify heap size
Reviewed-by: alanb, dxu

! test/java/math/BigInteger/ExtremeShiftingTests.java

hg: jdk8/tl/jdk: 6910473: java.math.BigInteger.bitLength() may return negative "int" on large numbers; ...

[brian . burkhalter]

Changeset: 0734e1584d9d
Author:bpb
Date:  2013-10-30 17:45 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0734e1584d9d

6910473: java.math.BigInteger.bitLength() may return negative "int" on large 
numbers
8021203: BigInteger.doubleValue/floatValue returns 0.0 instead of Infinity
8021204: Constructor BigInteger(String val, int radix) doesn't detect overflow
8022780: Incorrect BigInteger division because of MutableBigInteger.bitLength() 
overflow
Summary: Prevent construction of overflowed BigIntegers.
Reviewed-by: bpb, darcy, psandoz
Contributed-by: Dmitry Nadezhin 

! src/share/classes/java/math/BigInteger.java
! src/share/classes/java/math/MutableBigInteger.java
+ test/java/math/BigInteger/BitLengthOverflow.java
+ test/java/math/BigInteger/DivisionOverflow.java
+ test/java/math/BigInteger/DoubleValueOverflow.java
! test/java/math/BigInteger/ExtremeShiftingTests.java
+ test/java/math/BigInteger/StringConstructorOverflow.java
+ test/java/math/BigInteger/SymmetricRangeTests.java

hg: jdk8/tl/jdk: 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE; ...

[brian . burkhalter]

Changeset: 2be08cdd1ced
Author:bpb
Date:  2013-10-22 11:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2be08cdd1ced

7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with 
NPE
6445180: URLClassLoader does not describe the behavior of several methods with 
respect to null arguments
Summary: Document when a NPE will be thrown by URLClassLoader constructors, 
newInstance(), findClass(), and getPermissions().
Reviewed-by: alanb, mduigou, chegar, dholmes, jrose

! src/share/classes/java/net/URLClassLoader.java
! src/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java
! src/share/classes/sun/applet/AppletClassLoader.java
+ test/java/net/URLClassLoader/NullURLTest.java

hg: jdk8/tl/jdk: 8026806: Incomplete test of getaddrinfo() return value could lead to incorrect exception for Windows Inet 6

[brian . burkhalter]

Changeset: 9758edb6976f
Author:bpb
Date:  2013-10-22 10:44 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9758edb6976f

8026806: Incomplete test of getaddrinfo() return value could lead to incorrect 
exception for Windows Inet 6
Summary: Check getaddrinfo return value before calling WSAGetLastError.
Reviewed-by: alanb, dsamersoff

! src/windows/native/java/net/Inet6AddressImpl.c

hg: jdk8/tl/jdk: 8026832: Clean up straggling doclint warnings in java.math

[brian . burkhalter]

Changeset: e76bb2436b04
Author:bpb
Date:  2013-10-17 15:05 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e76bb2436b04

8026832: Clean up straggling doclint warnings in java.math
Summary: Fix empty paragraph tag warnings.
Reviewed-by: lancea

! src/share/classes/java/math/BigDecimal.java
! src/share/classes/java/math/RoundingMode.java

hg: jdk8/tl/jdk: 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

[brian . burkhalter]

Changeset: 3676f04e6553
Author:bpb
Date:  2013-10-15 16:45 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3676f04e6553

8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes 
UnknownHostException to be thrown
Summary: Modify UHE exception message for EAI_AGAIN failures.
Reviewed-by: alanb, chegar, michaelm, dsamersoff
Contributed-by: Brian Burkhalter 

! src/solaris/native/java/net/Inet4AddressImpl.c
! src/windows/native/java/net/Inet4AddressImpl.c
! src/windows/native/java/net/Inet6AddressImpl.c

hg: jdk8/tl/jdk: 7189139: BigInteger's staticRandom field can be a source of bottlenecks.

[brian . burkhalter]

Changeset: 673f8045311e
Author:bpb
Date:  2013-10-09 17:22 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/673f8045311e

7189139: BigInteger's staticRandom field can be a source of bottlenecks.
Summary: Use ThreadLocalRandom instead of SecureRandom.
Reviewed-by: shade, psandoz
Contributed-by: Brian Burkhalter 

! src/share/classes/java/math/BigInteger.java

hg: jdk8/tl/jdk: 8016252: More defensive HashSet.readObject

[brian . burkhalter]

Changeset: b86e6700266e
Author:bpb
Date:  2013-10-09 11:47 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b86e6700266e

8016252: More defensive HashSet.readObject
Summary: Add data validation checks in readObject().
Reviewed-by: alanb, mduigou, chegar
Contributed-by: Brian Burkhalter 

! src/share/classes/java/util/HashSet.java
+ test/java/util/HashSet/Serialization.java

hg: jdk8/tl/jdk: 8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't throw NPE if the remappingFunction is null and the key is absent

[brian . burkhalter]

Changeset: 2552cd270350
Author:bpb
Date:  2013-09-20 15:12 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2552cd270350

8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't 
throw NPE if the remappingFunction is null and the key is absent
Summary: Explicitly check for null remappingFunction parameter.
Reviewed-by: mduigou, forax, psandoz
Contributed-by: Brian Burkhalter 

! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/Map.java
! test/java/util/Map/Defaults.java

hg: jdk8/tl/jdk: 8010430: Math.round has surprising behavior for odd values of ulp 1

[brian . burkhalter]

Changeset: 917fffe971c8
Author:bpb
Date:  2013-09-11 17:07 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/917fffe971c8

8010430: Math.round has surprising behavior for odd values of ulp 1
Summary: If the effective floating point exponent is zero return the 
significand including the implicit 1-bit.
Reviewed-by: bpb, darcy, gls
Contributed-by: Dmitry Nadezhin 

! src/share/classes/java/lang/Math.java
! src/share/classes/java/lang/StrictMath.java
! test/java/lang/Math/RoundTests.java