Re: RFR: JDK-8250611: Cannot display splash screen on Windows

[Phil Race]

Only back to 11 and client support ended before that.

-Phil.

> On Aug 13, 2020, at 7:58 PM, Alexey Semenyuk  
> wrote:
> 
> Phil,
> 
> jpackage can be used to bundle apps with older JREs. Do you think it doesn't 
> make sense for this check given this?
> 
> - Alexey
> 
>> On 8/13/2020 6:03 PM, Philip Race wrote:
>> Do I understand correctly that you are checking if the client VM is being 
>> specified ?
>> I didn't think we had client VMs any more ..
>> 
>> -phil.
>> 
>>> On 8/13/20, 12:35 PM, Andy Herrick wrote:
>>> Please review this jpackage fix for issue [1] at [2].
>>> 
>>> In order to show splash screen from statically linked applauncher, we need 
>>> to load the dependent libraries of splashscreen.dll first (java.dll and 
>>> jvm.dll).
>>> 
>>> /Andy
>>> 
>>> [1] - https://bugs.openjdk.java.net/browse/JDK-8250611
>>> 
>>> [2] - http://cr.openjdk.java.net/~herrick/8250611/webrev.01/
>>> 
> 

Re: RFR: JDK-8250611: Cannot display splash screen on Windows

[Alexey Semenyuk]

Phil,

jpackage can be used to bundle apps with older JREs. Do you think it 
doesn't make sense for this check given this?


- Alexey

On 8/13/2020 6:03 PM, Philip Race wrote:
Do I understand correctly that you are checking if the client VM is 
being specified ?

I didn't think we had client VMs any more ..

-phil.

On 8/13/20, 12:35 PM, Andy Herrick wrote:

Please review this jpackage fix for issue [1] at [2].

In order to show splash screen from statically linked applauncher, we 
need to load the dependent libraries of splashscreen.dll first 
(java.dll and jvm.dll).


/Andy

[1] - https://bugs.openjdk.java.net/browse/JDK-8250611

[2] - http://cr.openjdk.java.net/~herrick/8250611/webrev.01/

Re: RFR: 8250803: pkgbuild failed with exit code 134

[alexander . matveev]

Hi Joe,

None. Most time is spend when pkgbuild is executed which is external 
tool. Based on log our code does not consume a lot of time during 
execution. Based on one of the runs total time was 11 min: 1 min for 
jlink, 4 min for hdutil create and 4 min for pkgbuild, so test itself 
took 2 min.


Thanks,
Alexander

On 8/13/20 1:21 PM, Joe Darcy wrote:
What steps were taken to make the test run faster instead of 
increasing the time out?


cheers,

-Joe

On 8/13/2020 1:13 PM, alexander.matv...@oracle.com wrote:

Please review the jpackage fix for bug [1] at [2].

- Looks like issue was just in not enough time for test to execute. 
Increasing timeout by 1 min fixed issues. In fix it is increased by 
50% just in case. Without timeout increase it was reproducible 100% 
on one of test machine. With increased timeout I cannot reproduce it 
after multiple runs.


[1] https://bugs.openjdk.java.net/browse/JDK-8250803
[2] http://cr.openjdk.java.net/~almatvee/8250803/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8250611: Cannot display splash screen on Windows

[alexander . matveev]

Hi Andy,

Looks good.

Thanks,
Alexander

On 8/13/20 12:35 PM, Andy Herrick wrote:

Please review this jpackage fix for issue [1] at [2].

In order to show splash screen from statically linked applauncher, we 
need to load the dependent libraries of splashscreen.dll first 
(java.dll and jvm.dll).


/Andy

[1] - https://bugs.openjdk.java.net/browse/JDK-8250611

[2] - http://cr.openjdk.java.net/~herrick/8250611/webrev.01/

Re: RFR: JDK-8250611: Cannot display splash screen on Windows

[Philip Race]

Do I understand correctly that you are checking if the client VM is 
being specified ?

I didn't think we had client VMs any more ..

-phil.

On 8/13/20, 12:35 PM, Andy Herrick wrote:

Please review this jpackage fix for issue [1] at [2].

In order to show splash screen from statically linked applauncher, we 
need to load the dependent libraries of splashscreen.dll first 
(java.dll and jvm.dll).


/Andy

[1] - https://bugs.openjdk.java.net/browse/JDK-8250611

[2] - http://cr.openjdk.java.net/~herrick/8250611/webrev.01/

Re: RFR: 8250803: pkgbuild failed with exit code 134

[Alexey Semenyuk]

Looks good.

- Alexey

On 8/13/2020 4:13 PM, alexander.matv...@oracle.com wrote:

Please review the jpackage fix for bug [1] at [2].

- Looks like issue was just in not enough time for test to execute. 
Increasing timeout by 1 min fixed issues. In fix it is increased by 
50% just in case. Without timeout increase it was reproducible 100% on 
one of test machine. With increased timeout I cannot reproduce it 
after multiple runs.


[1] https://bugs.openjdk.java.net/browse/JDK-8250803
[2] http://cr.openjdk.java.net/~almatvee/8250803/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8250611: Cannot display splash screen on Windows

[Alexey Semenyuk]

Looks good.

- Alexey

On 8/13/2020 3:35 PM, Andy Herrick wrote:

Please review this jpackage fix for issue [1] at [2].

In order to show splash screen from statically linked applauncher, we 
need to load the dependent libraries of splashscreen.dll first 
(java.dll and jvm.dll).


/Andy

[1] - https://bugs.openjdk.java.net/browse/JDK-8250611

[2] - http://cr.openjdk.java.net/~herrick/8250611/webrev.01/

Re: RFR: 8250803: pkgbuild failed with exit code 134

[Joe Darcy]

What steps were taken to make the test run faster instead of increasing 
the time out?


cheers,

-Joe

On 8/13/2020 1:13 PM, alexander.matv...@oracle.com wrote:

Please review the jpackage fix for bug [1] at [2].

- Looks like issue was just in not enough time for test to execute. 
Increasing timeout by 1 min fixed issues. In fix it is increased by 
50% just in case. Without timeout increase it was reproducible 100% on 
one of test machine. With increased timeout I cannot reproduce it 
after multiple runs.


[1] https://bugs.openjdk.java.net/browse/JDK-8250803
[2] http://cr.openjdk.java.net/~almatvee/8250803/webrev.00/

Thanks,
Alexander

RFR: 8250803: pkgbuild failed with exit code 134

[alexander . matveev]

Please review the jpackage fix for bug [1] at [2].

- Looks like issue was just in not enough time for test to execute. 
Increasing timeout by 1 min fixed issues. In fix it is increased by 50% 
just in case. Without timeout increase it was reproducible 100% on one 
of test machine. With increased timeout I cannot reproduce it after 
multiple runs.


[1] https://bugs.openjdk.java.net/browse/JDK-8250803
[2] http://cr.openjdk.java.net/~almatvee/8250803/webrev.00/

Thanks,
Alexander

Re: 8251160: Fix "no comment" warnings in java.logging

[Mandy Chung]

On 8/13/20 5:00 AM, Daniel Fuchs wrote:

Hi,

Please find below a doc-only fix for:

8251160: Fix "no comment" warnings in java.logging
https://bugs.openjdk.java.net/browse/JDK-8251160

CSR: https://bugs.openjdk.java.net/browse/JDK-8251534

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8251160/webrev.00/



Level

The javadoc for readResolve seems internal implementation details. Would 
it be sufficient to say:


“Returns a {@code Level} instance with the same {@code name},
 {@code value}, and {@code resourceBundleName} as the deserialized
 object"

LogRecord

+ * See {@code writeObject} for a description of the serial form.


This can use @see instead.

Mandy

RFR: JDK-8250611: Cannot display splash screen on Windows

[Andy Herrick]

Please review this jpackage fix for issue [1] at [2].

In order to show splash screen from statically linked applauncher, we 
need to load the dependent libraries of splashscreen.dll first (java.dll 
and jvm.dll).


/Andy

[1] - https://bugs.openjdk.java.net/browse/JDK-8250611

[2] - http://cr.openjdk.java.net/~herrick/8250611/webrev.01/

Re: [Ping] Re: 8181919: Refactor test/java/io/File/GetXSpace.sh to java test

[Brian Burkhalter]

Thanks, Naoto, will do. I am always unclear as to whether to add a bug id to a 
test when the issue is labelled “noreg-self.”

Brian

> On Aug 13, 2020, at 10:52 AM, naoto.s...@oracle.com wrote:
> 
> Looks good, Brian. I'd add the bug id in GetXSpace.java's @bug tag.
> 
> Naoto
> 
> On 8/13/20 8:40 AM, Brian Burkhalter wrote:
>> Thanks!
>>> On Aug 11, 2020, at 11:32 AM, Brian Burkhalter >> > wrote:
>>> 
>>> A revised version [A] is available pursuant to the changes made in the 
>>> course of the review [B] of the fix for [C].

Optimize sun.invoke.util.BytecodeDescriptor.unparse

[Christoph Dreis]

Hi,

I just stumbled upon sun.invoke.util.BytecodeDescriptor.unparse that seems to 
unnecessarily create a StringBuilder and checks for the given type to be of 
Object.class twice in certain scenarios.

When I apply the attached patch below with the following isolated benchmark:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Thread)
public class MyBenchmark {

@State(Scope.Thread)
public static class BenchmarkState {
private Class test = String.class; // long.class;
}

@Benchmark
public String unparseNew(BenchmarkState state) {
return BytecodeDescriptor.unparseNew(state.test);
}

@Benchmark
public String unparseOld(BenchmarkState state) {
return BytecodeDescriptor.unparseOld(state.test);
}
}

I get the following results:
String.class
  
Benchmark   Mode  Cnt Score Error   
Units 
MyBenchmark.unparseNew  avgt   1047,207 ±   1,918   
ns/op 
MyBenchmark.unparseNew:·gc.alloc.rate.norm  avgt   10   232,011 ±   0,002
B/op 
MyBenchmark.unparseOld  avgt   1087,197 ±  22,843   
ns/op 
MyBenchmark.unparseOld:·gc.alloc.rate.norm  avgt   10   384,020 ±   0,001
B/op 

  
long.class  
  
Benchmark   Mode  Cnt Score Error   
Units 
MyBenchmark.unparseNew  avgt   10 4,996 ±0,022   
ns/op
MyBenchmark.unparseNew:·gc.alloc.rate.norm  avgt   10≈ 10⁻⁶   
B/op
MyBenchmark.unparseOld  avgt   1013,303 ±6,305   
ns/op
MyBenchmark.unparseOld:·gc.alloc.rate.norm  avgt   1080,003 ±0,001
B/op

As you can see the new way makes things allocation free for primitives and also 
improves normal classes.

It seems like a relatively trivial improvement. In case you think this is 
worthwhile, I would appreciate it if someone could sponsor the change.

Cheers,
Christoph

=== PATCH ===
--- a/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java   
Thu Aug 13 09:33:28 2020 -0700
+++ b/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java   
Thu Aug 13 19:27:26 2020 +0200
@@ -110,9 +110,13 @@
 } else if (type == int.class) {
 return "I";
 }
-StringBuilder sb = new StringBuilder();
-unparseSig(type, sb);
-return sb.toString();
+Wrapper basicType = Wrapper.forBasicType(type);
+char c = basicType.basicTypeChar();
+if (c != 'L') {
+return basicType.basicTypeString();
+} else {
+return type.descriptorString();
+}
 }

Re: [Ping] Re: 8181919: Refactor test/java/io/File/GetXSpace.sh to java test

[naoto . sato]

Looks good, Brian. I'd add the bug id in GetXSpace.java's @bug tag.

Naoto

On 8/13/20 8:40 AM, Brian Burkhalter wrote:

Thanks!


On Aug 11, 2020, at 11:32 AM, Brian Burkhalter  
wrote:

A revised version [A] is available pursuant to the changes made in the course 
of the review [B] of the fix for [C].

Thanks,

Brian

[A] http://cr.openjdk.java.net/~bpb/8181919/webrev.01/ 

[B] http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068094.html 

[C] https://bugs.openjdk.java.net/browse/JDK-8249703 



On Aug 5, 2020, at 11:36 AM, Brian Burkhalter mailto:brian.burkhal...@oracle.com>> wrote:

To fix [1], please consider the patch [2]. This follows on from the proposed 
change [3] which in turn follows from [4].

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8181919 

[2] http://cr.openjdk.java.net/~bpb/8181919/webrev.00/ 

[3] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068025.html 
 
(GetXSpace should not run on AIX)
[4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/067990.html 
 
(GetXSpace fails on macOS)

Re: Fix for Javadoc errors in java.base

[Sean Mullan]

On 8/13/20 1:21 PM, Jonathan Gibbons wrote:
--- 
old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java 


2020-07-25 23:46:21.233726447 +0530
+++ 
new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java 


2020-07-25 23:46:20.721720857 +0530
@@ -96,8 +96,6 @@
   * @param p the prime modulus
   * @param g the base generator
   * @param l the private-value length
- *
- * @exception InvalidKeyException if the key cannot be encoded


This should actually remain, but it should be ProviderException which 
is a RuntimeException. See the other DHPrivateKey ctor as that 
specifies it correctly.


--Sean



I note the use of `@exception`, as compared to `@throws`, which is more 
common.


Stats:
`@exception` 7322 occurrences
`@throws` 21173 occurrences

That's probably too many `@exception` to clean up. :-(


Right, that's probably a separate cleanup activity. However, if you want 
to change the 3 instances of @exception to @throws in DHPrivateKey, I'm 
fine with that.


--Sean

Re: Fix for Javadoc errors in java.base

[Jonathan Gibbons]

On 8/13/20 10:13 AM, Sean Mullan wrote:

On 8/13/20 11:05 AM, Julia Boes wrote:

Hi Vipin,

Thanks for providing this fix, I'm happy to sponsor your change. To 
complete the review, we still need someone to green light the 
remaining changes below. I'm looping in net-dev and security-dev to 
have a look.


Bug: https://bugs.openjdk.java.net/browse/JDK-8251542

Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8251542/webrev/

Once the review is completed, please provide me with a patch that 
includes a changeset comment as described here: 
https://openjdk.java.net/guide/producingChangeset.html


If you have any questions, let me know.

Cheers,

Julia

--- 
old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java

2020-07-25 23:46:21.233726447 +0530
+++ 
new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java

2020-07-25 23:46:20.721720857 +0530
@@ -96,8 +96,6 @@
   * @param p the prime modulus
   * @param g the base generator
   * @param l the private-value length
- *
- * @exception InvalidKeyException if the key cannot be encoded


This should actually remain, but it should be ProviderException which 
is a RuntimeException. See the other DHPrivateKey ctor as that 
specifies it correctly.


--Sean



I note the use of `@exception`, as compared to `@throws`, which is more 
common.


Stats:
`@exception` 7322 occurrences
`@throws` 21173 occurrences

That's probably too many `@exception` to clean up. :-(

-- Jon

Re: Fix for Javadoc errors in java.base

[Sean Mullan]

On 8/13/20 11:05 AM, Julia Boes wrote:

Hi Vipin,

Thanks for providing this fix, I'm happy to sponsor your change. To 
complete the review, we still need someone to green light the remaining 
changes below. I'm looping in net-dev and security-dev to have a look.


Bug: https://bugs.openjdk.java.net/browse/JDK-8251542

Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8251542/webrev/

Once the review is completed, please provide me with a patch that 
includes a changeset comment as described here: 
https://openjdk.java.net/guide/producingChangeset.html


If you have any questions, let me know.

Cheers,

Julia

--- 
old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java

2020-07-25 23:46:21.233726447 +0530
+++ 
new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java

2020-07-25 23:46:20.721720857 +0530
@@ -96,8 +96,6 @@
   * @param p the prime modulus
   * @param g the base generator
   * @param l the private-value length
- *
- * @exception InvalidKeyException if the key cannot be encoded


This should actually remain, but it should be ProviderException which is 
a RuntimeException. See the other DHPrivateKey ctor as that specifies it 
correctly.


--Sean

Re: Fix for Javadoc errors in java.base

[Daniel Fuchs]

Hi Vipin, Julia,

On 13/08/2020 16:05, Julia Boes wrote:

Hi Vipin,

Thanks for providing this fix, I'm happy to sponsor your change. To 
complete the review, we still need someone to green light the remaining 
changes below. I'm looping in net-dev and security-dev to have a look.


Changes to Socket and ServerSocket look fine.
No CSR needed since this is a package private API.




Bug: https://bugs.openjdk.java.net/browse/JDK-8251542

Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8251542/webrev/


best regards,

-- daniel

Re: [aarch64-port-dev ] [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64

[Stuart Monteith]

On 13/08/2020 11:00, Andrew Haley wrote:

On 12/08/2020 12:38, Stuart Monteith wrote:

 > The method "testDigest" generates an byte array of a given size,
 > with each element filled with it's own index & 0xff.
 >
 > The test is then run once, assumed uncompiled, it is then "warmed
 > up" and the first generated digest is compared against the digest
 > presumably generated by the intrinsic. This is the same test for all
 > of the message digest algorithms.
 >
 > I'd say the test is no worse than what has gone before. There are
 > additional tests under the jdk library tests, but nothing that
 > addresses the correctness of the MD5 algorithm implementation
 > itself.

Good grief. So there are no compliance tests in the test suite at all.


Yes for any algorithm, for either the intrinsics or the Java implementations.



 > In terms of the status-quo, that patch looks ok to me. I think if
 > the testing is to be expanded, it should be expanded to all of the
 > message digest algorithms.

That's not much more that an excuse for doing nothing, IMO.



My intention was to suggest that more than MD5 or even just the intrinsics need to be tested, it's not an excuse to 
ignore this.


The existing tests are simply a comparison between generated message digest for a single message between the Java code 
and the intrinsics. The NIST samples cover SHA1 and MD5, but there are additional samples here: 
https://csrc.nist.gov/Projects/cryptographic-standards-and-guidelines/example-values .


The message digests in Java under sun.security.provider are:

MD2, MD4, MD5,
SHA1
SHA2:   SHA2-224, SHA2-256,
SHA3:   SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE256
SHA5: SHA-512/224, SHA-512/256, SHA-512, SHA-384,

The intrinsics implemented are:
aarch64: SHA1, SHA2, SHA5 (+MD5)
ppc64:  SHA2, SHA5
x86_64: SHA1, SHA2, SHA5, MD5
x86_32: SHA1, SHA2, MD5

The MD5 patches have been merged already for x86.

SHA3 doesn't have any intrinsic implementations.

MD2 has some example values in its RFC https://tools.ietf.org/html/rfc1319
Likewise, MD4 has example values in its RFC too: 
https://tools.ietf.org/html/rfc1320

My suggestion is to add new tests for each of the message digest algorithms and share them between the JTreg jdk and 
hotspot instrinsics. The MD5 intrinsics could be merged after some demonstration of correctness?


I've CC'd core-libs-dev as this affects the jdk library.

BR,
Stuart

[Ping] Re: 8181919: Refactor test/java/io/File/GetXSpace.sh to java test

[Brian Burkhalter]

Thanks!

> On Aug 11, 2020, at 11:32 AM, Brian Burkhalter  
> wrote:
> 
> A revised version [A] is available pursuant to the changes made in the course 
> of the review [B] of the fix for [C].
> 
> Thanks,
> 
> Brian
> 
> [A] http://cr.openjdk.java.net/~bpb/8181919/webrev.01/ 
> 
> [B] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068094.html 
> 
> [C] https://bugs.openjdk.java.net/browse/JDK-8249703 
> 
> 
>> On Aug 5, 2020, at 11:36 AM, Brian Burkhalter > > wrote:
>> 
>> To fix [1], please consider the patch [2]. This follows on from the proposed 
>> change [3] which in turn follows from [4].
>> 
>> Thanks,
>> 
>> Brian
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8181919 
>> 
>> [2] http://cr.openjdk.java.net/~bpb/8181919/webrev.00/ 
>> 
>> [3] 
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068025.html
>>  
>> 
>>  (GetXSpace should not run on AIX)
>> [4] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/067990.html 
>>  
>> (GetXSpace fails on macOS)
> 

Re: 8251160: Fix "no comment" warnings in java.logging

[Lance Andersen]

Hi Daniel,

The changes look good.

I added myself as a reviewer to the CSR

Best
Lance

> On Aug 13, 2020, at 8:00 AM, Daniel Fuchs  wrote:
> 
> Hi,
> 
> Please find below a doc-only fix for:
> 
> 8251160: Fix "no comment" warnings in java.logging
> https://bugs.openjdk.java.net/browse/JDK-8251160
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8251534
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8251160/webrev.00/
> 
> The documentation of the serial form of java.util.logging.Level
> and java.util.logging.LogRecord is improved to avoid doclint
> warnings.
> 
> best regards,
> 
> -- daniel


Best
Lance
--




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: Fix for Javadoc errors in java.base

[Julia Boes]

Hi Vipin,

Thanks for providing this fix, I'm happy to sponsor your change. To 
complete the review, we still need someone to green light the remaining 
changes below. I'm looping in net-dev and security-dev to have a look.


Bug: https://bugs.openjdk.java.net/browse/JDK-8251542

Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8251542/webrev/

Once the review is completed, please provide me with a patch that 
includes a changeset comment as described here: 
https://openjdk.java.net/guide/producingChangeset.html


If you have any questions, let me know.

Cheers,

Julia


--- old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java
2020-07-25 23:46:21.233726447 +0530
+++ new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java
2020-07-25 23:46:20.721720857 +0530
@@ -96,8 +96,6 @@
   * @param p the prime modulus
   * @param g the base generator
   * @param l the private-value length
- *
- * @exception InvalidKeyException if the key cannot be encoded
   */
  DHPrivateKey(BigInteger x, BigInteger p, BigInteger g, int l) {
  this.x = x;
--- 
old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
2020-07-25 23:46:22.241737383 +0530
+++ 
new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
2020-07-25 23:46:21.745732013 +0530
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -208,7 +208,7 @@
   *
   * @return a CallSite, which, when invoked, will return an instance of the
   * functional interface
- * @throws ReflectiveOperationException
+ * @throws LambdaConversionException
   */
  abstract CallSite buildCallSite()
  throws LambdaConversionException;
--- 
old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
2020-07-25 23:46:23.261748361 +0530
+++ 
new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
2020-07-25 23:46:22.761742991 +0530
@@ -200,7 +200,6 @@
   *
   * @return a CallSite, which, when invoked, will return an instance of the
   * functional interface
- * @throws ReflectiveOperationException
   * @throws LambdaConversionException If properly formed functional 
interface
   * is not found
   */
--- old/src/java.base/share/classes/java/net/ServerSocket.java 2020-07-25
23:46:26.449782093 +0530
+++ new/src/java.base/share/classes/java/net/ServerSocket.java 2020-07-25
23:46:25.937776742 +0530
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1995, 2020, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -315,7 +315,7 @@
  /**
   * Creates the socket implementation.
   *
- * @throws IOException if creation fails
+ * @throws SocketException if creation fails
   * @since 1.4
   */
  void createImpl() throws SocketException {
--- old/src/java.base/share/classes/java/net/Socket.java 2020-07-25
23:46:27.485792869 +0530
+++ new/src/java.base/share/classes/java/net/Socket.java 2020-07-25
23:46:26.973787565 +0530
@@ -533,7 +533,7 @@
   *
   * @param stream a {@code boolean} value : {@code true} for a TCP socket,
   *   {@code false} for UDP.
- * @throws IOException if creation fails
+ * @throws SocketException if creation fails
   * @since 1.4
   */
   void createImpl(boolean stream) throws SocketException {

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

[forax]

- Mail original -
> De: "Florian Weimer" 
> À: "Remi Forax" 
> Cc: "Patrick Concannon" , "Julia Boes" 
> , "Anthony Vanelverdinghe"
> , "core-libs-dev" 
> Envoyé: Jeudi 13 Août 2020 11:58:38
> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more 
> amenable to pushing’

> * Remi Forax:
> 
>> I still don't like the fact that IntMapMultiConsumer,
>> DoubleMapMultiConsumer and LongMapMultiConsumer are not in
>> java.util.function unlike all other functional interfaces used by
>> the Stream API.
> 
> They seem rather too specific for java.util.function to me.  Maybe we
> should add BiIntObjectConsumer etc., a BiConsumer whose first argument
> is fixed as an int?  And the second consumer would be injected as a
> type parameter, specific to the use in IntStream?

yes, you right, the interafce should be changed as you said.

Rémi

8251160: Fix "no comment" warnings in java.logging

[Daniel Fuchs]

Hi,

Please find below a doc-only fix for:

8251160: Fix "no comment" warnings in java.logging
https://bugs.openjdk.java.net/browse/JDK-8251160

CSR: https://bugs.openjdk.java.net/browse/JDK-8251534

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8251160/webrev.00/

The documentation of the serial form of java.util.logging.Level
and java.util.logging.LogRecord is improved to avoid doclint
warnings.

best regards,

-- daniel

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

[Florian Weimer]

* Remi Forax:

> I still don't like the fact that IntMapMultiConsumer,
> DoubleMapMultiConsumer and LongMapMultiConsumer are not in
> java.util.function unlike all other functional interfaces used by
> the Stream API.

They seem rather too specific for java.util.function to me.  Maybe we
should add BiIntObjectConsumer etc., a BiConsumer whose first argument
is fixed as an int?  And the second consumer would be injected as a
type parameter, specific to the use in IntStream?

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

[Florian Weimer]

* Patrick Concannon:

> webrev: http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.05/

+ * The results of this method are undefined if the second {@link 
IntConsumer}
+ * argument is operated on outside the scope of the mapper function.

Should this say “after the mapper function has returned”?  Otherwise,
one could argue that is possible to use a consumer from a previous
invocation of the mapper function.

(And maybe add a comma after “second”?  Not a native speaker.)