Re: CFV: new Core Libraries Group member: Roger Riggs

Vote: yes -Joe

Re: CVF: new Core Libraries Group member: Naoto Sato

Vote: yes -joe On 6/6/2022 5:52 PM, Stuart Marks wrote: I hereby nominate Naoto Sato [1] to membership in the Core Libraries Group [2]. Naoto Sato has been on the Core Libraries team for over a decade and has contributed hundreds of changes to the JDK project [3]. His most significant

Re: Why does we still need StrictMath?

On 5/8/2022 4:10 AM, Martin Desruisseaux wrote: Le 08/05/2022 à 10:56, Andrew Haley a écrit : Some targets (x86, in particular) have intrinsics (log, trig) that are faster than StrictMath and also more accurate. StrictMath is not about accuracy, but cross-architecture down-to-the-last bit

Re: Java Floating Points.

In the spirit of repeating previous messages, I again refer interested readers to my 2018 email to core-libs-dev which addresses many of the technical points being (re)raised here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/051952.html Appeal to authority is a commonly

FYI, candidate list of classes to be updated to sealed in JDK-8283414: Update java.base to use sealed classes (umbrella)

Hello, With a number of efforts to update various class hierarchies in the JDK to sealed classes, I wrote an annotation processor to find candidates to be changed to sealed. The candidates for this analysis are non-final public classes with at least one package access constructor and no

Re: Java float, double, StrictMath correction?

On 3/15/2022 6:11 PM, A Z wrote: [snip] Raffaello has said: 'Exact representation of 0.1 using base 2 is mathematically impossible, no matter the language (it is a periodic number in base 2).' Consideration of the article: https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf Which is

Re: RFR: JDK-8283124: Add constant for tau to Math and StrictMath

Hi Raffaello, With changing TAU to be set to 2.0 * PI, I'll file a follow-up bug to use the least-precision decimal values that will get rounded to PI and E, respectively, in Math and StrictMath. (Per the general base conversion properties for the double format, there will be between 15 and

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v6]

On 2/17/2022 8:34 AM, Roger Riggs wrote: On Thu, 17 Feb 2022 01:38:42 GMT, Joe Darcy wrote: This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. Language level modifiers and JVM level access

Re: RFR: 8279508: Auto-vectorize Math.round API [v2]

On 2/12/2022 6:55 PM, Jatin Bhateja wrote: On Fri, 21 Jan 2022 00:49:04 GMT, Sandhya Viswanathan wrote: The JVM currently initializes the x86 mxcsr to round to nearest even, see below in stubGenerator_x86_64.cpp: // Round to nearest (even), 64-bit mode, exceptions masked

Re: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap

On 12/4/2021 4:31 PM, liach wrote: On Wed, 24 Nov 2021 05:16:40 GMT, liach wrote: Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes. Since I don't have

Re: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec

It is a non-goal to replicate all of the JCK test coverage in the regression test suite. -Joe On 10/25/2021 7:17 PM, Sergey Bylokhov wrote: On Fri, 15 Oct 2021 07:17:52 GMT, Сергей Цыпанов wrote: It looks like we cannot use `Long.hashCode(long)` for `java.rmi.server.ObjID.hashCode()` due

Re: SourceVersion::feature

PS See https://github.com/openjdk/jdk/pull/5973 -Joe On 10/14/2021 1:53 PM, Joseph D. Darcy wrote: On 10/14/2021 10:23 AM, Michael Bien wrote: is this the right mailing list for javax.lang.model.* discussions? The compiler-dev list would be appropriate as well, but core-libs will work

Re: SourceVersion::feature

On 10/14/2021 10:23 AM, Michael Bien wrote: is this the right mailing list for javax.lang.model.* discussions? The compiler-dev list would be appropriate as well, but core-libs will work. First, I understand the desire for a method like this. One of the potential issues is SourceVersion

Re: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage

On 9/22/2021 4:53 PM, Claes Redestad wrote: On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов wrote: Currently the method is implemented like public List> parameterList() { return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); } This seems to be excessive, as three objects

Re: RFR: 8231640: (prop) Canonical property storage [v21]

Hello Jaikiran, The CSR is in Draft state. As discussed in the CSR wiki (https://wiki.openjdk.java.net/display/csr/Main), the request needs to be moved by the assignee to either Finalized or Proposed state to request the CSR review the request. HTH, -Joe On 9/20/2021 8:46 PM, Jaikiran Pai

Re: Confusing javadoc on a method java.lang.StringBuilder#readObject

On 9/8/2021 1:28 PM, Andrey Turbanov wrote: Hello. I found a confusing javadoc of the method java.lang.StringBuilder#readObject: "readObject is called to restore the state of the StringBuffer from a stream." I believe there should be "StringBuilder" instead of "StringBuffer". Agreed; filed

Re: How can I trigger a @Serial warning?

Hi Cay, The enhancements to javac's serial lint checking have not been implemented as of yet. For now, @Serial is just documentation. HTH, -Joe On 9/8/2021 10:43 PM, Cay Horstmann wrote: I am trying to give an example of the utility of the @Serial annotation. But the JDK 17 javac doesn't

Re: RFR (XS) 8224716 : Javadoc of Int/Long/DoubleSummaryStatistics should mention possible overflow of count

Hello, Please file a CSR for this change; thanks, -Joe On 6/25/2019 11:30 AM, Brent Christian wrote: I was musing about this myself. If the changes are within the @implNote(s), then perhaps not? -Brent On 6/25/19 11:15 AM, Brian Burkhalter wrote: > Is a CSR in order? Thanks, Brian On

Re: RFR(xs): 8225315 test java/util/ArrayDeque/WhiteBox.java isn't part of the jdk_collections test group

Looks okay. Should the test be removed from the catch-all group as part of this change? -Joe On 6/4/2019 5:53 PM, Stuart Marks wrote: Hi all, This test was added some time ago, but it wasn't added to the jdk_collections test group. Please review the patch appended below, which adds it to

Re: RFR: XS,docs JDK-8225314 broken links in java.base

Looks good; thanks Jon, -Joe On 6/4/2019 3:28 PM, Jonathan Gibbons wrote: Please review a small fix for a couple of broken links in java.base. Both look like the same copy/paste error, trying to refer to a target id in another package. No webrev: patch below. -- Jon JBS:

Re: RFR: [XS, doc] JDK-8225077: fix references to broken link in java.compiler module

+1 Thanks Jon, -Joe On 5/30/2019 1:32 PM, Jonathan Gibbons wrote: Please review a one line change to fix a 404 link in javax/annotation/processing/Filer.java With this fix, DocCheck finds no errors in the java.compiler module. JBS: https://bugs.openjdk.java.net/browse/JDK-8225077 -- Jon

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

Hi Naoto, Should this bug get a CSR for the behavioral change? Cheers, -Joe On 5/29/2019 2:12 PM, naoto.s...@oracle.com wrote: Hi, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8223773 The proposed changeset is located at:

Re: JDK 13 RFR of JDK-8223112: Clarify operational semantics of java.util.Objects.equals()

PS Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8223265 Note that the particular implementation used in Objects.equals was recommended in its initial code review back in 2009: http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-September/002580.html Thanks,

Re: RFR: JDK-8219483: j.l.c.ClassDesc::nested(String, String...) doesn't throw NPE if any arg is null

Hi Vicente, Revised version looks good; thanks, -Joe On 5/1/2019 1:08 PM, Vicente Romero wrote: Hi Joe, Thanks for the reviews, I have updated the webrev after you suggestion [1], Vicente [1] http://cr.openjdk.java.net/~vromero/8219483/webrev.02/ On 4/30/19 6:00 PM, Joseph D. Darcy

Re: RFR: JDK-8219483: j.l.c.ClassDesc::nested(String, String...) doesn't throw NPE if any arg is null

Hi Vicente, CSR reviewed. I suggesting adding a test case for cd.nested("good", null) Thanks, -Joe On 4/29/2019 2:41 PM, Vicente Romero wrote: Hi Joe, Thanks for the review. I have modified the patch, please see [1] . I still need a reviewer for the CSR [2], Vicente [1]

Re: RFR: JDK-8222151: refactoring: enhancements to java.lang.Class::methodToString and java.lang.Class::getTypeName

Hi Vicente, For methodToString, factoring out computing the common getName() + '.' + name prefix might be preferable, but otherwise the patch looks fine. Thanks, -Joe On 4/11/2019 10:22 AM, Vicente Romero wrote: Please review the enhancements to java.lang.Class proposed by Sergei

Re: RFR: 8222029: Optimize Math.floorMod

Should any additional cases be added to test/jdk/java/lang/Math/DivModTests.java to cover the new implementation? Thanks, -Joe On 4/5/2019 10:21 AM, Claes Redestad wrote: On 2019-04-05 17:41, Andrew Haley wrote: On 4/5/19 2:44 PM, Claes Redestad wrote: Testing: tier1-2, all Math tests run

Re: 8221597: A typo in the Java API doc for File.getUsableSpace()

+1 -Joe On 4/4/2019 4:54 PM, Brian Burkhalter wrote: Oops: unavailable -> available. On Apr 4, 2019, at 4:50 PM, Brian Burkhalter wrote: Summary: s/unallocated/unavailable/ at line 1872

Re: 8078860: (spec) InputStream.read(byte[] b, int off, int len) claims to not affect element b[off]

Hello, I would say the text in question is a (slightly incorrect) attempt to provide some explicit informative implications of the preceding normative text of the spec, so a CSR is not required for this correction. (There are other cases where a small correction would require a CSR.)

Re: [13] RFR: 8220224: With CLDR provider, NumberFormat.format could not handle locale with number extension correctly.

PS Looking more closely, I see the the issue is addressed in the 01 version of the webrev; I was only looking at the 00 version before :-) Thanks, -Joe On 3/21/2019 2:11 PM, Joseph D. Darcy wrote: Hi Naoto, Looks okay. The serial-related declarations are still using ; I think it is fine

Re: [13] RFR: 8220224: With CLDR provider, NumberFormat.format could not handle locale with number extension correctly.

Hi Naoto, Looks okay. The serial-related declarations are still using ; I think it is fine to push what you have now, but what encourage a follow-up bug to replace foo with {@code foo} throughout the entire class. Thanks, -Joe On 3/21/2019 1:54 PM, Naoto Sato wrote: Hello, Please review

Re: RFR: jsr166 integration 2019-02

On 2/10/2019 8:27 PM, Martin Buchholz wrote: On Sun, Feb 10, 2019 at 8:24 PM David Holmes wrote: On 11/02/2019 2:20 pm, Martin Buchholz wrote: On Sun, Feb 10, 2019 at 7:41 PM David Holmes mailto:david.hol...@oracle.com>> wrote: > Still in limbo: > 8203662: remove increment of

Re: Feature suggestion: Add static equals methods to Float and Double

Catching up on email... On 1/8/2019 10:55 AM, Hans Boehm wrote: The IEEE standard does say that for quiet NaNs, the value (or one of them) "should" be preserved by most operations on the quiet NaN. I have not heard of implementations violating this for anything other than the "quiet" bit. Thus

Re: 12 RFR (S): 8216532: tools/launcher/Test7029048.java fails (Solaris)

Rather than naming the enum for the test cases as "CASE", more conventional naming would be "TestCase" or "Case" for the type itself. -Joe On 1/16/2019 9:30 AM, mark.reinh...@oracle.com wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8216532 Webrev:

Re: latest changes in java.lang.Class

Hello, That does seem to be a bug in the changes I made for JDK-6304578: (reflect) toGenericString fails to print bounds of type variables on generic methods The logic in methodToString is used to build messages for exceptions and the omission of the argument information is a likely

Re: RFR: 8215380: Backout accidental change to String::length

+1 to revert to the prior version, Cheers, -Joe On 12/13/2018 3:20 PM, Claes Redestad wrote: Hi, I need to revert an accidental change to String.length Bug: https://bugs.openjdk.java.net/browse/JDK-8215380 Patch inlined below Running the accidentally pushed version in naive microbenchmarks

Re: JDK 13 RFR of core libs portions of JDK-8205626: Start of release updates for JDK 13

n 12/7/2018 12:16 AM, Alan Bateman wrote: On 07/12/2018 02:31, Joseph D. Darcy wrote: Hello, With the start of JDK 13 around the corner, please review the core libs portions of: JDK-8205626: Start of release updates for JDK 13 http://cr.openjdk.java.net/~darcy/jdk13-fork.2

JDK 13 RFR of core libs portions of JDK-8205626: Start of release updates for JDK 13

Hello, With the start of JDK 13 around the corner, please review the core libs portions of: JDK-8205626: Start of release updates for JDK 13 http://cr.openjdk.java.net/~darcy/jdk13-fork.2 Those changes include (but are not necessarily limited to) updates to:

Re: RFR 8214971 : Replace use of string.equals("") with isEmpty()

On 12/6/2018 1:08 PM, Pavel Rappo wrote: Roger, changes look good. On a side note, it's impressive how many cases we have when we check for string not being null and empty. We should have had something for that *internally* in the JDK. Or perhaps that should be a utility method on String or

Re: RFR(xs): 8211882: Broken links in serialized-form.html

Hi Stuart, Looks fine; thanks, -Joe On 12/5/2018 4:39 PM, Stuart Marks wrote: Hi all, Please review this small fix to correct some broken links in serialized-form.html. Patch appended below. Bug: https://bugs.openjdk.java.net/browse/JDK-8211882 Thanks, s'marks # HG changeset

Re: Downport JDK-8212828 (posix_spawn on Linux as non-default) to 11u

Hello, The specification of a system property includes both its name and its set of legal values. If the set of legal values changes, a CSR is warranted to document that. Cheers, -Joe On 11/29/2018 4:26 PM, David Holmes wrote: Hi Roger, On 30/11/2018 5:54 am, Roger Riggs wrote: Hi

Re: RFR: XXS: JDK-8213910: Invalid HTML in java.net.http.HttpClient

+1 -Joe On 11/14/2018 4:01 PM, Jonathan Gibbons wrote: Please review the removal of two extraneous in HttpClient.java. $ hg diff -R open diff -r 40098289d580 src/java.net.http/share/classes/java/net/http/HttpClient.java --- a/src/java.net.http/share/classes/java/net/http/HttpClient.java

Re: FYI: new javadoc tag to document system properties

Hello, For future CSR requests involving system properties, please document the properties using these javadoc facilities. Thanks, -Joe On 11/14/2018 2:27 PM, Jonathan Gibbons wrote: This is an FYI to announce some initial, long-overdue support in javadoc for documenting system properties

Re: Problems with ElementType.TYPE_USE and reflection

Hello, To get the type annotations on a field you would have to use field.getAnnotatedType().getAnnotations(); See https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/reflect/Field.html#getAnnotatedType() Calling getAnnotations on a field returns the declaration

Re: 8213321: Fix legal headers in test/jaxp

+1 Cheers, -Joe On 11/2/2018 12:13 PM, Joe Wang wrote: Hi, Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8213321 Changes: --- a/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java +++

Re: RFR (S) 8212178: Soft reference reclamation race in com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator

I think it would be reasonable to give engineers who work in the XML area some time to review the fix as well before it is pushed. Cheers, -Joe On 10/15/2018 11:13 AM, Aleksey Shipilev wrote: On 10/15/2018 07:50 PM, Kim Barrett wrote: Fix:

Re: 8152910: Get performance improvement with Stable annotation

Looks fine Brian; thanks, -Joe On 10/1/2018 2:31 PM, Brian Burkhalter wrote: Please review at your convenience: https://bugs.openjdk.java.net/browse/JDK-8152910 JMH benchmarks do show a slight but measurable performance improvement with the below patch applied. Thanks, Brian ---

Re: are there src git repositories for javase

The Skara project (http://mail.openjdk.java.net/mailman/listinfo/skara-dev) has a JDK 12 mirror at https://github.com/Project-Skara/jdk/ -Joe On 10/8/2018 10:37 AM, Bernd Eckenfels wrote: Hello, there is no official/canonical one as far as I know, but there are a few (externally

Re: RFR: JDK-8211121: Remove sun.reflect.ReflectionFactory::newInstanceForSerialization

Hi Lance, Looks fine; thanks, -Joe On 9/25/2018 4:10 PM, Lance Andersen wrote: Hi all: JDK-8211121 removes sun.reflect.ReflectionFactory::newInstanceForSerialization which was only used by the java.corba module. It was missed as part of the initial removal of the Java EE modules. The diff

Re: RFR: 8208746 8209775 : ISO 4217 Amendment #168 #169 Update

Hi Naoto, Thanks for checking; cheers, -Joe On 8/28/2018 6:44 PM, naoto.s...@oracle.com wrote: Hi Joe, This is a typical currency data change, and does not involve any public interface changes, so I think CSR is not needed. We haven't filed CSRs for such changes in the past. Naoto On

Re: RFR 8209171 : Simplify Java implementation of Integer/Long.numberOfTrailingZeros()

Hi Ivan, On which platforms were the benchmark numbers collected? Thanks, -Joe On 8/9/2018 4:15 PM, Ivan Gerasimov wrote: Hello! Integer.numberOfTrailingZeros() and Long.numberOfTrailingZeros() are intrinsified by Hotspot, so the Java implementation of these is not too important.

JDK 12 RFR of JDK-8208782: Remove extra type in throws clause of SerialClob.writeObject

Hello, The fix for JDK-8208060, Additional corrections of serial-related declarations, overlooked an extra type in the throws clause of javax.sql.rowset.serial.SerialClob.writeObject. The extra type should be removed. Patch below. Thanks, -Joe ---

Re: [12] RFR 8021322: [Fmt-Ch] Implementation of ChoiceFormat math methods should delegate to java.lang.Math methods

Looks fine; cheers, -Joe On 7/26/2018 9:26 AM, Naoto Sato wrote: Looks good. Naoto On 7/26/18 1:34 AM, Nishit Jain wrote: Hi, Please review the fix for JDK-8021322. CSR for the spec changes has been approved. Bug: https://bugs.openjdk.java.net/browse/JDK-8021322 Webrev:

JDK 12 RFR of JDK-8208060: Additional corrections of serial-related declarations

Hello, Another round of cleaning up the declarations of serial-related fields and methods: JDK-8208060: Additional corrections of serial-related declarations http://cr.openjdk.java.net/~darcy/8208060.0/ Summary of the issues being addressed:

Re: JDK 12 RFR of JDK-8207751: Remove misleading serialVersionUID from JulienFields.Field

thods" will check for these kinds of properties as part of the build. HTH, -Joe On 7/17/2018 4:53 PM, Lance Andersen wrote: Hi Joe On Jul 17, 2018, at 7:32 PM, Joseph D. Darcy <mailto:joe.da...@oracle.com>> wrote: Hi Lance, On 7/17/2018 4:25 PM, Lance Andersen wrote: Hi Joe, +1 I as

Re: JDK 12 RFR of JDK-8207751: Remove misleading serialVersionUID from JulienFields.Field

Hi Lance, On 7/17/2018 4:25 PM, Lance Andersen wrote: Hi Joe, +1 I assume we do not need to add a specific test for this clean-up? I put a "noreg-hard" label on the bug; I don't think it merits a dedicated test. Thanks, -Joe

Re: RFR [12] 8207748: Fix for 8202794 breaks tier1 builds

+1 -Joe On 7/17/2018 4:18 PM, Brian Burkhalter wrote: https://bugs.openjdk.java.net/browse/JDK-8207748.01 Diff included below. Build verified on Linux, macOS, and Solaris. Thanks, Brian --- a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c +++

Re: RFR 8198669: Refactor annotation array value parsing to reduce duplication

Looks good Liam; thanks, -Joe On 6/15/2018 10:58 AM, Liam Miller-Cushon wrote: Hello, This change is a follow-up to JDK-7183985 which replaces the interior of parseClassArray, parseEnumArray, and parseAnnotationArray with a shared method that is passed a lambda for the type-specific parsing

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

On 6/11/2018 10:38 PM, mandy chung wrote: On 6/11/18 10:16 PM, David Holmes wrote: Here is one further minor update from the CSR discussions: http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.corelibs.v5-incr/src/java.base/share/classes/java/lang/Class.java.cdiff.html "This

Re: (trivial) RFR: 8204589: ProblemList failing launcher tests

+1 -Joe On 6/7/2018 7:20 PM, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8204589 webrev: http://cr.openjdk.java.net/~dholmes/8204589/webrev/ After the push for: JDK-8201274 Launch Single-File Source-Code Programs there are a few test failures in our CI testing, so

Re: RFR: 8200888: typo in name of exception in @throws

Looks fine; even better if @exception is replaced with @throws :-) -Joe On 4/4/2018 5:21 PM, Jonathan Gibbons wrote: Please review this tiny fix to a typo in the name of an exception in @throws: No webrev; here's the change: NullPointerExcpetion -> NullPointerException diff -r

Re: RFR of JDK-8188897: java/rmi/registry/reexport/Reexport.java failed with Port already in use

Hello, Some general comments on the coding for tests like this: * It is preferable to avoid sleep in tests to avoid increasing the minimum amount of time a test takes to run. This helps limit the overall time it takes the test suite to run. * If timeouts are used, it is recommend to factor

Re: RFR: Here are some URLClassPath patches

Hi Martin, Until we figure out the best course of action, please problem list the failing test. Thanks, -Joe On 2/27/2018 7:02 PM, Martin Buchholz wrote: I should probably do more testing than usual when touching classloading... We have a jdi test that does this (hg blame finds duke as

Re: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present

Hi Liam, On 2/24/2018 5:14 PM, Liam Miller-Cushon wrote: Hi, thanks for the comments. The updated webrev is at: http://cr.openjdk.java.net/~cushon/7183985/webrev.02/ <http://cr.openjdk.java.net/%7Ecushon/7183985/webrev.02/> On Fri, Feb 23, 2018 at 4:29 PM, Joseph D. Darcy &

Re: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present

Hello, A few initial comments, not my final review. Objects implementing the AnnotatedElement interface are also created in javac during annotation processing. As a secondary concern, it would be good to be have behavior between both javac and runtime annotations consistent when possible.

Re: RFR: 8197594 - String and character repeat

On 2/15/2018 12:38 PM, Roger Riggs wrote: Hi Jim, Its cleaner to do the API (CSR) review before and without the implementation. It helps keep the issues separate. Don't make statements about count == Integer.MAX_VALUE / 2. There is no point, unless it should throw IAE. My general

Re: JDK 11 RFR of JDK-8196995: java.lang.Character should not state UTF-16 encoding is used for strings

Since other people who work more closely in the area than me don't seem to find the wording confusing or misleading, I'll just close out the bug. Thanks, -Joe On 2/8/2018 11:13 AM, Xueming Shen wrote: On 2/8/18, 10:59 AM, joe darcy wrote: Hello, On 2/8/2018 3:53 AM, Alan Bateman wrote: On

Re: RFR: JDK-8161348 Several tools/jlink tests failed due to time out

Hello, I'm wary of increasing the timeout to 5 minutes. When such tests are run on CI servers, the effective timeout can be 10 minutes or more given a timeout factor used for the test run. Should using 1GB of memory on the @run line have an earlier @requires guard for an amount of memory on

Re: RFR: 8134459: java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpTest.java timed out

Hello, Making tests run faster is all good of course. However, I'm leery of bumping up the timeouts; I'd prefer the tests be split into multiple parts if there is a chance it will take many minutes to run. (Having individual regression tests run in at most a minute or two helps avoid

Re: RFR (JDK10/JAXP Doc-only) 8189704: broken links in the javax/xml/namespace package

Looks fine Joe; cheers, -Joe On 1/3/2018 3:32 PM, huizhe wang wrote: Hi, Please review a doc-only fix for two namespace classes. The broken links to the Errata are removed since the reference(s) to the Errata is part of the Namespaces in XML specification itself. There is no need for the

Re: Java SE Maths questions.

On 12/6/2017 6:02 PM, David Holmes wrote: cc'ing core-libs-dev. Despite the notation on JEP 306 I don't think there's anyone from hotspot active in this area and most of the below is about SE library classes. David On 7/12/2017 11:39 AM, A Z wrote: These are Java SE questions. -Is it

Re: Fw: Question about JEP 306.

Hello, On 12/5/2017 5:07 PM, David Holmes wrote: Adding core-libs-dev as both mailing lists are named in this JEP. David On 6/12/2017 11:02 AM, A Z wrote: -I have been wondering what interest, focus or progress is happening around OpenJDK JEP 306: The rampdown phase for JDK 10 is

Re: RFR 8190441: ProblemList some intermittent CORBA tests

+1 -Joe On 10/31/2017 1:07 PM, Lance Andersen wrote: Looks good roger On Oct 31, 2017, at 4:05 PM, Roger Riggs wrote: Please review some additions to the ProblemList.txt for intermittent CORBA tests. diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt

Re: RFR Re: [PATCH] 8178117: Add public state constructors for Int/Long/DoubleSummaryStatistics

Hello, Is it intentional that "DoubleSummaryStatistics" is used in a sentence like 91 * @apiNote 92 * The enforcement of argument correctness means that the retrieved set of 93 * recorded values obtained from a {@code DoubleSummaryStatistics} source in all three types

Re: JDK 10 RFR of JDK-8183175: Add explicit constructors to MalformedParameterizedTypeException

Hi Brian, On 6/28/2017 5:37 PM, Brian Burkhalter wrote: Hi Joe, On Jun 28, 2017, at 5:01 PM, joe darcy > wrote: As noted in JDK-8183175: Add explicit constructors to MalformedParameterizedTypeException the exception type

Re: RFR 9 : 8180633 : Remove intermittent key from java/lang/ClassLoader/Assert.java

Sounds fine Brent; thanks, -Joe On 5/18/2017 3:59 PM, Brent Christian wrote: Hi, The test: java/lang/ClassLoader/Assert.java has been passing consistently on our automated test systems for quite a while. The last recorded failure I found happened ~18 months ago. I propose that the

Re: Long.bitCount micro-optimization

On 5/8/2017 1:29 PM, Doug Lea wrote: On 05/08/2017 02:14 PM, Isaac Levy wrote: Original message below: The JDK impl of bitCount can be improved -- though most users will get the hotspot intrinsic. The best source I could find for the suggestion below is page 195:

Re: RFR: Update tables in java.base to be HTML5-friendly.

Hi Jon, The changes in the java.lang and java.math packages look fine. Cheers, -Joe On 5/3/2017 3:06 PM, Jonathan Gibbons wrote: This is a review request for two co-dependent fixes. JDK-8179592: Update tables in java.base to be HTML 5-friendly. JDK-8179479: Add new styles to enable HTML 5

Re: RFR: 8179413: Fix remaining minor HTML5 issues in java.base module

Looks fine; thanks, -Joe On 4/27/2017 5:34 PM, Lance Andersen wrote: +1 On Apr 27, 2017, at 8:25 PM, Jonathan Gibbons wrote: Please review a handful of small changes that were not caught be the earlier bulk updates. Unlike those earlier updates, these few were

Re: RFR: 8179370: Replace use of , and tags in java.base

Hi Jon, I'd prefer if the "foo" were replaced with "{@code tt}" rather than "foo"- none of the tricky cases which preclude use of {@code } use seem to be present here - but will approve the changeset in its current form too. Cheers, -Joe On 4/26/2017 5:50 PM, Jonathan Gibbons wrote:

Re: [PATCH] 8178117: Add public state constructors for Int/Long/DoubleSummaryStatistics

On 4/11/2017 1:48 PM, Chris Dennis wrote: Color me confused… what would the javadoc on the parameter say? It could I guess have an @implNote documenting the meanings of the parameters… but then what use is it? The proposed API simply limits the precision with which a DoubleSummaryStatistic

Re: JDK 9 RFR of JDK-8177678: Overstatement of universality of Era.getDisplayName() implementation

Hi Naoto, On 3/27/2017 4:10 PM, Naoto Sato wrote: Hi Joe, thank you for working on this. - Weakening the universal wording in the parent method and inheriting the description in the overridden method looks fine to me. However, the background below mentions @implSpec, but the actual diff uses

Re: RFR: 8176541: XML deprecation "since" values should use 1.x version form for 1.8 and earlier

Looks fine; cheers, -Joe On 3/14/2017 6:08 PM, huizhe wang wrote: Hi, Please review a correction of the "since" values for several deprecated classes / methods. diff --git a/src/java.xml/share/classes/javax/xml/stream/XMLEventFactory.java

Re: JDK 9 RFR of 8176221: Preferences docs contain reference to Sun's JRE

Looks good Brian; thanks, -Joe On 3/13/2017 12:44 PM, Brian Burkhalter wrote: Please review this simple doc-only change for [1]: --- a/src/java.prefs/share/classes/java/util/prefs/Preferences.java +++ b/src/java.prefs/share/classes/java/util/prefs/Preferences.java @@ -188,8 +188,8 @@ *

Re: RFR: JDK-8175177 - org/omg/CORBA/OrbPropertiesTest.java changes JDK under test

Hello, I strongly recommend this test *not* write to java.home in any way, including undoing the changes afterward. If that is not possible, I think the test should be updated as suggested and also turned into a manual test. Cheers, -Joe On 2/23/2017 4:00 PM, Mark Sheppard wrote: Hi,

JDK 10 RFR of JDK-8172928: Add doc link from System.identityHashCode to Object.hashCode

Hello, Please review the patch below to address JDK-8172928: Add doc link from System.identityHashCode to Object.hashCode Thanks, -Joe diff -r e405d4bf5c56 src/java.base/share/classes/java/lang/System.java --- a/src/java.base/share/classes/java/lang/System.javaTue Feb 14 16:56:12

Re: Fixing Object.hashCode documentation

Hello, I just closed out JDK-6321873 adding the comment: Much of this contents of this issue was addressed by JDK-8071434; JDK-8172928 has been filed to add additional doc linkages between System.identityHashCode and Object.hashCode. -Joe On 1/17/2017 7:12 AM, Roger Riggs wrote: Hi, I

Re: Guaranteed order of annotations?

Hello, Following up on Joel's message, IIRC this ordering issue did come up during the design and testing of repeating annotations. As noted previously in the thread, while the ordering of the annotations in a container annotation is guaranteed, there is *not* a general ordering constraint

JDK 9 RFR of JDK-8171131: Problem list ModuleNamesOrderTest.java until JDK-8171070 is fixed

Hello, The test tools/jlink/ModuleNamesOrderTest.java has been seen to fail intermittently on different platforms. Until JDK-8171070 is fixed, the test should be problem listed. (Without having deeply investigated the issue, it looks like more @compile and @build directives are needed

Re: RFR: 8170595: Optimize Class.isAnonymousClass

Hello, I think work like this merits some additional test development to make sure the new, faster implementation doesn't introduce any regressions in correctness. From a quick look in the java/lang/Class test directory, I didn't see any existing tests probing the correctness of

JDK 9 RFR of JDK-8170875: Problem list LocaleTest.java until JDK-8170840 is fixed

Hello, After the fix for JDK-8071929, the test java/util/Locale/LocaleTest.java has been failing across platforms. Until JDK-8170840 is fixed, the test should be problem listed. Patch below. Thanks, -Joe --- a/test/ProblemList.txtWed Dec 07 11:53:26 2016 -0800 +++

Re: RFR: 8169020: Add since element to JDBC deprecated methods

Looks fine Lance; cheers, -Joe On 11/2/2016 11:04 AM, Lance Andersen wrote: Hi all, The diff below takes advantage the since element that was added to the Deprecated annotation to clarify when the JDBC methods where deprecated in Java SE. The CCC has been approved Best Lance ———

Re: [9] RFR: 8168921: Inconsistent Annotation.toString()

Looks good Ivan; thanks, -Joe On 11/2/2016 8:58 AM, Ivan Gerasimov wrote: Thank you Joe for review! On 31.10.2016 20:11, joe darcy wrote: Hi Ivan, The code change in src look fine, but please update the existing test test/java/lang/annotation/AnnotationToStringTest.java rather than

Re: RFR of JDK 8168505: Remove the intermittent keyword from java/util/Arrays/ParallelPrefix.java

+1 (Official reviewer :-) -Joe On 10/24/2016 6:31 PM, Amy Lu wrote: Looks fine. (I'm not an official reviewer.) Thanks, Amy On 10/25/16 9:22 AM, Hamlin Li wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8168505 webrev: http://cr.openjdk.java.net/~mli/8168505/webrev.00/ Test (

Re: RFR: 8160213: tools/pack200/Utils.java should clean up javac*.tmp files

Looks fine Kumar; thanks, -Joe On 10/24/2016 5:59 PM, Kumar Srinivasan wrote: Hello, Please review fix for: https://bugs.openjdk.java.net/browse/JDK-8160213 Webrev: http://cr.openjdk.java.net/~ksrini/8160213/webrev.00/ Now the temporary javac argument file will be written to the working

Re: RFR(xs): 8168096: markup error in "since" element spec of @Deprecated

+1 -Joe On 10/17/2016 4:20 PM, Stuart Marks wrote: Hi all, please review this tiny fix to the javadoc markup in the Deprecated annotation type. Thanks, s'marks --- a/src/java.base/share/classes/java/lang/Deprecated.javaThu Oct 13 23:02:35 2016 + +++

Re: RFR 8167524 Rogue character in Stream javadoc

+1 -Joe On 10/11/2016 2:27 PM, Paul Sandoz wrote: Hi, I accidentally fat fingered the JavaDoc of Stream which got consumed into an unrelated patch that i pushed [1]. Thanks go to Martin for noticing this. Paul. [1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e93b7ea55975 diff -r

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

If Hamlin's approach is taken in the end, I think having a smaller retry count (5 or 10 rather than 20) would be more appropriate to avoid making the worst-case running time longer than necessary. Cheers, -Joe On 9/29/2016 6:55 AM, Roger Riggs wrote: Hi Hamlin, One more suggested

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Hello, Without commenting on the particulars, I'm happy to see work being done to address this issue in running the RMI tests. A fix here should greatly increase the reliability of the JDK test suite! Thanks, -Joe On 9/29/2016 12:09 PM, Chris Hegarty wrote: On 29 Sep 2016, at 16:25, Chris

Re: JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec

t be misread as only applying if the value is positive? s/of/indicating a/ ? On Mon, Aug 22, 2016 at 1:47 PM, Joseph D. Darcy<joe.da...@oracle.com <mailto:joe.da...@oracle.com>>wrote: Hello, I plan to push with a slightly different wording. Rather than ... but with a guar

  1   2   3   >