Re: Fix for Javadoc errors in java.base

[Vipin Sharma]

Hi Joe,

I ran an IntelliJ inspection to find these errors.

Regards,
Vipin


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Jul 28, 2020 at 5:53 AM Joe Darcy  wrote:

> Hello Vipin,
>
> What tooling was used to find these errors? Running doclint against
> private methods too?
>
> Thanks,
>
> -Joe
>
> On 7/27/2020 12:37 PM, Vipin Sharma wrote:
> > Hi,
> >
> > This patch fixes Javadoc errors in java.base, please sponsor this patch
> and
> > help to create a bug id for this.
> > I have signed OCA, this is my third patch.
> >
> > ---
> > 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/math/BigDecimal.java 2020-07-25
> > 23:46:24.285759291 +0530
> > +++ new/src/java.base/share/classes/java/math/BigDecimal.java 2020-07-25
> > 23:46:23.785753966 +0530
> > @@ -5413,7 +5413,7 @@
> >*
> >* @param n the numerator; must be negative
> >* @param d the denominator; must not be unity
> > - * @return a two-element {@long} array with the remainder and
> quotient
> > in
> > + * @return a two-element {@code long} array with the remainder and
> > quotient in
> >* the initial and final elements, respectively
> >*/
> >   private static long[] divRemNegativeLong(long n, long d) {
> > --- old/src/java.base/share/classes/java/math/MutableBigInteger.java
> > 2020-07-25 23:46:25.381770889 +0530
> > +++ new/src/java.base/share/classes/java/math/MutableBigInteger.java
> > 2020-07-25 23:46:24.877765572 +0530
> > @@ -145,7 +145,6 @@
> >* Makes this number an {@code n}-int number all of whose bits are
> > ones.
> >* Used by Burnikel-Ziegler division.
> >* @param n number of ints in the {@code value} array
> > - * @return a number equal to {@code ((1<<(32*n)))-1}
> >*/
> >   private void ones(int n) {
> >   if (n > value.length)
> > --- 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 

Re: RFR: 8247546: Pattern matching does not skip correctly over supplementary characters

[naoto . sato]

Hi Joe,

Thank you for the review!

On 7/27/20 6:04 PM, Joe Wang wrote:

Hi Naoto,

Looks good to me, using the correct supplementary-aware implementation 
is an improvement for the impl to handle the situation.


A note (probably a workaround) for the user's case, to replace invalid 
surrogate characters, he could have used Unicode escape sequences 
[\ud800-\udfff] instead.


Yes.



For the test, I wonder if it'd be better to combine the 1st and 2nd, 3rd 
and 4th cases into: xxx\udca9\ud83d\udca9\ud83dyyy to represent two lone 
surrogates plus a valid pair.


If we combine test strings into the one mentioned above, I think it 
cannot distinguish the case we wanted to test. They all match with the 
first unpaired surrogate, i.e., \udca9.




A minor comment on the comments of the test cases (in 
SupplementaryTestCases.txt): instead of repeating the bug id (that is: 
// @bug 8247546), it may be good to provide a short note (e.g. match 
lone/invalid surrogates).


Right, there is no reason to leave bug id since it can be found from hg 
log. Instead, I replaced them with more useful short notes.


Revised webrev:
https://cr.openjdk.java.net/~naoto/8247546/webrev.02/

Naoto



Regards,
Joe

On 7/27/20 2:18 PM, naoto.s...@oracle.com wrote:

On 7/27/20 11:51 AM, naoto.s...@oracle.com wrote:
Apart from the original issue, there was a bug in Range() method 
(Pattern.java:5795), so it is fixed along.


Created a test case for this:

--- a/test/jdk/java/util/regex/SupplementaryTestCases.txt
+++ b/test/jdk/java/util/regex/SupplementaryTestCases.txt
@@ -149,6 +149,11 @@
 \ud83d\udca9
 false 0

+// @bug 8247546
+[\x{dc00}-\x{dfff}]
+\ud83d\udca9
+false 0
+
 // use of x modifier
 \ud800\udc61bc(?x)bl\ud800\udc61h
 \ud800\udc61bcbl\ud800\udc61h

Low surrogate range check falls into using BmpCharPredicate, which 
results in the same bug. The entire webrev is also revised:


http://cr.openjdk.java.net/~naoto/8247546/webrev.01/

Naoto

Re: RFR: 8247546: Pattern matching does not skip correctly over supplementary characters

[Joe Wang]

Hi Naoto,

Looks good to me, using the correct supplementary-aware implementation 
is an improvement for the impl to handle the situation.


A note (probably a workaround) for the user's case, to replace invalid 
surrogate characters, he could have used Unicode escape sequences 
[\ud800-\udfff] instead.


For the test, I wonder if it'd be better to combine the 1st and 2nd, 3rd 
and 4th cases into: xxx\udca9\ud83d\udca9\ud83dyyy to represent two lone 
surrogates plus a valid pair.


A minor comment on the comments of the test cases (in 
SupplementaryTestCases.txt): instead of repeating the bug id (that is: 
// @bug 8247546), it may be good to provide a short note (e.g. match 
lone/invalid surrogates).


Regards,
Joe

On 7/27/20 2:18 PM, naoto.s...@oracle.com wrote:

On 7/27/20 11:51 AM, naoto.s...@oracle.com wrote:
Apart from the original issue, there was a bug in Range() method 
(Pattern.java:5795), so it is fixed along.


Created a test case for this:

--- a/test/jdk/java/util/regex/SupplementaryTestCases.txt
+++ b/test/jdk/java/util/regex/SupplementaryTestCases.txt
@@ -149,6 +149,11 @@
 \ud83d\udca9
 false 0

+// @bug 8247546
+[\x{dc00}-\x{dfff}]
+\ud83d\udca9
+false 0
+
 // use of x modifier
 \ud800\udc61bc(?x)bl\ud800\udc61h
 \ud800\udc61bcbl\ud800\udc61h

Low surrogate range check falls into using BmpCharPredicate, which 
results in the same bug. The entire webrev is also revised:


http://cr.openjdk.java.net/~naoto/8247546/webrev.01/

Naoto

Re: Fix for Javadoc errors in java.base

[Joe Darcy]

Hello Vipin,

What tooling was used to find these errors? Running doclint against 
private methods too?


Thanks,

-Joe

On 7/27/2020 12:37 PM, Vipin Sharma wrote:

Hi,

This patch fixes Javadoc errors in java.base, please sponsor this patch and
help to create a bug id for this.
I have signed OCA, this is my third patch.

---
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/math/BigDecimal.java 2020-07-25
23:46:24.285759291 +0530
+++ new/src/java.base/share/classes/java/math/BigDecimal.java 2020-07-25
23:46:23.785753966 +0530
@@ -5413,7 +5413,7 @@
   *
   * @param n the numerator; must be negative
   * @param d the denominator; must not be unity
- * @return a two-element {@long} array with the remainder and quotient
in
+ * @return a two-element {@code long} array with the remainder and
quotient in
   * the initial and final elements, respectively
   */
  private static long[] divRemNegativeLong(long n, long d) {
--- old/src/java.base/share/classes/java/math/MutableBigInteger.java
2020-07-25 23:46:25.381770889 +0530
+++ new/src/java.base/share/classes/java/math/MutableBigInteger.java
2020-07-25 23:46:24.877765572 +0530
@@ -145,7 +145,6 @@
   * Makes this number an {@code n}-int number all of whose bits are
ones.
   * Used by Burnikel-Ziegler division.
   * @param n number of ints in the {@code value} array
- * @return a number equal to {@code ((1<<(32*n)))-1}
   */
  private void ones(int n) {
  if (n > value.length)
--- 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 {
---
old/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java
2020-07-25 23:46:28.545803801 +0530
+++

Re: RFR: 8247546: Pattern matching does not skip correctly over supplementary characters

[naoto . sato]

On 7/27/20 11:51 AM, naoto.s...@oracle.com wrote:
Apart from the original issue, there was a bug in Range() method 
(Pattern.java:5795), so it is fixed along.


Created a test case for this:

--- a/test/jdk/java/util/regex/SupplementaryTestCases.txt
+++ b/test/jdk/java/util/regex/SupplementaryTestCases.txt
@@ -149,6 +149,11 @@
 \ud83d\udca9
 false 0

+// @bug 8247546
+[\x{dc00}-\x{dfff}]
+\ud83d\udca9
+false 0
+
 // use of x modifier
 \ud800\udc61bc(?x)bl\ud800\udc61h
 \ud800\udc61bcbl\ud800\udc61h

Low surrogate range check falls into using BmpCharPredicate, which 
results in the same bug. The entire webrev is also revised:


http://cr.openjdk.java.net/~naoto/8247546/webrev.01/

Naoto

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Ningsheng Jian]

Thank you Erik!

Regards,
Ningsheng

On 7/23/20 9:06 PM, Erik Joelsson wrote:

Hello Ningsheng,

Build change looks good.

/Erik

On 2020-07-23 01:02, Ningsheng Jian wrote:

Hi Vladimir,

Thanks for pointing out this. Yes, I missed that change in shared 
code. I've regenerated the webrev, with GensrcAdlc.gmk file change 
included:


http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 



Also add build-dev.

Thanks,
Ningsheng

On 7/23/20 5:36 AM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 





FTR there's one more aarch64-specific change in shared code to enable 
aarch64_neon.ad processing:


diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk 
b/make/hotspot/gensrc/GensrcAdlc.gmk

--- a/make/hotspot/gensrc/GensrcAdlc.gmk
+++ b/make/hotspot/gensrc/GensrcAdlc.gmk
@@ -129,6 +129,12 @@

$d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad 
\

  )))

+  ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64)
+    AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
$(AD_SRC_ROOTS), \

+ $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \
+    )))
+  endif
+
    ifeq ($(call check-jvm-feature, shenandoahgc), true)
  AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
$(AD_SRC_ROOTS), \


$d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad 
\


Best regards,
Vladimir Ivanov


On 7/8/20 3:05 PM, Yang Zhang wrote:

Hi Andrew

I have updated this patch. Could you please help to review it again?
In this patch, the following changes are made:
1. Separate newly added NEON instructions to a new ad file
    aarch64_neon.ad
2. Add assembler tests for NEON instructions. Trailing spaces
    in the python script are also removed.

http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ 



Thanks,
Yang


-Original Message-
From: Andrew Haley 
Sent: Tuesday, June 30, 2020 12:10 AM
To: Yang Zhang ; Viswanathan, Sandhya 
; Paul Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of 
Vector API (Incubator): AArch64 backend changes


On 29/06/2020 08:48, Yang Zhang wrote:

1. Instructions that can be matched with NEON instructions directly.
MulVB, SqrtVF and AbsV have been merged into jdk master already.

2. Instructions that jdk master has middle end support for, but 
they cannot be matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These 
new instructions can be moved into jdk master first, but for 
auto-vectorization, the performance might not get improved.


3. Panama/Vector API specific  instructions such as 
Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, 
MaxV/MinV, VectorBlend etc.
These instructions cannot be moved into jdk master first because 
there isn't middle-end support.


I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also 
update aarch64_asmtest.py and macroassemler.cpp. When the patch is 
ready, I will send it again.


Thank you *very* much for your hard work. Appreciated!

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd.  
https://keybase.io/andrewhaley

EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR(M): 8249963: Make the zlib implementation selectively configurable at startup

[Brian Goetz]

So from your (and Alan's and Lance's) point of view does it still make 
sense to create a JEP for this enhancement and have a broader 
discussion about its usefulness on the "discuss" list? Or is your 
rejection definitive, no matter what the outcome of such a discussion 
will be?


I think it's perfectly fine to start a discussion.  I wouldn't start 
with a JEP draft, though, as that will have many of the same problems 
that the RFR did.  You'll want to start with what you see as the 
problem, why it is a problem, why it needs to be solved in the JDK, etc, 
and then proceed to evaluating solutions, as I outlined in my mail, and 
build consensus at each step.


Given the discussions we've had already, it seems highly unlikely that a 
JEP that enshrined _this exact solution_ would gain consensus.  But, it 
is entirely possible that an open-minded discussion of the problem and 
the many possible solutions, might lead to a solution that you could 
build some consensus around.  (Or it might not; that's OK too.)





I realize it sucks when you've done a lot of work and someone says
"but we don't want/need that"; this is why you socialize the idea
first.  Alan said in his first mail "I don't think the JDK should
be in the business of ..." -- that's a clear "this is not a
problem that needs to be solved in the JDK."  That's why we start
at the top of the list.


That's simply not true. I've developed this change to solve a real 
problem and while doing so I went through all the points you've listed 
above. I'm quite happy with it because we're using it productively 
with good results. I've just proposed it here because I thought it 
might be useful for others as well but if that's not the case it's 
perfectly fine for me.




I will answer this one as it speaks to a common mis-assumption about 
OpenJDK.  You obviously had some variant of the problem+solutions 
discussion internally on your team, and came to a solution that worked 
in your situation.  That's all good!  But, you should be prepared to 
start back at the beginning if you want to change "everybody's Java"; 
the set of considerations for a feature in a given deployment or even 
distribution are not the same as for the upstream, so the discussion 
might go differently.  (In particular, the answer to "is this a problem 
that needs to be solved in " may well vary with 
.)

Fix for Javadoc errors in java.base

[Vipin Sharma]

Hi,

This patch fixes Javadoc errors in java.base, please sponsor this patch and
help to create a bug id for this.
I have signed OCA, this is my third patch.

---
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/math/BigDecimal.java 2020-07-25
23:46:24.285759291 +0530
+++ new/src/java.base/share/classes/java/math/BigDecimal.java 2020-07-25
23:46:23.785753966 +0530
@@ -5413,7 +5413,7 @@
  *
  * @param n the numerator; must be negative
  * @param d the denominator; must not be unity
- * @return a two-element {@long} array with the remainder and quotient
in
+ * @return a two-element {@code long} array with the remainder and
quotient in
  * the initial and final elements, respectively
  */
 private static long[] divRemNegativeLong(long n, long d) {
--- old/src/java.base/share/classes/java/math/MutableBigInteger.java
2020-07-25 23:46:25.381770889 +0530
+++ new/src/java.base/share/classes/java/math/MutableBigInteger.java
2020-07-25 23:46:24.877765572 +0530
@@ -145,7 +145,6 @@
  * Makes this number an {@code n}-int number all of whose bits are
ones.
  * Used by Burnikel-Ziegler division.
  * @param n number of ints in the {@code value} array
- * @return a number equal to {@code ((1<<(32*n)))-1}
  */
 private void ones(int n) {
 if (n > value.length)
--- 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 {
---
old/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java
2020-07-25 23:46:28.545803801 +0530
+++
new/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java
2020-07-25 23:46:28.029798501 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All 

RFR: 8247546: Pattern matching does not skip correctly over supplementary characters

[naoto . sato]

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8247546

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8247546/webrev.00/

On compiling the regex pattern, the start node is chosen based on the 
pattern, i.e, whether it involves supplementary processing or not. On 
deciding which implementation to use, surrogates were not taken into 
consideration, which leads to the issue in the bug report. The proposed 
fix is to make it aware of surrogates, and choose the correct 
supplementary-aware implementation for the start node.


Apart from the original issue, there was a bug in Range() method 
(Pattern.java:5795), so it is fixed along.


Naoto

Re: [15] RFR(S) : 6501010 : test/java/io/File/GetXSpace.java fails on Windows

[Igor Ignatyev]

ping?

-- Igor

> On Jul 20, 2020, at 11:28 AM, Igor Ignatyev  wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//6501010/webrev.00
>> 98 lines changed: 18 ins; 31 del; 49 mod;
> 
> Hi all,
> 
> could you please review this small fix to make java/io/File/GetXSpace.java 
> work again on windows?
> 
> the test has been updated to work under cygwin, which includes the following 
> changes:
> - GetXSpace.sh accepts CYGWIN_* as known OS and sets windows path to TMP var
> - uses the same regexp to parse df on windows as on other platforms
> - but uses 'FileSystem' field as Space's name, as opposed to 'MountedOn' on 
> *nix, as on cygwin, MountedOn is cygwin path, while FileSystem is 
> corresponding windows path, and the test expect Space's name to be 
> appropriate path
> 
> the patch also includes some small faceliftings:
> - printing out a bit more information to facilitate failure analyses, e.g. df 
> output, exception stack traces
> - usage of try-w/-resources
> - remove of code duplication
> - usage of generics
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//6501010/webrev.00
> testing: java/io/File/GetXSpace.java 100 times on {linux,windows}-x64
> JBS: https://bugs.openjdk.java.net/browse/JDK-6501010
> 
> Thanks,
> -- Igor

Re: No way to disable Java Container Metrics

[Severin Gehwolf]

On Mon, 2020-07-27 at 11:52 -0400, Bob Vandette wrote:
> > On Jul 27, 2020, at 11:32 AM, Severin Gehwolf  wrote:
> > 
> > Hi Bob,
> > 
> > On Fri, 2020-07-24 at 15:21 -0400, Bob Vandette wrote:
> > > I’ve been monitoring the discussion on your jdk8u alias and I can’t help 
> > > wondering if
> > > my original decision to provide two different implementations of this 
> > > container detection
> > > logic was the best way to go.
> > > 
> > > I didn’t want to have an all Java implementation since the VM needs to 
> > > initialize it’s
> > > memory and cpu sizing very early on prior to its ability to run Java code.
> > > 
> > > If we put all of the logic in the VM, then we’d end up with a pretty wide 
> > > interface to
> > > the VM and more overhead extracting values (due to JNI) although the Java 
> > > logic 
> > > typically ends up in native code anyway.  Having the functionality in the 
> > > VM
> > > makes it easier to add JFR events.  Having a pure Java implementation 
> > > makes it
> > > easier to support the OS MBeans.  The maintenance of supporting both 
> > > implementations
> > > is a bit of a pain.
> > 
> > Add to that that Java metrics return non-null for any controller it
> > finds. The JVM doesn't. Container support is turned on there only if
> > all cpu and memory controllers are found.
> 
> That was intentional.  I wanted the VM to configure itself consistently.
> Either all needed value are present or revert to non container mode.
> For Metrics, I felt it was ok to report whatever is available.

Yes, I know. Thanks. What I meant to say was that it's another
consideration to take into account if at some point a JVM-only-impl +
Java wrapper approach would be taken.

Thanks,
Severin
> 
> 
> > > Assuming no one has the time or desire to migrate the logic to
> > > the VM and provide
> > > Java wrapper logic, I’m ok with what you are proposing.  It’s one
> > > step on the path.
> > > The VM support and the Java level support are really for two
> > > different consumers
> > > but I think it would be cleaner and less confusing to disable
> > > both on one flag rather
> > > than support two options.
> > 
> > OK, agreed. I've filed:
> > https://bugs.openjdk.java.net/browse/JDK-8250627
> > 
> > Thanks,
> > Severin
> > 
> > > Bob.
> > > 
> > > > On Jul 24, 2020, at 12:13 PM, Severin Gehwolf <
> > > > sgehw...@redhat.com>
> > > > wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > For hotspot one can disable container detection with a simple
> > > > switch:
> > > > 
> > > > $ java -XX:-UseContainerSupport -Xlog:os+container=trace
> > > > -version
> > > > [0.000s][trace][os,container] OSContainer::init: Initializing
> > > > Container Support
> > > > [0.000s][trace][os,container] Container Support not enabled
> > > > openjdk version "15-internal" 2020-09-15
> > > > OpenJDK Runtime Environment (build 15-internal+0-
> > > > adhoc.sgehwolf.openjdk-head-2)
> > > > OpenJDK 64-Bit Server VM (build 15-internal+0-
> > > > adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing)
> > > > 
> > > > The same cannot be achieved with the Java code,
> > > > jdk.internal.platform.Metrics.java and friends in the JDK. At
> > > > the
> > > > time
> > > > Metrics were added the only consumer of them was the Java
> > > > Launcher
> > > > via
> > > > -XshowSettings:system. This has changed with JDK-8226575:
> > > > OperatingSystemMXBean should be made container aware.
> > > > 
> > > > It is known that in certain cases the container detection code
> > > > will
> > > > detect for a system to be supposedly in a container where it
> > > > actually
> > > > isn't:
> > > > https://bugs.openjdk.java.net/browse/JDK-8227006?focusedCommentId=14275604=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14275604
> > > > 
> > > > For hotspot there is a flag, to turn auto-detection off for
> > > > exactly
> > > > the
> > > > case when heuristics are wrong: -XX:-UseContainerSupport.
> > > > However,
> > > > this
> > > > flag has no effect on the Java metrics code. There is a risk
> > > > that
> > > > on
> > > > some systems the auto-detection will be wrong and might cause
> > > > regressions.
> > > > 
> > > > I propose to make the Java metrics code adhere to -XX:+/-
> > > > UseContainerSupport flag. Do you think this would be useful? If
> > > > yes,
> > > > I'll file a bug and propose a patch for it.
> > > > 
> > > > Thoughts? Opinions?
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 

Re: No way to disable Java Container Metrics

[Bob Vandette]

> On Jul 27, 2020, at 11:32 AM, Severin Gehwolf  wrote:
> 
> Hi Bob,
> 
> On Fri, 2020-07-24 at 15:21 -0400, Bob Vandette wrote:
>> I’ve been monitoring the discussion on your jdk8u alias and I can’t help 
>> wondering if
>> my original decision to provide two different implementations of this 
>> container detection
>> logic was the best way to go.
>> 
>> I didn’t want to have an all Java implementation since the VM needs to 
>> initialize it’s
>> memory and cpu sizing very early on prior to its ability to run Java code.
>> 
>> If we put all of the logic in the VM, then we’d end up with a pretty wide 
>> interface to
>> the VM and more overhead extracting values (due to JNI) although the Java 
>> logic 
>> typically ends up in native code anyway.  Having the functionality in the VM
>> makes it easier to add JFR events.  Having a pure Java implementation makes 
>> it
>> easier to support the OS MBeans.  The maintenance of supporting both 
>> implementations
>> is a bit of a pain.
> 
> Add to that that Java metrics return non-null for any controller it
> finds. The JVM doesn't. Container support is turned on there only if
> all cpu and memory controllers are found.

That was intentional.  I wanted the VM to configure itself consistently.
Either all needed value are present or revert to non container mode.
For Metrics, I felt it was ok to report whatever is available.

Bob.


> 
>> Assuming no one has the time or desire to migrate the logic to the VM and 
>> provide
>> Java wrapper logic, I’m ok with what you are proposing.  It’s one step on 
>> the path.
>> The VM support and the Java level support are really for two different 
>> consumers
>> but I think it would be cleaner and less confusing to disable both on one 
>> flag rather
>> than support two options.
> 
> OK, agreed. I've filed:
> https://bugs.openjdk.java.net/browse/JDK-8250627
> 
> Thanks,
> Severin
> 
>> Bob.
>> 
>>> On Jul 24, 2020, at 12:13 PM, Severin Gehwolf 
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> For hotspot one can disable container detection with a simple
>>> switch:
>>> 
>>> $ java -XX:-UseContainerSupport -Xlog:os+container=trace -version
>>> [0.000s][trace][os,container] OSContainer::init: Initializing
>>> Container Support
>>> [0.000s][trace][os,container] Container Support not enabled
>>> openjdk version "15-internal" 2020-09-15
>>> OpenJDK Runtime Environment (build 15-internal+0-
>>> adhoc.sgehwolf.openjdk-head-2)
>>> OpenJDK 64-Bit Server VM (build 15-internal+0-
>>> adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing)
>>> 
>>> The same cannot be achieved with the Java code,
>>> jdk.internal.platform.Metrics.java and friends in the JDK. At the
>>> time
>>> Metrics were added the only consumer of them was the Java Launcher
>>> via
>>> -XshowSettings:system. This has changed with JDK-8226575:
>>> OperatingSystemMXBean should be made container aware.
>>> 
>>> It is known that in certain cases the container detection code will
>>> detect for a system to be supposedly in a container where it
>>> actually
>>> isn't:
>>> https://bugs.openjdk.java.net/browse/JDK-8227006?focusedCommentId=14275604=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14275604
>>> 
>>> For hotspot there is a flag, to turn auto-detection off for exactly
>>> the
>>> case when heuristics are wrong: -XX:-UseContainerSupport. However,
>>> this
>>> flag has no effect on the Java metrics code. There is a risk that
>>> on
>>> some systems the auto-detection will be wrong and might cause
>>> regressions.
>>> 
>>> I propose to make the Java metrics code adhere to -XX:+/-
>>> UseContainerSupport flag. Do you think this would be useful? If
>>> yes,
>>> I'll file a bug and propose a patch for it.
>>> 
>>> Thoughts? Opinions?
>>> 
>>> Thanks,
>>> Severin
>>> 
> 

Re: No way to disable Java Container Metrics

[Severin Gehwolf]

Hi Bob,

On Fri, 2020-07-24 at 15:21 -0400, Bob Vandette wrote:
> I’ve been monitoring the discussion on your jdk8u alias and I can’t help 
> wondering if
> my original decision to provide two different implementations of this 
> container detection
> logic was the best way to go.
> 
> I didn’t want to have an all Java implementation since the VM needs to 
> initialize it’s
> memory and cpu sizing very early on prior to its ability to run Java code.
> 
> If we put all of the logic in the VM, then we’d end up with a pretty wide 
> interface to
> the VM and more overhead extracting values (due to JNI) although the Java 
> logic 
> typically ends up in native code anyway.  Having the functionality in the VM
> makes it easier to add JFR events.  Having a pure Java implementation makes it
> easier to support the OS MBeans.  The maintenance of supporting both 
> implementations
> is a bit of a pain.

Add to that that Java metrics return non-null for any controller it
finds. The JVM doesn't. Container support is turned on there only if
all cpu and memory controllers are found.

> Assuming no one has the time or desire to migrate the logic to the VM and 
> provide
> Java wrapper logic, I’m ok with what you are proposing.  It’s one step on the 
> path.
> The VM support and the Java level support are really for two different 
> consumers
> but I think it would be cleaner and less confusing to disable both on one 
> flag rather
> than support two options.

OK, agreed. I've filed:
https://bugs.openjdk.java.net/browse/JDK-8250627

Thanks,
Severin

> Bob.
> 
> > On Jul 24, 2020, at 12:13 PM, Severin Gehwolf 
> > wrote:
> > 
> > Hi,
> > 
> > For hotspot one can disable container detection with a simple
> > switch:
> > 
> > $ java -XX:-UseContainerSupport -Xlog:os+container=trace -version
> > [0.000s][trace][os,container] OSContainer::init: Initializing
> > Container Support
> > [0.000s][trace][os,container] Container Support not enabled
> > openjdk version "15-internal" 2020-09-15
> > OpenJDK Runtime Environment (build 15-internal+0-
> > adhoc.sgehwolf.openjdk-head-2)
> > OpenJDK 64-Bit Server VM (build 15-internal+0-
> > adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing)
> > 
> > The same cannot be achieved with the Java code,
> > jdk.internal.platform.Metrics.java and friends in the JDK. At the
> > time
> > Metrics were added the only consumer of them was the Java Launcher
> > via
> > -XshowSettings:system. This has changed with JDK-8226575:
> > OperatingSystemMXBean should be made container aware.
> > 
> > It is known that in certain cases the container detection code will
> > detect for a system to be supposedly in a container where it
> > actually
> > isn't:
> > https://bugs.openjdk.java.net/browse/JDK-8227006?focusedCommentId=14275604=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14275604
> > 
> > For hotspot there is a flag, to turn auto-detection off for exactly
> > the
> > case when heuristics are wrong: -XX:-UseContainerSupport. However,
> > this
> > flag has no effect on the Java metrics code. There is a risk that
> > on
> > some systems the auto-detection will be wrong and might cause
> > regressions.
> > 
> > I propose to make the Java metrics code adhere to -XX:+/-
> > UseContainerSupport flag. Do you think this would be useful? If
> > yes,
> > I'll file a bug and propose a patch for it.
> > 
> > Thoughts? Opinions?
> > 
> > Thanks,
> > Severin
> > 

Re: Type inference: bug or feature?

[Justin Dekeyser]

Hello,

Thank you for your input!
Indeed, the reason of such a choice sounds legit and confirms the idea of
having more safety.

I just came with this situation while playing around with Java, and I was
surprised;
But it definitely was an academic example that was not planned for real use
cases! ;-)

Thank you very much,

Have a nice day,

Justin Dekeyser



On Mon, Jul 27, 2020 at 12:55 PM Remi Forax  wrote:

> - Mail original -
> > De: "Maurizio Cimadamore" 
> > À: "Justin Dekeyser" , "core-libs-dev" <
> core-libs-dev@openjdk.java.net>
> > Envoyé: Lundi 27 Juillet 2020 12:26:40
> > Objet: Re: Type inference: bug or feature?
>
> > CC'ing compiler-dev
> >
> > Hi Justin,
> > the behavior you are observing is normal. For a Java expression to be
> > able to be influenced by type inference it has to be a poly expression
> > (where poly stands for _many_ as in, the same expression can have many
> > types).
> >
> > At the time we did Java 8 we briefly considered making cast expressions
> > part of the poly expression dance (like lambdas, method references,
> > method calls, parens, new creation expression, conditionals and switch
> > expression - see JLS 15.2), but the rule which dictate cast conversion
> > (JLS 5.5) are so complex (as they have to take into account possibility
> > for unchecked cast, etc.) that it felt like touching them was a very
> > risky move, with no clear benefit.
>
> There was another reason :)
>
> The idea behind introducing generics is to get ride of casts because they
> are a hazard at runtime.
> So allowing people to use casts as poly expression goes in the wrong
> direction, add more casts.
>
> Instead of using a cast, it's better to use explicit type arguments,
>   TheClass.emptyList()
>
> [...]
>
> >
> > Cheers
> > Maurizio
>
> regards,
> Rémi
>
> >
> > On 26/07/2020 18:22, Justin Dekeyser wrote:
> >> Dear all,
> >>
> >> I'm not sure but I think I've found a bug in Java type inference
> mechanism.
> >> It may also be a feature, so I'll expose the problem to you below; in
> terms
> >> of Integer, Number and List, although you'll quickly realize it will
> work
> >> wrong in any similar situation.
> >>
> >> Let's assume I have
> >>
> >> static  List emptyList(Class magnet) {
> >> return Collections.emptyList();
> >> }
> >>
> >> Then the following codes does not compile (for the same reason):
> >>
> >> var x = (List) emptyList(Number.class);
> >> List x = (List) emptyList(Number.class);
> >>
> >> incompatible types: List cannot be converted to List
> >>
> >> however, the following do compile:
> >>
> >> var x = emptyList(Number.class); // inferred to List
> >> List x = emptyList(Number.class); // no mistake here, it's
> Integer
> >> on the left
> >>
> >> Is this the expected behavior? Why does casting operation here interfere
> >> with type inference like this?
> >>
> >> Regards,
> >>
> >> Justin Dekeyser
> >>
> >>
> >>
> >>
> >> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> >> Garanti
> >> sans virus. www.avast.com
> >> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: Type inference: bug or feature?

[Remi Forax]

- Mail original -
> De: "Maurizio Cimadamore" 
> À: "Justin Dekeyser" , "core-libs-dev" 
> 
> Envoyé: Lundi 27 Juillet 2020 12:26:40
> Objet: Re: Type inference: bug or feature?

> CC'ing compiler-dev
> 
> Hi Justin,
> the behavior you are observing is normal. For a Java expression to be
> able to be influenced by type inference it has to be a poly expression
> (where poly stands for _many_ as in, the same expression can have many
> types).
> 
> At the time we did Java 8 we briefly considered making cast expressions
> part of the poly expression dance (like lambdas, method references,
> method calls, parens, new creation expression, conditionals and switch
> expression - see JLS 15.2), but the rule which dictate cast conversion
> (JLS 5.5) are so complex (as they have to take into account possibility
> for unchecked cast, etc.) that it felt like touching them was a very
> risky move, with no clear benefit.

There was another reason :)

The idea behind introducing generics is to get ride of casts because they are a 
hazard at runtime.
So allowing people to use casts as poly expression goes in the wrong direction, 
add more casts.

Instead of using a cast, it's better to use explicit type arguments,
  TheClass.emptyList()

[...]

> 
> Cheers
> Maurizio

regards,
Rémi

> 
> On 26/07/2020 18:22, Justin Dekeyser wrote:
>> Dear all,
>>
>> I'm not sure but I think I've found a bug in Java type inference mechanism.
>> It may also be a feature, so I'll expose the problem to you below; in terms
>> of Integer, Number and List, although you'll quickly realize it will work
>> wrong in any similar situation.
>>
>> Let's assume I have
>>
>> static  List emptyList(Class magnet) {
>> return Collections.emptyList();
>> }
>>
>> Then the following codes does not compile (for the same reason):
>>
>> var x = (List) emptyList(Number.class);
>> List x = (List) emptyList(Number.class);
>>
>> incompatible types: List cannot be converted to List
>>
>> however, the following do compile:
>>
>> var x = emptyList(Number.class); // inferred to List
>> List x = emptyList(Number.class); // no mistake here, it's Integer
>> on the left
>>
>> Is this the expected behavior? Why does casting operation here interfere
>> with type inference like this?
>>
>> Regards,
>>
>> Justin Dekeyser
>>
>>
>>
>>
>> 
>> Garanti
>> sans virus. www.avast.com
>> 
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Type inference: bug or feature?

[Justin Dekeyser]

Dear all,

Okay, thank you very much for the many references you gave me!
Indeed I wasn't aware of this specificity of cast expressions you
mentioned, very interesting !

Sorry for the long email chain, though!

Have a nice day,

Justin Dekeyser


On Mon, Jul 27, 2020 at 12:26 PM Maurizio Cimadamore <
maurizio.cimadam...@oracle.com> wrote:

> CC'ing compiler-dev
>
> Hi Justin,
> the behavior you are observing is normal. For a Java expression to be
> able to be influenced by type inference it has to be a poly expression
> (where poly stands for _many_ as in, the same expression can have many
> types).
>
> At the time we did Java 8 we briefly considered making cast expressions
> part of the poly expression dance (like lambdas, method references,
> method calls, parens, new creation expression, conditionals and switch
> expression - see JLS 15.2), but the rule which dictate cast conversion
> (JLS 5.5) are so complex (as they have to take into account possibility
> for unchecked cast, etc.) that it felt like touching them was a very
> risky move, with no clear benefit.
>
> The behavior you see is caused by the fact that the cast expression acts
> as a "shield" - that is, whenever a method call appears after a cast
> expression (as in your case), the method call is type-checked as if it
> were in isolation, and _then_ the result of type checking is validated
> against the cast. In other words, your example is no different than doing:
>
> var x = (List)(Object)emptyList(Number.class);
>
>
> That is, the emptyList call will see no meaningful target type (just
> Object), so Number will be inferred and a List will be returned,
> which will then be incompatible with the type of the cast expression
> (List).
>
> Your second set of examples, since it does not make use of cast
> expressions, works as expected, as the target type can freely flow
> inside the method call typing, and thus influence the type inference
> result (e.g. the inference engine now sees two constraints, for Integer
> and for Number, and is of course able to pick the "best" one).
>
> Hope this helps.
>
> Cheers
> Maurizio
>
> On 26/07/2020 18:22, Justin Dekeyser wrote:
> > Dear all,
> >
> > I'm not sure but I think I've found a bug in Java type inference
> mechanism.
> > It may also be a feature, so I'll expose the problem to you below; in
> terms
> > of Integer, Number and List, although you'll quickly realize it will work
> > wrong in any similar situation.
> >
> > Let's assume I have
> >
> > static  List emptyList(Class magnet) {
> > return Collections.emptyList();
> > }
> >
> > Then the following codes does not compile (for the same reason):
> >
> > var x = (List) emptyList(Number.class);
> > List x = (List) emptyList(Number.class);
> >
> > incompatible types: List cannot be converted to List
> >
> > however, the following do compile:
> >
> > var x = emptyList(Number.class); // inferred to List
> > List x = emptyList(Number.class); // no mistake here, it's
> Integer
> > on the left
> >
> > Is this the expected behavior? Why does casting operation here interfere
> > with type inference like this?
> >
> > Regards,
> >
> > Justin Dekeyser
> >
> >
> >
> >
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > Garanti
> > sans virus. www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: RFR(M): 8249963: Make the zlib implementation selectively configurable at startup

[Volker Simonis]

Hi Brian,

thanks a lot for your detailed answer. I've replied to some of your
comments inline but I don't expect another answer because it seems that all
arguments have been exchanged and we're happily agreeing to disagree :)

There's just a single remaining question for which I would appreciate an
answer. I perfectly understood that the OpenJDK maintainers don't want this
change but this list is obviously biased towards the developers of the
OpenJDK and not its users. So from your (and Alan's and Lance's) point of
view does it still make sense to create a JEP for this enhancement and have
a broader discussion about its usefulness on the "discuss" list? Or is your
rejection definitive, no matter what the outcome of such a discussion will
be?

Thank you and best regards,
Volker

On Fri, Jul 24, 2020 at 10:16 PM Brian Goetz  wrote:

>
>
> On 7/24/2020 7:48 AM, Volker Simonis wrote:
>
> I think it's reasonable to ask if the JDK
> really needs to support this complexity.
>
> I can't see much complexity here.
>
>
> Then I think we should start there.   Until you can see the complexity
> here that is obvious to Alan, Lance, myself, and others, then there is no
> point discussing the specific technical issue.
>
> Every configuration knob or flag creates complexity, because it creates a
> transient environmental dependence -- yet another thing that can cause
> behavior to change even when running the same JDK on the same underlying
> platform.
>
> I think you are looking at _your patch_ and saying "it's not that
> complex", but that's not the kind of complexity we're talking about.  We're
> talking about the number of potential axes that can interact with each
> other to cause surprising or hard-to-debug behavior.  Can you honestly not
> imagine something going wrong with having Inflater use one zlib, Deflator
> another, and crc32 a third?
>
> Until now I'm only hearing mostly high-level ,theoretical arguments
> against the proposal rather than technical objections.
>
>
> That's like when your mother tells you not to run with scissors,
> complaining that her concern is only theoretical, because not only do we
> not know anyone who has injured themselves running with scissors, but even
> if we did, they were not running with THIS pair of scissors."  But of
> course, your mother was right, and Alan (and all the others that reponded)
> are right too.  One of the most important roles of JDK stewards is pushing
> back on unnecessary complexity.  This is what Alan is doing.
>
> The change itself is quite small
>
>
> Small changes can still introduce complexity.  (It's one line of code to
> enforce that methods in Java only have an odd number of checked exceptions
> on tuesdays, but that would surely be new complexity.)
>
> and it doesn't change any default
> behaviour at all so I didn't think a JEP will be required.
>
>
> Which means either it will not be tested, or we have to double the number
> of test modes.
>

The proposed dispatching mechanism should obviously be tested and it should
work flawlessly. But every customer who will use or everybody who will ship
or bundle a combination of alternative libraries will just as obviously
have to test them. Or is Oracle testing all the available native Java
agents which a customer can use just because Java offers an interface which
allows native agents connecting to the VM?


>
> I don't think we have to test all (or even various) zlib
>
> which means customers using this will be running on an effectively
> untested configuration.  Does that seem wise?
>

See my comment above. I just propose to give customers the possibility to
use alternative configurations and I think that's wise. Nobody will ever
run in an untested configuration until he is actively choosing to do so
because he expects that the benefits will outweigh the risks.


> Stepping back, we're in the classic trap where you've skipped over all the
> important discussion, and as a result we've gotten the obvious outcome,
> which is that we're talking about the wrong thing.  Steps you should have
> run before getting tied to your solution, at a minimum, include:
>
>  - Develop a clear and shared understanding about what the problem is
>  - Develop consensus that it is a problem
>  - Develop consensus that it is a problem that needs to be solved in the
> JDK
>  - Brainstorm possible solutions, with tradeoffs, pros, and cons
>  - Identify the best solution, and build consensus around that
>  - Implement
>  - Test
>  - Review
>  - Iterate
>
> But you skipped straight to "Implement", and are now surprised that you're
> getting pushback against what should have been steps 1 or 2.  You are
> trying to drive the discussion to "what changes do I have to make to have
> this patch accepted", but the conversation we should be having is "should
> we solve this problem at all" and then "if so, is this the right
> solution."  And it seems you're not finding anyone who is very compelled by
> either the problem or the solution.
>

Re: Type inference: bug or feature?

[Maurizio Cimadamore]

On 27/07/2020 11:26, Maurizio Cimadamore wrote:

CC'ing compiler-dev

Hi Justin,
the behavior you are observing is normal. For a Java expression to be 
able to be influenced by type inference it has to be a poly expression 
(where poly stands for _many_ as in, the same expression can have many 
types).


At the time we did Java 8 we briefly considered making cast 
expressions part of the poly expression dance (like lambdas, method 
references, method calls, parens, new creation expression, 
conditionals and switch expression - see JLS 15.2), but the rule which 
dictate cast conversion (JLS 5.5) are so complex (as they have to take 
into account possibility for unchecked cast, etc.) that it felt like 
touching them was a very risky move, with no clear benefit.


The behavior you see is caused by the fact that the cast expression 
acts as a "shield" - that is, whenever a method call appears after a 
cast expression (as in your case), the method call is type-checked as 
if it were in isolation, and _then_ the result of type checking is 
validated against the cast. In other words, your example is no 
different than doing:


var x = (List)(Object)emptyList(Number.class);


That is, the emptyList call will see no meaningful target type (just 
Object), so Number will be inferred and a List will be 
returned, which will then be incompatible with the type of the cast 
expression (List).


Your second set of examples, since it does not make use of cast 
expressions, works as expected, as the target type can freely flow 
inside the method call typing, and thus influence the type inference 
result (e.g. the inference engine now sees two constraints, for 
Integer and for Number, and is of course able to pick the "best" one).


Hope this helps.

Cheers
Maurizio

On 26/07/2020 18:22, Justin Dekeyser wrote:

Dear all,

I'm not sure but I think I've found a bug in Java type inference 
mechanism.
It may also be a feature, so I'll expose the problem to you below; in 
terms
of Integer, Number and List, although you'll quickly realize it will 
work

wrong in any similar situation.

Let's assume I have

static  List emptyList(Class magnet) {
    return Collections.emptyList();
}

Then the following codes does not compile (for the same reason):

var x = (List) emptyList(Number.class);
List x = (List) emptyList(Number.class);

incompatible types: List cannot be converted to List

however, the following do compile:

var x = emptyList(Number.class); // inferred to List
List x = emptyList(Number.class); // no mistake here, it's 
Integer

on the left

Is this the expected behavior? Why does casting operation here interfere
with type inference like this?

Regards,

Justin Dekeyser




 


Garanti
sans virus. www.avast.com
 


<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Type inference: bug or feature?

[Maurizio Cimadamore]

CC'ing compiler-dev

Hi Justin,
the behavior you are observing is normal. For a Java expression to be 
able to be influenced by type inference it has to be a poly expression 
(where poly stands for _many_ as in, the same expression can have many 
types).


At the time we did Java 8 we briefly considered making cast expressions 
part of the poly expression dance (like lambdas, method references, 
method calls, parens, new creation expression, conditionals and switch 
expression - see JLS 15.2), but the rule which dictate cast conversion 
(JLS 5.5) are so complex (as they have to take into account possibility 
for unchecked cast, etc.) that it felt like touching them was a very 
risky move, with no clear benefit.


The behavior you see is caused by the fact that the cast expression acts 
as a "shield" - that is, whenever a method call appears after a cast 
expression (as in your case), the method call is type-checked as if it 
were in isolation, and _then_ the result of type checking is validated 
against the cast. In other words, your example is no different than doing:


var x = (List)(Object)emptyList(Number.class);


That is, the emptyList call will see no meaningful target type (just 
Object), so Number will be inferred and a List will be returned, 
which will then be incompatible with the type of the cast expression 
(List).


Your second set of examples, since it does not make use of cast 
expressions, works as expected, as the target type can freely flow 
inside the method call typing, and thus influence the type inference 
result (e.g. the inference engine now sees two constraints, for Integer 
and for Number, and is of course able to pick the "best" one).


Hope this helps.

Cheers
Maurizio

On 26/07/2020 18:22, Justin Dekeyser wrote:

Dear all,

I'm not sure but I think I've found a bug in Java type inference mechanism.
It may also be a feature, so I'll expose the problem to you below; in terms
of Integer, Number and List, although you'll quickly realize it will work
wrong in any similar situation.

Let's assume I have

static  List emptyList(Class magnet) {
return Collections.emptyList();
}

Then the following codes does not compile (for the same reason):

var x = (List) emptyList(Number.class);
List x = (List) emptyList(Number.class);

incompatible types: List cannot be converted to List

however, the following do compile:

var x = emptyList(Number.class); // inferred to List
List x = emptyList(Number.class); // no mistake here, it's Integer
on the left

Is this the expected behavior? Why does casting operation here interfere
with type inference like this?

Regards,

Justin Dekeyser





Garanti
sans virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

[PATCH] Use byte[] instead of char[] in Integer.digits

[Сергей Цыпанов]

Hello, I'd like to contribute this trivial patch to JDK.

The idea behind it is that with compact strings we don't need char[] when all 
symbols are ASCII.

This allows to slightly reduce footprint of java.lang.Integer.class and drop 
casts from char to byte.

I've measured performance of patched code using Integer/Long.toString() and 
toHexString() methods for short and long values
and the patch is likely to improve it slightly, at least for Long:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g", "-XX:+UseParallelGC"})
public class IntegerToString {
  @Benchmark
  public String integerToHexString(Data data) { return 
Integer.toHexString(data.value); }

  @Benchmark
  public String integerToString(Data data) { return 
Integer.toString(data.value); }

  @State(Scope.Thread)
  public static class Data {
@Param({"0", "2147483647"}) private int value;
  }
}


Gives

Benchmark   (value)  Mode  Cnt   Score   
Error  Units
IntegerToString.integerToHexString0  avgt   50   7.833 ± 
0.172  ns/op
IntegerToString.integerToString   0  avgt   50   7.550 ± 
0.070  ns/op
IntegerToString.integerToHexString   2147483647  avgt   50  13.200 ± 
0.268  ns/op
IntegerToString.integerToString  2147483647  avgt   50  17.028 ± 
0.572  ns/op

after

Benchmark   (value)  Mode  Cnt   Score   
Error  Units
IntegerToString.integerToHexString0  avgt   50   7.771 ± 
0.410  ns/op
IntegerToString.integerToString   0  avgt   50   7.779 ± 
0.321  ns/op
IntegerToString.integerToHexString   2147483647  avgt   50  13.193 ± 
0.450  ns/op
IntegerToString.integerToString  2147483647  avgt   50  16.641 ± 
0.332  ns/op

As of Long the corresponding benchmark

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g", "-XX:+UseParallelGC"})
public class LongToString {
  @Benchmark
  public String longToHexString(Data data) { return 
Long.toHexString(data.longValue); }

  @Benchmark
  public String longToString(Data data) { return Long.toString(data.longValue); 
}

  @State(Scope.Thread)
  public static class Data {
@Param({"0", "9223372036854775807"}) private long longValue;
  }
}


gives

before

LongToString.longToHexString  0  avgt   50   7.711 ± 
0.303  ns/op
LongToString.longToString 0  avgt   50   7.321 ± 
0.439  ns/op
LongToString.longToHexString9223372036854775807  avgt   50  17.393 ± 
0.515  ns/op
LongToString.longToString   9223372036854775807  avgt   50  30.192 ± 
1.365  ns/op

after

LongToString.longToHexString  0  avgt   50   7.796 ± 
0.250  ns/op
LongToString.longToString 0  avgt   50   6.497 ± 
0.015  ns/op
LongToString.longToHexString9223372036854775807  avgt   50  17.720 ± 
0.914  ns/op
LongToString.longToString   9223372036854775807  avgt   50  27.089 ± 
0.232  ns/op

Also I've included into that patch trivial change for Integer.IntegerCache 
where we can use local variable size
instead of c.length where c is array. This is likely to slightly improve 
startup time as this code is executed at class
loading time and likely to be executed in interpreter mode rather than 
beingcompiled by optimizing compiler.

Regards,
Sergey Tsypanovdiff --git a/src/java.base/share/classes/java/lang/Integer.java b/src/java.base/share/classes/java/lang/Integer.java
--- a/src/java.base/share/classes/java/lang/Integer.java
+++ b/src/java.base/share/classes/java/lang/Integer.java
@@ -87,7 +87,7 @@
 /**
  * All possible chars for representing a number as a String
  */
-static final char[] digits = {
+static final byte[] digits = {
 '0' , '1' , '2' , '3' , '4' , '5' ,
 '6' , '7' , '8' , '9' , 'a' , 'b' ,
 'c' , 'd' , 'e' , 'f' , 'g' , 'h' ,
@@ -159,10 +159,10 @@
 }
 
 while (i <= -radix) {
-buf[charPos--] = (byte)digits[-(i % radix)];
+buf[charPos--] = digits[-(i % radix)];
 i = i / radix;
 }
-buf[charPos] = (byte)digits[-i];
+buf[charPos] = digits[-i];
 
 if (negative) {
 buf[--charPos] = '-';
@@ -371,7 +371,7 @@
 int radix = 1 << shift;
 int mask = radix - 1;
 do {
-buf[--charPos] = (byte)Integer.digits[val & mask];
+buf[--charPos] = Integer.digits[val & mask];
 val >>>= shift;
 } while (charPos > 0);
 }
@@ -1030,7 +1030,7 @@
 if (archivedCache == null || size > archivedCache.length) {
 Integer[] c = new Integer[size];
 int j = low;
-for(int i = 0; i < c.length; i++) {
+for(int i = 0; i 

Re: Type inference: bug or feature?

[Justin Dekeyser]

Hello,

Again, thanks for the prompt response!

Well, I'm not really sure about the answer but, to my understanding, if
this:
List x = emptyList(Number.class);
compiles correctly (thus U inferred as Number, V inferred as Integer as
expected),
then why this
List x = (List) emptyList(Number.class);
does not compile ? (with explicit or var-typing)

On the other hand, the following code
var x = (Function) x -> x;
compile with no error, hence in this case, casting does help in type
inference.

I really feel that, although a bit "over complicated", there is something
that I either really don't get, or something else :/

Regards,

Justin Dekeyser



On Mon, Jul 27, 2020 at 10:21 AM Florian Weimer  wrote:

> * Justin Dekeyser:
>
> > Nevertheless, the point was not really about list stuffs, and is not
> > related to the lack of co/contra variance.
>
> > You may replace List with any other generic class Foo and Integer
> > and Number with any other class satisfying the same inheritance
> > relations.
>
> Ahh, well, but why are such casts useful?  The results will be wrong in
> pretty much every case.  Their correctness cannot be checked at run
> time, either.
>
> Thanks,
> Florian
>
>

Re: Type inference: bug or feature?

[Florian Weimer]

* Justin Dekeyser:

> Nevertheless, the point was not really about list stuffs, and is not
> related to the lack of co/contra variance.

> You may replace List with any other generic class Foo and Integer
> and Number with any other class satisfying the same inheritance
> relations.

Ahh, well, but why are such casts useful?  The results will be wrong in
pretty much every case.  Their correctness cannot be checked at run
time, either.

Thanks,
Florian

Re: Type inference: bug or feature?

[Justin Dekeyser]

Hello,

Thanks for the answer.

Nevertheless, the point was not really about list stuffs, and is not
related to the lack of co/contra variance.
You may replace List with any other generic class  Foo and Integer and
Number with any other class satisfying the same inheritance relations.

The behavior is really about casting, which prevents type inference to work
"as one would expect".
This is even weirder because, in case of lambda expressions, casting does
help in desambiguising the type.

So on the one side, we have a casting operation that helps in type
inference,
on the other side, we have a casting operation that prevents some inference.

I'm really not sure this is no bug :/

Regards,

Justin Dekeyser



On Mon, Jul 27, 2020 at 9:43 AM Florian Weimer  wrote:

> * Justin Dekeyser:
>
> > Then the following codes does not compile (for the same reason):
> >
> > var x = (List) emptyList(Number.class);
> > List x = (List) emptyList(Number.class);
> >
> > incompatible types: List cannot be converted to List
> >
> > however, the following do compile:
> >
> > var x = emptyList(Number.class); // inferred to List
> > List x = emptyList(Number.class); // no mistake here, it's
> Integer
> > on the left
> >
> > Is this the expected behavior? Why does casting operation here interfere
> > with type inference like this?
>
> emptyList() is special, it only works this way because the returned list
> is always empty, so that the element type does not matter.  For any
> other list-returning function, the types List and List
> are not interchangeable because for each type, there are operations
> which are not valid for the other.  That's why we often need wildcards
> once type hierarchies are involved (List or
> List, depending on context).
>
> A somewhat similar case is functions which do not return (normally).
> They too can have a very general generic type which does not depend on
> function arguments.
>
> Thanks,
> Florian
>
>

Re: Type inference: bug or feature?

[Florian Weimer]

* Justin Dekeyser:

> Then the following codes does not compile (for the same reason):
>
> var x = (List) emptyList(Number.class);
> List x = (List) emptyList(Number.class);
>
> incompatible types: List cannot be converted to List
>
> however, the following do compile:
>
> var x = emptyList(Number.class); // inferred to List
> List x = emptyList(Number.class); // no mistake here, it's Integer
> on the left
>
> Is this the expected behavior? Why does casting operation here interfere
> with type inference like this?

emptyList() is special, it only works this way because the returned list
is always empty, so that the element type does not matter.  For any
other list-returning function, the types List and List
are not interchangeable because for each type, there are operations
which are not valid for the other.  That's why we often need wildcards
once type hierarchies are involved (List or
List, depending on context).

A somewhat similar case is functions which do not return (normally).
They too can have a very general generic type which does not depend on
function arguments.

Thanks,
Florian