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 APIs

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

    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

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 sti

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

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 src/jdk

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: https://bugs.openj

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 avoide

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 improves

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

s 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

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 f

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 we

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

s 3.3} of   * The Java Language Specification.   *   * The specified stream remains open after this method returns. On 7/17/2020 3:30 PM, Brian Burkhalter wrote: Hi Joe, +1 Brian On Jul 17, 2020, at 3:03 PM, Joe Darcy <mailto:joe.da...@oracle.com>> wrote: Following-up on  J

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

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 constructor

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 src/java.scripting/share/classes/javax/script/Com

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 corre

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 be

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

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

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. Thank

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 --- old/src/java.rm

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 OCA,

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 a/src/java.

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 --- a/src/java.base/share/class

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 AnnotatedWildcardTy

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, that

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 th

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 in

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 BigInt

Re: Fix for Javadoc errors in java.base

n=sig-email&utm_content=webmail> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> On Tue, Jul 28, 2020 at 5:53 AM Joe Darcy <mailto:joe.da...@oracle.com>> wrote: Hello Vi

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 S

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 time

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: 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: 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 ma

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: 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 https://bugs.openjdk.java.net/browse/JDK-82

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

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 a

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. Theref

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: 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. Marked

Re: RFR: JDK-8255262: Remove use of legacy custom @spec tag

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/814

Re: 8225117: java/math/BigInteger/SymmetricRangeTests.java fails with ParseException

Look fine Brian; cheers, -Joe On 5/31/2019 8:33 AM, Brian Burkhalter wrote: https://bugs.openjdk.java.net/browse/JDK-8225117 For SymmetricRangeTests the @ignore action tag needs to be after @library but before @run. For StringConstructorOve

JDK 13 RFR of JDK-8164819: Make javac's toString() on annotation objects consistent with core reflection

Hello, Please review the webrev of changes for     JDK-8164819: Make javac's toString() on annotation objects consistent with core reflection     http://cr.openjdk.java.net/~darcy/8164819.2/ Some background, several years ago in JDK 9, the toString output of annotations was changed to be usa

JDK 13 RFR of JDK-8225353: Add @jls links to java.lang.Enum

Hello, As noticed by Jon, the text for java.lang.Enum refers to a section of the JLS but does not use @jls tags: "This is the common base class of all Java language enumeration types. More information about enums, including descriptions of the implicitly declared methods synthesized by the c

JDK 13 RFR of JDK-8225465: Add @jls tags to receiver type methods

Hello, Receiver types are an obscure corner of the Java language added as part of type annotations. The API methods in core reflection and javax.lang.model that refer to receiver types should cross-reference the relevant JLS sections using @jls javadoc tags. Please review the patch below to

JDK 13 RFR of JDK-8042748: Clarify exception thrown by ParameterizedTypeImpl.validateConstructorArguments()

Hello, Please review the patch below to address     JDK-8042748: Clarify exception thrown by ParameterizedTypeImpl.validateConstructorArguments() Thanks, -Joe diff -r 0a7af38ef32a src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java --- a/src/java.

JDK 13 RFR of JDK-8181869: getAnnotatedParameterTypes​() specification should be clarified

Hello, Please review the doc clarification below to address     JDK-8181869: getAnnotatedParameterTypes​() specification should be clarified Each of the three flavors of get-parameter-types methods (getParameterTypes, getGenericParameterTypes, getAnnotatedParameterTypes) gets the same discl

Re: RFR 8225322: Broken links in java.sql

+1 -Joe On 6/8/2019 1:36 PM, Lance Andersen wrote: Hi all, Please review this update to the java.sql package javadocs which addresses a broken URL on OTN as the page is no longer being available. — $ !hg hg diff diff -r d22206f24d59 src/java.sql/share/classes/java/sql/package-info.jav

JDK 13 RFR of JDK-708660: (reflect) Clarifications to javadoc for getGeneric*Type methods in j.l.r

Hello, Please review the doc clarifications to address     JDK-708660: (reflect) Clarifications to javadoc for getGeneric*Type methods in j.l.r     webrev: http://cr.openjdk.java.net/~darcy/7086604.0/     specdiff: http://cr.openjdk.java.net/~darcy/7086604.0.specdiff/overview-summary.html A

Re: JDK 13 RFR of JDK-708660: (reflect) Clarifications to javadoc for getGeneric*Type methods in j.l.r

-in-this-paricular-type since the latter provides better discoverability for developers. Thanks, -Joe On 6/10/2019 12:16 PM, Alex Buckley wrote: On 6/8/2019 4:04 PM, Joe Darcy wrote: Please review the doc clarifications to address JDK-708660: (reflect) Clarifications to javadoc for get

Re: JDK 13 RFR of JDK-708660: (reflect) Clarifications to javadoc for getGeneric*Type methods in j.l.r

this type variable. + * generic declaration declared for this type variable.   *   * @return the generic declaration declared for this type variable.   * On 6/10/2019 12:54 PM, Joe Darcy wrote: Hello, Given upcoming deadlines and the scope of the feedback suggested, I propose

JDK 13 RFR of JDK-8225675: Outdated citation of JLS in java.lang.ref.Reference

Hello, Please review the small patch below to address     JDK-8225675: Outdated citation of JLS in java.lang.ref.Reference (I'll reflow the paragraph before pushing; wanted to make the nature of the diff clearer in the review.) Thanks, -Joe diff -r 1224b16c8ff4 src/java.base/share/classes

JDK 14 RFR of JDK-8226809: Circular reference in printed stack trace is not correctly indented & ambiguous

Hello, Please review the fix for     JDK-8226809: hCircular reference in printed stack trace is not correctly indented & ambiguous     http://cr.openjdk.java.net/~darcy/8226809.0/ Patch below. Consider the code which creates various circularities in the suppressed and caused links of an exc

JDK 14 RFR of JDK-8227202: clarify Class.isEnum() doc

Hello, Please review the patch below to address     JDK-8227202: clarify Class.isEnum() doc To condense a long story (see https://blogs.oracle.com/darcy/so-you-want-to-change-the-java-programming-language), there are cases where the Class object of an enum constant is *not* the Class object

Re: JDK 14 RFR of JDK-8227202: clarify Class.isEnum() doc

Hi Brian, Thanks for catching that; I'll correct before pushing. Cheers, -Joe On 7/3/2019 2:28 PM, Brian Burkhalter wrote: Hi Joe, On Jul 3, 2019, at 2:24 PM, Joe Darcy <mailto:joe.da...@oracle.com>> wrote: + * Note that if an enum constant is declared with a class bod

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

Hello, Returning to some old work [1], please review the addition of a java.io.Serial annotation type for JDK 14 to mark serial-related fields and methods:     webrev: http://cr.openjdk.java.net/~darcy/8202385.3/     CSR: https://bugs.openjdk.java.net/browse/JDK-8217698 Thanks, -Joe [1] Pr

Re: EnumSet.class serialization broken - twice - JDK-8227368

Hello, I'd advise against including at least part of the comment     // declare serialization compatibility with JDK 8 (see JDK-8227368) We generally don't include bug numbers in the text of the code and rely mapping from the SCM to the bug database to provide the (sometimes large!) additiona

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

ference to the serialization specification for the definition of the fields and methods to make it clear where the authoritative identification is spec'd. 73-75:  Please align the and tags on separate lines with matching indentation. 77: Extra leading space. Regards, Roger On 7

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

ar to the style of reference made in java.io.Serializable. Offhand, I didn't know of the correct idiom to refer to the document as a working hyperlink, but would be switch to that idiom. Cheers, -Joe On 7/12/2019 8:19 PM, Joe Darcy wrote: Hi Roger, On 7/12/2019 1:31 PM, Roger Riggs

Re: RFR: 8228581: Archive BigInteger constants

Hi Claes, For those of us unfamiliar with the archive mechanism, can you describe its semantics or send a pointer to such a description? Thanks, -Joe On 7/24/2019 6:28 AM, Claes Redestad wrote: Hi, BigInteger has a number of pre-calculated constants that are profitable to put up for archiv

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

eful to describe that reflection is used to access and use the fields and methods and they may  otherwise appear to be unused. A recommendation could be added in an @impleNote to apply @Serial to each serialization defined method or field. $02, Roger On 7/13/19 1:16 PM, Joe Darcy wrote: PS I

JDK 14 RFR of JDK-8229997: Apply java.io.Serial annotations in java.base

Hello, Recent work for JDK-8202385: "Annotation to mark serial-related fields and methods" added the java.io.Serial annotation type to the platform. The intention of this new annotation type is to allow serialization-related fields and methods to be marked as documentation and to allow strict

Re: JDK 14 RFR of JDK-8229997: Apply java.io.Serial annotations in java.base

Hi Alan, On 8/27/2019 11:39 PM, Alan Bateman wrote: On 28/08/2019 02:28, Joe Darcy wrote: Hello, Recent work for JDK-8202385: "Annotation to mark serial-related fields and methods" added the java.io.Serial annotation type to the platform. The intention of this new annotation

JDK 14 RFR of JDK-8230074: Improve specification for {Math, StrictMath}.negateExact

Hello, Please review the small amendment to make the specifications for some of the "exact" methods in Math and StrictMath more explicit in their exceptional behavior:     JDK-8230074: Improve specification for {Math, StrictMath}.negateExact     http://cr.openjdk.java.net/~darcy/8230074.0/ P

Re: JDK 14 RFR of JDK-8229997: Apply java.io.Serial annotations in java.base

On 8/28/2019 9:23 AM, Martin Buchholz wrote: Should Serial.java have an @since 14 ? Yes; I'll fold that into another update. Thanks, -Joe

Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

Hello, For the doc changes in MethodHandle, please supplement the paragraph 1937  * 1938  * Note that this method throws errors related to loading and linking as 1939  * specified in Sections 12.2 and 12.3 of The Java Language 1940  * Specification. with @jls

JDK 14 RFR of JDK-8230681: Add @since tag to java.io.Serial

Hello, As spotted by Martin, please review the addition of an @since tag to the new-in-JDK-14 java.io.Serial type; patch below. Thanks, -Joe diff -r 06f3d5092832 src/java.base/share/classes/java/io/Serial.java --- a/src/java.base/share/classes/java/io/Serial.java    Thu Sep 05 11:12:12 2019

JDK 14 RFR of JDK-8230723: Remove default constructors from java.lang and java.io

Hello, First part of a multi-part cleanup effort please review     JDK-8230723: Remove default constructors from java.lang and java.io     webrev: http://cr.openjdk.java.net/~darcy/8230723.0/     CSR: https://bugs.openjdk.java.net/browse/JDK-8230724 Patch below. The default constructors on Mod

Re: JDK 14 RFR of JDK-8230723: Remove default constructors from java.lang and java.io

Hi Brian, On 9/6/2019 1:14 PM, Brian Burkhalter wrote: Hi Joe, On Sep 6, 2019, at 11:12 AM, Joe Darcy <mailto:joe.da...@oracle.com>> wrote: First part of a multi-part cleanup effort please review     JDK-8230723: Remove default constructors from java.lang andjava.io <ht

Re: Urgent RFR: 8231034/8231033 Problem list tetss failing after JSR-166 refresh

Looks fine David; thanks, -Joe On 9/15/2019 4:49 PM, David Holmes wrote: Bugs: https://bugs.openjdk.java.net/browse/JDK-8231033   https://bugs.openjdk.java.net/browse/JDK-8231034 webrev: http://cr.openjdk.java.net/~dholmes/8231033-8231034/webrev/ (inline below) A bunch of mainly managemen

JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes

Hello, As background, I'm working on a number of serialization-related compile-time checks with the goal of enabling stricter javac lint checking in the JDK build (and elsewhere). One check is tracked by     JDK-8160675: Issue lint warning for non-serializable non-transient instance fields

Re: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes

9/18/19 5:38 PM, Joe Darcy wrote: Hello, As background, I'm working on a number of serialization-related compile-time checks with the goal of enabling stricter javac lint checking in the JDK build (and elsewhere). One check is tracked by     JDK-8160675: Issue lint warning for non-seri

JDK 14 RFR of JDK-8199424: consider removing ObjectInputStream and ObjectOutputStream native methods

Hello, As part of my serialization work, I noticed some "to do" notes in ObjectOutputStream.java to get rid of two native methods once the integral <-> floating-point bitwise conversion methods (Float.floatToIntBits, etc.) were intrinsified. That intrinsification occurred many releases back a

Re: JDK 14 RFR of JDK-8199424: consider removing ObjectInputStream and ObjectOutputStream native methods

ObjectInputStream? Brian On Sep 19, 2019, at 3:34 PM, Joe Darcy <mailto:joe.da...@oracle.com>> wrote: As part of my serialization work, I noticed some "to do" notes in ObjectOutputStream.java to get rid of two native methods once the integral <-> floating-point b

Re: RFR 8231314: java.time serialization warning cleanup

Hello, Looks fine to me too. As Naoto observed, the patch is on top of a changeset with annotations I haven't pushed yet; I think it would be fine if this changeset were pushed first and I'll adjust mine accordingly. Thanks, -Joe On 9/20/2019 2:03 PM, naoto.s...@oracle.com wrote: Hi Roger,

JDK 14 RFR of JDK-8231442 : Suppress warnings on non-serializable instance fields in java.sql.* modules

Hello, Next step in the serialization warnings pre-cleanup is java.sql.* modules. Please review the proposed changes:     JDK-8231442 : Suppress warnings on non-serializable instance fields in java.sql.* modules     http://cr.openjdk.java.net/~darcy/8231442.0/ Several of the writeObject met

JDK 14 RFR of JDK-8231546: Suppress warnings on non-serializable instance fields in java.prefs module

Hello, Another part of the cleanup of library serialization usage ahead of augmented javac -Xlint warnings (JDK-8160675), the non-serializable instance fields of serializable types in the java.prefs module should have their serial warnings suppressed. The analogous issue in core libs is JDK-8

Re: JDK 14 RFR of JDK-8231546: Suppress warnings on non-serializable instance fields in java.prefs module

moved? -Chris. On 26 Sep 2019, at 19:27, Roger Riggs wrote: Looks fine, Joe On 9/26/19 1:51 PM, Joe Darcy wrote: Hello, Another part of the cleanup of library serialization usage ahead of augmented javac -Xlint warnings (JDK-8160675), the non-serializable instance fields of serializable typ

Re: RFR 8231427 (test) Warning cleanup in tests of java.io.Serializable

Hi Roger, Generally looks fine. Adding some comments about why the @SuppressWarnings annotations were being applied might help future readers of the code. Cheers, -Joe On 9/27/2019 10:02 AM, Roger Riggs wrote: Please review cleanup of tests in java/io/Serializable. There are warnings for m

Re: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma

Hello, At least from a quick reading, either the spec change or the behavior change would seem to merit a CSR. Cheers, -Joe On 10/2/2019 4:26 PM, Ivan Gerasimov wrote: Hi Chris! Thank you very much for review! I agree that it makes sense to update the javadoc for consistency. I don't thi

JDK 14 RFR of JDK-8231777: Remove extraneous @serial javadoc tag in NodeChangeEvent.java

Hello, In response to the review of JDK-8231546: http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062612.html it was noticed a field in NodeChangeEvent.java has an @serial javadoc tag, but the class itself is @serial excluded so the @serial tag on the field is extraneous.

JDK 14 RF(pre)R: add section on "conditionally serializable" collections

Hello, In response to the recent and on-going review of serializable types in the base module and elsewhere, I thought it would be helpful if the collections specs discussed how collections were serialiazable. In particular, the proposed terminology is that a collection is "conditionally seri

Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception

It is customary to have the license of a file be updated from someone affiliated with the copyright holder of the file. -Joe On 10/3/2019 1:42 PM, Florian Weimer wrote: * Adam Farley8: Four GPLv2 files in 8u seem to be missing the classpath exception from the copyright section. Requesting r

Re: RFR: JDK-8226585: Improve javac messages for using a preview API

Hi Jan, For future work, consider having a "Preview Methods" tag alongside static, instance, deprecated, etc. Cheers, -Joe On 10/3/2019 2:57 AM, Jan Lahoda wrote: Hi, This is a continuation of Joe's patch from here: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html

Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception

oring the change? Best Regards Adam Farley IBM Runtimes Joe Darcy wrote on 03/10/2019 23:30:14: > From: Joe Darcy > To: Florian Weimer , Adam Farley8 > Cc: jdk-updates-...@openjdk.java.net, Java Core Libs d...@openjdk.java.net> > Date: 03/10/2019 23:32 > Subject: Re: RFR: J

Re: JDK 14 RF(pre)R: add section on "conditionally serializable" collections

Hi Stuart, I prefer your more extensive write-up and thus I review it to go back :-) I've filed JDK-8231913: "Discuss serializability of collections" with you as the assignee. Thanks, -Joe On 10/4/2019 4:46 PM, Stuart Marks wrote: On 10/3/19 8:32 AM, Joe Darcy wrote: In

Re: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes

t;conditionally serializable" terminology in anticipate of the fix for JDK-8231913: "Discuss serializability of collections". Thanks, -Joe On 9/18/2019 2:38 PM, Joe Darcy wrote: Hello, As background, I'm working on a number of serialization-related compile-time checks with

Re: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes

: Joe, On 05/10/2019 04:04, Joe Darcy wrote: Hello, Please review the revised fix: http://cr.openjdk.java.net/~darcy/8231202.1/ Given the prior discussion in this thread, then I think this version looks fine ( which consists solely of warning suppressions ). -Chris.

JDK 14 RFR of JDK-8232076: Suppress warnings on non-serializable non-transient instance fields java.naming

Hello, The serialization review continues, this time a few fields in the java.naming module:     http://cr.openjdk.java.net/~darcy/8232076.0/ Patch below; thanks, -Joe --- old/src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java 2019-10-09 15:32:45.25800 -0700 +++

Re: RFR 8231427 (test) Warning cleanup in tests of java.io.Serializable

Looks good Roger; thanks, -Joe On 10/11/2019 8:12 AM, Roger Riggs wrote: Hi Joe, Updated with comments added for the reasons of the @SuppressWarnings("serial"). http://cr.openjdk.java.net/~rriggs/webrev-ser-test-cleanup-8231427-3/ Thanks, Roger On 9/27/19 2:45 PM, Joe Darcy

JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable non-transient instance fields in java.util.concurrent

Hello, Expanding the serialization review to include the java.util.concurrent package, please review the proposed changes:     JDK-8232230: Suppress warnings on non-serializable non-transient instance fields in java.util.concurrent     http://cr.openjdk.java.net/~darcy/8232230.0/ Terminolog

Re: RFR of JDK-8134599: TEST_BUG: java/rmi/transport/closeServerSocket/CloseServerSocket.java fails intermittently with Address already in use

Hello, Structurally, I'd prefer an approach that doesn't increase the minimum time needed to run the test. Any timeout-like value used within the test code should be sensitive to the jtreg timeout factor, as done in the webrev. Thanks, -Joe On 10/14/2019 7:20 PM, Weijun Wang wrote: +Sean

JDK 14 RFR of JDK-8232234: Suppress warnings on non-serializable non-transient instance fields in java.rmi

Hello, Please review the changes for serial review now extending to the java.rmi module:     JDK-8232234: Suppress warnings on non-serializable non-transient instance fields in java.rmi     http://cr.openjdk.java.net/~darcy/8232234.0/ Patch below. For src/java.rmi/share/classes/sun/rmi/ser

Re: JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable non-transient instance fields in java.util.concurrent

oncurrent upstream and then sync it down or should I push to jdk/jdk? Thanks, -Joe On Mon, Oct 14, 2019 at 5:33 PM Joe Darcy <mailto:joe.da...@oracle.com>> wrote: Hello, Expanding the serialization review to include the java.util.concurrent package, please review

Re: JDK 14 RFR of JDK-8232234: Suppress warnings on non-serializable non-transient instance fields in java.rmi

developers to suppress warning on fields that are not known to be serialized/externalized. Roger On 10/15/19 1:12 AM, Joe Darcy wrote: Hello, Please review the changes for serial review now extending to the java.rmi module:     JDK-8232234: Suppress warnings on non-serializable non-transi

  1   2   3   4   5   6   7   8   9   10   >