JDK 11 RFR of JDK-8202563: BigInteger/BigDecimal not immune to overflow, contrary to spec

Hello, Over in BigInteger, 2^Integer.MAX_VALUE just isn't as effectively infinite as it used to be. Please review the spec changes and CSR below to clarify that the range of BigInteger is "arbitrarily large" but not "infinite":     JDK-8202563: BigInteger/BigDecimal not immune to overflow,

Re: Update to the Double::toString(double) Javadoc

Hello Raffaello, On 4/27/2018 7:39 AM, raffaello.giulie...@gmail.com wrote: Hi, as may be known, the current Javadoc for Double::toString(double) is not specific enough. As a consequence, different implementations can return different results. To see this, here are some quotes from the

Initial JDK 11 RFR of JDK-8202385: Annotation to mark serial-related fields and methods

Hello, Please review the webrev (code below) to address     JDK-8202385: Annotation to mark serial-related fields and methods     http://cr.openjdk.java.net/~darcy/8202385.0/ The proposed java.io.Serial annotation type is intended to be used along with an augmented implementation of javac's

Re: Initial JDK 11 RFR of JDK-8202385: Annotation to mark serial-related fields and methods

extends  * {@code Serializable}, those three methods are not used for  * externalizable classes. How does that sound? Thanks, -Joe On 5/10/2018 1:22 PM, joe darcy wrote: Hi Roger, Right; there are a few other distinguished methods defined for externalization, but they are defined

Re: Initial JDK 11 RFR of JDK-8202385: Annotation to mark serial-related fields and methods

Hi David, On 5/10/2018 1:39 PM, David Lloyd wrote: Would it be allowed to enable the serial lint without using the @Serial annotation? Certainly. A limited serial lint checker already exists in javac and we enable that check it in the JDK build. Basically it checks that a serializable

Re: Initial JDK 11 RFR of JDK-8202385: Annotation to mark serial-related fields and methods

e. Thanks, Roger On 5/10/2018 11:55 AM, joe darcy wrote: Hello, Please review the webrev (code below) to address     JDK-8202385: Annotation to mark serial-related fields and methods     http://cr.openjdk.java.net/~darcy/8202385.0/ The proposed java.io.Serial annotation type is intended to be u

Re: JDK 11 RFR of JDK-8202563: BigInteger/BigDecimal not immune to overflow, contrary to spec

;>}) is omitted since this operation only makes sense for a fixed sized word and not for a representation conceptually having an infinite number of leading virtual sign bits. -Joe On Mon, May 7, 2018 at 9:47 PM, joe darcy <joe.da...@oracle.com <mailto:joe.da...@oracle.com>>

Re: RFR: jsr166 jdk integration 2018-05

Hi John, On 5/19/2018 3:54 PM, John Rose wrote: On May 19, 2018, at 9:42 AM, Martin Buchholz wrote: I like thinking of ArrayList as just an optimized HashMap, Lua-style, and HashMap.replaceAll also does not increment modCount, supporting our "structural modification"

Re: RFR JDK-8200172,String.split non-positive term incorrect use

Hello, I think some larger re-wording is in order. Here is one of the proposed new paragraphs: 2181  * The {@code limit} parameter controls the number of times the 2182  * pattern is applied and therefore affects the length of the resulting 2183  * array.  If the limit n is

Re: RFR: jsr166 jdk integration 2018-05

Hello, On 5/17/2018 8:51 PM, Stuart Marks wrote: I owe all of you replies on this, but I don't have time to continue the discussion, and I suspect you all want to get on with things. Let me have a quick chat with Paul tomorrow and then I'll propose a path forward. I've spoken about this

Re: Review Request: 8204648: test/jdk/tools/launchers/SourceMode.java fails with long shebang line

Skipping the shebang tests is fine a workaround Mandy; thanks, -Joe On 6/8/2018 9:57 PM, mandy chung wrote: I run into some issue with shebang tests.  Since Jon is on vacation, I revise the patch to skip the shebang test temporarily until he returns. Mandy diff --git

Re: [core-libs] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control

Hi David, On 5/24/2018 10:52 PM, David Holmes wrote: Here are the further minor updates so far in response to all the review comments. Incremental corelibs webrev: http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.corelibs.v3-incr/ Full corelibs webrev:

JDK 11 RFR of JDK-8205003: Replace selected link tags with linkplain in java.lang.Class

Hello, Please review the small patch below to address     JDK-8205003: Replace selected link tags with linkplain in java.lang.Class Thanks, -Joe diff -r 0742a087710e src/java.base/share/classes/java/lang/Class.java --- a/src/java.base/share/classes/java/lang/Class.java    Wed Jun 13

Re: RFR: jsr166 integration 2018-06

On 6/22/2018 10:51 AM, Martin Buchholz wrote: On Fri, Jun 22, 2018 at 10:28 AM, Paul Sandoz wrote: --- We've been unable to reach agreement on 8203662 - it remains in limbo. 8203662: remove increment of modCount from ArrayList and Vector replaceAll()

JDK 10 RFR of JDK-8189952: New methods on String: chars() and codePoints() should be marked since 9

Hello, The initial changeset which introduced these the methods String.chars() and String.codePoints(), JDK-8071477 , had the expected @since tags for the time (@since 1.9), but subsequent changes to String seem to have removed them. Please review the patch below to add them back. Thanks,

Re: JDK 15 RFR of JDK-8225540: In core reflection note whether returned annotations are declaration or type annotations

Hi Pavel, On 4/9/2020 3:46 AM, Pavel Rappo wrote: http://cr.openjdk.java.net/~darcy/8225540.1/ I'm not an expert in this area, but AFAIK this looks good. A couple of nits. 1. The newly added text in the top-level doc comment for AnnotatedElement is missing some tags. It looks nice in

Re: Some Classes with a public void close() don't implement AutoCloseable

Hi Johannes, FYI, back during Project Coin during JDK 7, there were various systematic efforts to review types with a "close" method in the JDK and retrofit AutoCloseable where appropriate:     JDK-6911261: Project Coin: Retrofit Automatic Resource Management (ARM) support onto platform

Re: RFR [15] 8242230: Whitespace typos, relaxed javadoc, formatting

Hi Pavel, Looks fine in general, assuming the change to Class.java renders correctly in output. Thanks, -Joe On 4/7/2020 8:28 AM, Pavel Rappo wrote: Hi Ivan, On 7 Apr 2020, at 09:11, Ivan Gerasimov wrote: Hi Pavel! A couple of comments. 1) java/util/logging/Formatter.java This has

Re: RFR [15] 8242230: Whitespace typos, relaxed javadoc, formatting

necessary at the time to get (almost) the desired effect. Thanks, -Joe On 7 Apr 2020, at 20:23, Joe Darcy wrote: Hi Pavel, Looks fine in general, assuming the change to Class.java renders correctly in output. Thanks, -Joe On 4/7/2020 8:28 AM, Pavel Rappo wrote: Hi Ivan, On 7 Apr 2

JDK 15 RFR of JDK-8225540: In core reflection note whether returned annotations are declaration or type annotations

Hello, Please review the changes to fix     JDK-8225540: In core reflection note whether returned annotations are declaration or type annotations     http://cr.openjdk.java.net/~darcy/8225540.1/ This is a sibling fix to JDK-8225495 already done over in javax.lang.model. In brief, the

Re: [15] RFR: 8214694: cleanup rawtypes warnings in open jndi tests

Hi Chris, The changes don't appear incorrect, but at least from a cursory inspection, they don't appear as precise as they could be. Usually generifying a classes like this will next yield a round of redundant "cast" warnings; in my cleanup efforts, getting cast warnings was usually a sign

JDK 15 RFR of JDK-8241789: Make citations of JLS and JVMS consistent in java.lang.Class

Hello, As noticed during the CSR review of JDK-8238359, not all the citations of JVMS and JLS are done consistently in java.lang.Class. These citations should be done uniformly.     http://cr.openjdk.java.net/~darcy/8241789.0/ Patch below. The referenced JVMS "table 4.1" had been

JDK 15 RF(pre)R of JDK-8241374: add Math.absExact

Hello, Please review the initial proposed wording of the spec for     JDK-8241374: add Math.absExact The eventual wording needs to be replicated four times (Math.absExact(int), Math.absExact(long), StrictMath.absExact(int), StrictMath.absExact(long)) so I want to get the wording agreed to

Re: [15] RFR: 8214694: cleanup rawtypes warnings in open jndi tests

, thanks. Updated webrev as below http://cr.openjdk.java.net/~xyin/8214694/webrev.01/ Regards, Chris On 27 Mar 2020, at 4:41 AM, Joe Darcy wrote: Hi Chris, The changes don't appear incorrect, but at least from a cursory inspection, they don't appear as precise as they could be. Usually

Re: (XS) Review Request JDK-8241964: Clean up java.lang.Class javadoc

Looks fine Mandy; thanks for doing this cleanup, -Joe On 3/31/2020 4:15 PM, Mandy Chung wrote:  This patch cleans up the javadoc in java.lang.Class and replaces "this object" and "this class object" with "this {@code Class} object" Webrev at:

Re: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact

verbose, implementation. Thanks for the suggestion, -Joe With best regards, Tagir Valeev. On Tue, Mar 31, 2020 at 12:54 AM Joe Darcy wrote: Hello, Updated webrev at: http://cr.openjdk.java.net/~darcy/8241374.1/ One of the four pieces of the update to discuss below. A few comments, I a

Re: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact

Hi Stuart, Full webrev for review include including tests:     http://cr.openjdk.java.net/~darcy/8241374.0/ and the companion CSR:     https://bugs.openjdk.java.net/browse/JDK-8241805 Replies interspersed below. On 3/28/2020 7:37 PM, Stuart Marks wrote: Hi Joe, Overall this looks quite

Re: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact

Hi Brian and Chris, I was considering adding such as JLS link myself; I'll work one in and post a revised webrev. Thanks, -Joe On 3/30/2020 9:29 AM, Brian Burkhalter wrote: Hi Joe, On Mar 30, 2020, at 6:31 AM, Chris Hegarty > wrote: Full webrev for

Re: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact

equivalent, as the other fooExact StrictMath methods do. Thanks, -Joe On 3/30/2020 9:31 AM, Joe Darcy wrote: Hi Brian and Chris, I was considering adding such as JLS link myself; I'll work one in and post a revised webrev. Thanks, -Joe On 3/30/2020 9:29 AM, Brian Burkhalter wrote: Hi Joe,

Re: Some Classes with a public void close() don't implement AutoCloseable

be     AutoCloseable? I'm sure Joe Darcy can say more on this but I remember there was a lot of effort put into this topic when AutoCloseable was added in Java 7 (and Project Coin). Closeable close is idempotent but AutoCloseable close could not require it. AutoCloseable's API docs recommend it of course

Re: RFR 8214761 : Bug in parallel Kahan summation implementation

Hello, Thanks for the nudge; I'll get to this sometime after the Skara transition for jdk/jdk. Cheers, -Joe On 9/3/2020 9:29 AM, Chris Dennis wrote: In case there is a need for extra motivation here: import java.util.stream.DoubleStream; public class Test8214761 { public static void

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic)

Hello, I also suggest taking a look at the existing regression tests in     test/jdk/java/lang/Long/Unsigned.java to see if more cases should be added with the new algorithm. Potentially, the existing algorithm could retire to serve as a reference in the regression tests. Thanks, -Joe On

Re: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode

Note that we've had the javac warning about equals and hashCode overriding as a fatal build condition since at least JDK 9. -Joe On 9/15/2020 12:36 PM, Brian Burkhalter wrote: Hello, The override of hashCode() looks like it is still there in JDK 15 [1]. I don’t know however why it does not

Re: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance)

Hi Lance, I'd prefer to err on the side of having a CSR; thanks, -Joe On 9/14/2020 3:55 PM, Lance Andersen wrote: Hi Joe, I guess it could.  Given it is not used within the implementation(or defined outside of the spec), I will defer to you preference  :-) On Sep 14, 2020, at 6:49 PM, Joe

Re: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance)

Should issue have a CSR review for the behavior change? -Joe On 9/12/2020 7:25 PM, Jaikiran Pai wrote: On Sat, 12 Sep 2020 17:38:34 GMT, Lance Andersen wrote: Can I please get a review and a sponsor for this patch which fixes the issue reported in

Re: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types

On Tue, 8 Sep 2020 22:32:47 GMT, Stuart Marks wrote: > Add some generics and wrap in `{@code}` to protect angle brackets. Marked as reviewed by darcy (Reviewer). Looks fine. - PR: https://git.openjdk.java.net/jdk/pull/87

Re: RFR: 8253066: typo in Stream.mapMulti

On Fri, 11 Sep 2020 22:20:48 GMT, Stuart Marks wrote: > A simple typo fix. Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/137

Re: RFR: 8255020: Minor updates to docs jdk.incubator.vector

On Mon, 19 Oct 2020 18:41:31 GMT, Paul Sandoz wrote: > Minor updates, with no specification changes, to the documentation of Vector > API. > > The compilation of the Vector module was updated to turn on doclint errors > for >= protected documentation. Marked as reviewed by darcy (Reviewer).

Re: RFR: JDK-8246804: Incorrect copyright header in TypeAnnotationParser.java

+1 -Joe On 8/17/2020 1:01 PM, Vicente Romero wrote: Please review this very simple fix for [1] at [2]. The fix is a very simple one liner change, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8246804 [2] http://cr.openjdk.java.net/~vromero/8246804/webrev.00/

Re: RFR: 8246774: Record Classes (final) implementation

On Mon, 21 Sep 2020 21:36:39 GMT, Vicente Romero wrote: >> Co-authored-by: Vicente Romero >> Co-authored-by: Harold Seigel >> Co-authored-by: Jonathan Gibbons >> Co-authored-by: Brian Goetz >> Co-authored-by: Maurizio Cimadamore >> Co-authored-by: Joe Dar

Re: Math.exp() yields different results on 32 bit systems

Hello, Per the spec https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Math.html#exp(double) the result of exp has to be within one ulp of the exact result and the value of e^(10_000) is (much) larger than Double.MAX_VALUE so positive infinity is the correct answer.

Re: contributing to JDK-8171407: Port fdlibm to Java, part 2

Hi Raffaello, Finishing the fdlibm port remains on my to-do list. Given the review investment needed, I would not find it helpful for someone else to contribute a port. Thanks, -Joe On 5/25/2020 9:24 AM, Raffaello Giulietti wrote: Hi, [1] enumerates 14 StrictMath native functions that

Re: RFR: 8255022: Documentation missing for Vector API zero methods [v2]

On Wed, 21 Oct 2020 20:31:24 GMT, Paul Sandoz wrote: >> The zero methods on `IntVector` and all other specializations are missing >> documentation. > > Paul Sandoz has updated the pull request incrementally with one additional > commit since the last revision: > > Address CSR review.

Re: RFR: 8249612 Remove unused ISNANF and ISNAND from jdk_util_md.h

Looks fine (when needed, there are equivalents of those in the Java math library); thanks, -Joe On 7/16/2020 8:50 AM, Mikael Vidstedt wrote: Nice find! :) Cheers, Mikael On Jul 16, 2020, at 6:34 AM, Alexander Scherbatiy wrote: Hello, Could you review a simple clean up of jdk_util_md.h

Re: JDK 16 RFR of JDK-8250660: Clarify that WildcardType and AnnotatedWildcardType bounds methods return one

be deprecated (for removal) and replaced by a singular counterpart that returns a single Type rather than a Type[]. Cheers, David - On 1/08/2020 8:12 am, Joe Darcy wrote: Hello, Please review the doc clarification below to address 8250660: Clarify that WildcardType and AnnotatedWildcardType b

Re: JDK 16 RFR of JDK-8250660: Clarify that WildcardType and AnnotatedWildcardType bounds methods return one

Hi David, On 8/3/2020 4:42 PM, David Holmes wrote: Hi Joe, On 4/08/2020 2:24 am, Joe Darcy wrote: Hi David, To provide a bit more context, the API was consciously designed to be future-proofed against the possibility of Java supporting multiple bounds here (JDK-4891872). As of yet

JDK 16 RFR of JDK-8250920: Increase @jls usage in core reflection

Hello, While JDK-8250660: "Clarify that WildcardType and AnnotatedWildcardType bounds methods return one" is still under discussion, please review a change for     JDK-8250920: Increase @jls usage in core reflection     http://cr.openjdk.java.net/~darcy/8250920.0/ which adds @jls tags for

JDK 16 RFR of JDK-5017980: Allow signed positive integer to be parsed instead of a NumerFormatException

Hello, Please review the patch below and CSR for     JDK-8249273: Documentation of BigInteger(String) constructor does not mention leading plus     CSR: https://bugs.openjdk.java.net/browse/JDK-8251235 The fix for JDK-5017980 way back in JDK 7 omitted the spec update to one of the two

Re: 8245304: Re-examine ThreadLocal usage in java.math.BigDecimal

Looks fine; thanks, -Joe On 8/11/2020 10:32 AM, Brian Burkhalter wrote: To fix [1], please consider [2] which replaces the ThreadLocal “threadLocalStringBuilderHelper” with straightforward use of a StringBuilderHelper instance. The initial capacity of the StringBuilder instance variable of

JDK 16 RFR of JDK-8250660: Clarify that WildcardType and AnnotatedWildcardType bounds methods return one

Hello, Please review the doc clarification below to address     8250660: Clarify that WildcardType and AnnotatedWildcardType bounds methods return one Thanks, -Joe diff -r b0553ba43ba1 src/java.base/share/classes/java/lang/reflect/AnnotatedWildcardType.java ---

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

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

Re: JDK 16 RFR of JDK-8250660: Clarify that WildcardType and AnnotatedWildcardType bounds methods return one

:24 AM, Joe Darcy wrote: Hi David, To provide a bit more context, the API was consciously designed to be future-proofed against the possibility of Java supporting multiple bounds here (JDK-4891872). As of yet, that change has not come to pass, and as you note may never come to pass. So besides

Re: Fix for Javadoc errors in java.base

ail> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> On Tue, Jul 28, 2020 at 5:53 AM Joe Darcy <mailto:joe.da...@oracle.com>> wrote: Hello Vipin, What tooling was used to find these er

Re: RFR(S): 8249198: Faster Math.signum(fp) for positive and negative numbers

Hello, The comment +    // NaN is here by JLS 15.20.1 is not correct; either NaN or (signed) zero is present at that point in the code. -Joe On 7/10/2020 11:11 AM, Dmitry Chuyko wrote: Hello, Please review a small change in Math.signum(double d) and Math.signum(float f) that

Re: RFR(S): 8249198: Faster Math.signum(fp) for positive and negative numbers

to review the benchmarks. Thanks, -Joe -Dmitry On 7/10/20 10:06 PM, Joe Darcy wrote: Hello, The comment +    // NaN is here by JLS 15.20.1 is not correct; either NaN or (signed) zero is present at that point in the code. -Joe On 7/10/2020 11:11 AM, Dmitry Chuyko wrote: Hello, Please revi

Re: RFR: 8247782: typos in java.math

Looks good Martin; thanks for fixing, -Joe On 6/17/2020 11:44 AM, Martin Buchholz wrote: 8247782: typos in java.math https://cr.openjdk.java.net/~martin/webrevs/jdk/math-spelling/ https://bugs.openjdk.java.net/browse/JDK-8247782

Re: RFR [15,docs] JDK-8247880,bad HTML(href==...) in table

+1 -Joe On 6/18/2020 3:37 PM, Jonathan Gibbons wrote: Please review a trivial docs fix for some invalid HTML in jdk.zipfs/module-info.java. In two places, 'href==' is reduced to 'href=' -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8247880 Patch inline diff -r cf0df75c75c1

Re: RFR: [15,docs] JDK-8247894,Invalid @see in java.management

+1 -Joe On 6/18/2020 4:00 PM, Jonathan Gibbons wrote: Please review a trivial fix for an invalid @see tag in java/lang/management/package.html. The presumed intent of the original is not a supported variant. The fix is to remove the `{@linkplain ...}` wrapper. -- Jon JBS:

Re: Exceptions priority in InputStream.read(byte[], int, int)

Hello, As a general comment, over time we come to regard specifications like "if these three pre-conditions of the method are all violated, this exception will be thrown; if only these two pre-conditions are violated, this other exception will be thrown" as over specifications and best

RFR of JDK-8245620: Improve Annotation.annotationType() documentation

Hello, Please review a number of small updates to the javadoc of java.lang.annotation.Annotation to address     JDK-8245620: Improve Annotation.annotationType() documentation The use of  Annotation.annotationType() vs calling getClass on an annotation object may not be clear so the method's

Re: RFR of JDK-8245620: Improve Annotation.annotationType() documentation

Hi Pavel, On 6/11/2020 2:54 AM, Pavel Rappo wrote: Joe, There is a typo: *appropriate overloading of {@link java.util.Arrays#equals Arrays.hashCode}. ^ ~~~^ Since we are in this area, is it possible to rephrase (or at least

JDK 16 RFR of JDK-8250578: Address reliance on default constructors in javax.sql

Hello, Another module, another use of a default constructor. Please review the fix and CSR for:     JDK-8250578: Address reliance on default constructors in javax.sql     CSR: https://bugs.openjdk.java.net/browse/JDK-8250579     http://cr.openjdk.java.net/~darcy/8250578.0/ Patch below.

JDK 16 RFR of 8250580: Address reliance on default constructors in java.rmi

Hello, Another bug in the quest to remove use of default constructors in the JDK's public API, this time in the java.rmi module:     webrev: http://cr.openjdk.java.nhet/~darcy/8250580.0/     CSR: https://bugs.openjdk.java.net/browse/JDK-8250581 Patch below; thanks, -Joe ---

JDK 16 RFR of JDK-8249687: Use inline @jls and @jvm tages in more places in java.base

Hello, Following-up on  JDK-8237805 and some recent observations from Mikael V., there are more locations in the base module where in-line @jls and @jvms tags are appropriate to use. Please review their addition:     http://cr.openjdk.java.net/~darcy/8249687.0/ I checked that the sections

Re: Fix for Javadoc errors in java.base

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

Re: JDK 16 RFR of JDK-8250240: Address use of default constructors in the java.util.concurrent

Hi Martin, On 7/23/2020 5:24 PM, Martin Buchholz wrote: So these are all abstract classes where the constructor can only be called via super() ? Yep. In which case one would expect the constructors to be protected, not public. But I'm probably missing some reason why "protected" would not

JDK 16 RFR of JDK-8250221: Address use of default constructors in java.logging

Hello, Please review the changes for     JDK-8250221: Address use of default constructors in java.logging     webrev: http://cr.openjdk.java.net/~darcy/8250221.0/     CSR: https://bugs.openjdk.java.net/browse/JDK-8250223 This is part of a larger effort to remove reliance of default

JDK 16 RFR of JDK-8250240: Address use of default constructors in the java.util.concurrent

Hello, Martin, how would you prefer these changes, or equivalent ones, to get into the java.util.concurrent upstream sources? Several classes in java.util.concurrent rely on default constructors, which is not recommended.  Please review the patch below which removes them along with the

Re: JDK 16 RFR of JDK-8250240: Address use of default constructors in the java.util.concurrent

otected" is used. On Thu, Jul 23, 2020 at 5:43 PM Joe Darcy wrote:

JDK 16 RFR of JDK-8250237: Address use of default constructors in the javax.script package

Hello, One class in the javax.script package uses a default constructor; please review the patch below and CSR (https://bugs.openjdk.java.net/browse/JDK-8250239) to replace it with an explicit constructor. Thanks, -Joe diff -r d62da6fc4074

Re: RFR JDK-8022795: Method.isVarargs of dynamic proxy generated method to match the proxy interface method

Hi Mandy, The behavior change looks okay; please file a CSR for this too. Thanks, -Joe On 7/22/2020 12:04 PM, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8022795/webrev.00/ A small improvement to the dynamic proxy generated method to have ACC_VARARGS matching

Re: RFR [16/java.xml] 8250638: Address reliance on default constructors in java.xml

Look fine Joe; thanks, -Joe On 7/30/2020 9:20 AM, Joe Wang wrote: Hello, Please review a change to remove reliance of default constructors in java.xml. JBS: https://bugs.openjdk.java.net/browse/JDK-8250638 CSR: https://bugs.openjdk.java.net/browse/JDK-8250800 Patch: diff --git

Re: RFR: 8159746: (proxy) Support for default methods [v7]

On Wed, 25 Nov 2020 22:24:40 GMT, Mandy Chung wrote: >> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke >> the given default method on the given proxy instance. >> >> The implementation looks up a method handle for `invokespecial` instruction >> as if called from with

Re: RFR: 8257450: Start of release updates for JDK 17 [v2]

> Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Me

Re: RFR: 8257450: Start of release updates for JDK 17 [v2]

On Mon, 7 Dec 2020 16:10:42 GMT, Jan Lahoda wrote: > > > The langtools changes look fine to me. There were additions/changes to jcod > files under `test/hotspot/jtreg/runtime/sealedClasses/` made under > JDK-8246778, so these may need an update. Sorry about that. After a merge, the tests in

Re: RFR: 8255560: Class::isRecord should check that the current class is final and not abstract [v4]

On Wed, 2 Dec 2020 10:00:21 GMT, Chris Hegarty wrote: >> Update Class::isRecord to only return true for classes that are final. >> >> The removal of non-specified JVM checks on classes with a Record Attribute >> (see JDK-8255342), has resulted in more types of loadable classes that may >>

RFR: 8257450: Start of release updates for JDK 17

Start of JDK 17 updates. - Commit messages: - Update tests. - Merge branch 'master' into JDK-8257450 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 - JDK-8257450 -

Re: RFR: 8257450: Start of release updates for JDK 17

On Tue, 1 Dec 2020 07:33:25 GMT, David Holmes wrote: >> Start of JDK 17 updates. > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 226: > >> 224: REIFIABLE_TYPES_INSTANCEOF(JDK16, >> Fragments.FeatureReifiableTypesInstanceof, DiagKind.PLURAL), >> 225:

Re: RFR: 8257450: Start of release updates for JDK 17

On Tue, 1 Dec 2020 07:38:13 GMT, David Holmes wrote: >> Start of JDK 17 updates. > > Looks good - 99% sym stuff :) > > Doesn't look like the hotspot deprecated flag test will need updating this > time, as no newly deprecated flags marked for obsoletion in 17. Usual start of release update: *

Re: RFR: 8251989: Hex formatting and parsing utility [v17]

On Wed, 2 Dec 2020 16:33:15 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, >> prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with >> modified

Re: RFR: 8251989: Hex formatting and parsing utility [v17]

On Wed, 2 Dec 2020 16:33:15 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, >> prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with >> modified

Re: RFR: 8257450: Start of release updates for JDK 17 [v3]

> Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Merge bra

Re: RFR: 8257450: Start of release updates for JDK 17 [v2]

On Mon, 7 Dec 2020 20:20:58 GMT, Jesper Wilhelmsson wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contain

Re: RFR: 8251989: Hex formatting and parsing utility [v17]

On Fri, 4 Dec 2020 22:13:21 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/util/HexFormat.java line 936: >> >>> 934: * if any of the characters is not a hexadecimal character >>> 935: */ >>> 936: public int fromHexDigits(CharSequence string) { >> >> I recommend

Re: RFR: 8257450: Start of release updates for JDK 17 [v4]

> Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge bra

RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and ==

Updates to the specifications of Double.{equals, compareTo} to explain more explicitly why the obvious wrappers around "==" and "<"/"==" are not sufficient for floating-point values. Once the wording is worked out, I'll replicate it for the analogous methods on Float. - Commit

Re: RFR: 8257450: Start of release updates for JDK 17 [v5]

> Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge bra

Re: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and ==

On Tue, 8 Dec 2020 17:59:41 GMT, Stuart Marks wrote: >> Updates to the specifications of Double.{equals, compareTo} to explain more >> explicitly why the obvious wrappers around "==" and "<"/"==" are not >> sufficient for floating-point values. >> >> Once the wording is worked out, I'll

Re: RFR: 8257450: Start of release updates for JDK 17 [v6]

> Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: - Get in JEP

Re: RFR: 8257845: Integrate JEP 390

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - [JDK-8252180](https://bugs.openjdk.java.net/browse/JDK-8252180): Deprecate > wrapper

Re: RFR: 8257450: Start of release updates for JDK 17 [v2]

On Mon, 7 Dec 2020 20:08:59 GMT, Jonathan Gibbons wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains eight

Re: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended

On Mon, 7 Dec 2020 19:51:38 GMT, Harold Seigel wrote: > Please review this fix for JDK-8256867. This change no longer throws a > ClassFormatError exception when loading a class whose PermittedSubclasses > attribute is empty (contains no classes). Instead, the class is treated as a > sealed

Re: RFR: 8257450: Start of release updates for JDK 17 [v8]

> Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: - Merge bra

Re: RFR: 8257450: Start of release updates for JDK 17 [v7]

> Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - Merge bra

Integrated: 8257450: Start of release updates for JDK 17

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy wrote: > Start of JDK 17 updates. This pull request has now been integrated. Changeset: 6be1f567 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/6be1f567 Stats: 7607 lines in 77 files changed: 7548 ins; 0 del; 59

[jdk16] RFR: 8258140: Update @jls tags in java.base for renamed/renumbered sections

Given upcoming changes in the JLS terminology around the term "type", various sections were renamed: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html The @jls tags in the java.base module which refer to the renamed sections should be updated.

Re: [jdk16] RFR: 8257598: Clarify what component values are used in Record::equals

On Fri, 11 Dec 2020 05:02:25 GMT, Vicente Romero wrote: > Please review this patch which modifies the spec for method > java.lang.Record::equals. It states that the implementation of this method > should use the record fields for the comparison instead of the accessors. > > TIA, > Vicente

Re: RFR: 8257598: Clarify what component values are used in Record::equals

If this is meant for JDK 16, it is easier overall if PR is done against the JDK 16 repo. -Joe On 12/10/2020 6:13 PM, Vicente Romero wrote: Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the

Re: [jdk16] RFR: 8257637: Update usage of "type" terminology in java.lang.annotation

On Tue, 15 Dec 2020 19:28:15 GMT, Julia Boes wrote: > This change is in line with upcoming changes in the JLS terminology ('type' > versus 'class and interface'). > > For background see: > https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html > > For easier

[jdk16] Integrated: 8258140: Update @jls tags in java.base for renamed/renumbered sections

On Sat, 12 Dec 2020 18:40:16 GMT, Joe Darcy wrote: > Given upcoming changes in the JLS terminology around the term "type", various > sections were renamed: > > > https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html > >

  1   2   3   4   5   6   7   8   9   10   >