Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

On 3/11/2019 3:49 PM, Mandy Chung wrote: On 3/11/19 8:48 AM, Adam Farley8 wrote: Hi Mandy, Thank you for explaining. :) Unfortunately I'm only a mere Author, and I cannot submit test runs on the shared test server. I have run the test locally, and it passes against a patched build and

Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

Looks good now, thanks! With best regards, Tagir Valeev On Mon, Mar 11, 2019 at 11:29 PM Joe Darcy wrote: > > Hello, > > Always surprising how much discussion an (apparently) simple refactoring > can generate! > > Thanks to Tagir for spotting this issue. > > For completeness, the two-argument

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Also, if the upper bound is an expression, the range() approach makes it clear that the upper bound expression is intended to be evaluated once. > On Mar 11, 2019, at 4:07 PM, John Rose > wrote: > > P.S. I also saw the fiery objections to the range() idiom, and I

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On Mar 7, 2019, at 4:33 AM, Tagir Valeev wrote: > > Hello, Remi! > > It actually works thanks to auto-boxing/unboxing. E.g. this > implementation works: > > static Iterable range(int from, int to) { > return () -> new PrimitiveIterator.OfInt() { >int cur = from; > >@Override >

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

On 3/11/19 8:48 AM, Adam Farley8 wrote: Hi Mandy, Thank you for explaining. :) Unfortunately I'm only a mere Author, and I cannot submit test runs on the shared test server. I have run the test locally, and it passes against a patched build and fails correctly agaionst an unpatched

Re: [PATCH] enhancement proposal for String concatenation

Yes, I agree that StringJoiner could benefit from a hint about the expected number of elements to join. On the other hand, with the current allocation scheme, each reference stored in the elts[] will only be copied at most twice on average, so the total performance improvement might not be

Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

On 2019-03-11 18:59, Mandy Chung wrote: The updated patch looks good. Mandy +1 /Claes

Re: RFR(jdk 13/java.xml) 8219705: Wrong media-type for a given serialization method

> On Mar 11, 2019, at 3:15 PM, Joe Wang wrote: > > > > On 3/11/19, 11:54 AM, Lance Andersen wrote: >> >> Hi Joe, >> >>> On Mar 11, 2019, at 2:41 PM, Joe Wang >> > wrote: >>> >>> Thanks Lance! >>> >>> The assertEquals message adds the name (prNames[i]) of

Re: [PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs

Hi, Jon On 2/28/19 1:38 PM, Jonathan Gibbons wrote: On 28/02/2019 20:58, Jonathan Gibbons wrote: Looking at the revised JAR specification, approved in [1], it is disappointing that the spec contains text which is specific to a JAR file being used in a classloader: |The resulting URLs are

Re: RFR(jdk 13/java.xml) 8219705: Wrong media-type for a given serialization method

On 3/11/19, 11:54 AM, Lance Andersen wrote: Hi Joe, On Mar 11, 2019, at 2:41 PM, Joe Wang > wrote: Thanks Lance! The assertEquals message adds the name (prNames[i]) of the property (e.g. media-type) so that it shows "java.lang.AssertionError: media-type

Re: RFR(jdk 13/java.xml) 8219705: Wrong media-type for a given serialization method

Hi Joe, > On Mar 11, 2019, at 2:41 PM, Joe Wang wrote: > > Thanks Lance! > > The assertEquals message adds the name (prNames[i]) of the property (e.g. > media-type) so that it shows "java.lang.AssertionError: media-type expected > [text/html] but found [text/xml]" when fail. Yep, I saw

Re: RFR(jdk 13/java.xml) 8219705: Wrong media-type for a given serialization method

Thanks Lance! The assertEquals message adds the name (prNames[i]) of the property (e.g. media-type) so that it shows "java.lang.AssertionError: media-type expected [text/html] but found [text/xml]" when fail. There's also a debug message that displays all of the properties when the test

Re: RFR(jdk 13/java.xml) 8219705: Wrong media-type for a given serialization method

Hi Joe I think this is fine. I might consider beefing up the test assertEquals message it is just the name Assert.assertEquals(value, prValues[i], prNames[i]); HTH Best Lance > On Mar 11, 2019, at 2:22 PM, Joe Wang wrote: > > Please review a fix for a JCK failure. All XML-related JCK

RFR(jdk 13/java.xml) 8219705: Wrong media-type for a given serialization method

Please review a fix for a JCK failure. All XML-related JCK and SQE tests passed after the patch. JBS: https://bugs.openjdk.java.net/browse/JDK-8219705 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8219705/webrev/ Thanks, Joe

Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

The updated patch looks good. Mandy On 3/11/19 9:29 AM, Joe Darcy wrote: Hello, Always surprising how much discussion an (apparently) simple refactoring can generate! Thanks to Tagir for spotting this issue. For completeness, the two-argument forms of requireNonNull which takes a

Re: RFR: JDK-8214566 : --win-dir-chooser does not prompt if destination folder is not empty

looks good. /Andy On 3/7/2019 5:52 PM, Alexander Matveev wrote: Hi Erik, http://cr.openjdk.java.net/~almatvee/8214566/webrev.01/ - Removed $(call SET_SHARED_LIBRARY_ORIGIN), TOOLCHAIN_LINK_CXX and linking with libjava. Thanks, Alexander On 3/7/2019 6:52 AM, Erik Joelsson wrote: Hello

Re: RFR: JDK-8215574 : Investigate and document usage of --category, --copyright, --vendor and --description

Looks good. /Andy On 3/8/2019 6:46 PM, Alexander Matveev wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Removed unused TITLE which is just APP_NAME. - Fix maintainer for DEB packages

Re: jpackage --create-installer problem on Mac when installer-type is unspecified

Although we plan to remove the mac-app-store intaller type for the first release (which will fix this instance the problem for now) I agree this is not right for an exception in one install type to prevent the other types (if there are any) from running. I think instead though we should try

Re: [13] RFR: 8220227: Host Locale Provider getDisplayCountry returns error message under non-English Win10

Looks good to me. I can sponsor your fix. Naoto On 3/11/19 1:57 AM, Toshio 5 Nakamura wrote: Hi Naoto-san, Thank you for reviewing the fix. Could you re-review the updated webrev? http://cr.openjdk.java.net/~tnakamura/8220227/webrev.01/ Thanks, Toshio Nakamura naoto.s...@oracle.com wrote

Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

Hello, Always surprising how much discussion an (apparently) simple refactoring can generate! Thanks to Tagir for spotting this issue. For completeness, the two-argument forms of requireNonNull which takes a Supplier is not applicable to preserve the message behavior since the loop counter

Re: RFR: 8220281 IBM-858 alias name is missing on IBM00858 charset

Looks good to me, thanks. I can sponsor your fix. Naoto On 3/10/19 8:35 PM, Ichiroh Takiguchi wrote: Hello Naoto. I appreciate your suggestion. I modified IBMBugs.java testcase. Could you review the fix again ? Bug:    https://bugs.openjdk.java.net/browse/JDK-8220281 Change:

Re: java.lang.CharSequence#compare - lexicographical ordering of custom Comparable CharSequence(s)

Hi Peter, The initial implementation was only optimized to call into String.compare if the arguments were string [1]. I proposed the current code a general form to catch java.nio.CharBuffer and any new JDK implementations of CharSequence + Comparable. Naively, I lean towards "- CharSequence

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

Hi Mandy, Thank you for explaining. :) Unfortunately I'm only a mere Author, and I cannot submit test runs on the shared test server. I have run the test locally, and it passes against a patched build and fails correctly agaionst an unpatched build, so I think we're good to go. Can you tell

Re: RFR: Container Fixes (8219652, 8217766, 8212528)

Sorry, missed a link: http://cr.openjdk.java.net/~bobv/8217766/webrev.0/ Bob. > On Mar 11, 2019, at 11:13 AM, Bob Vandette wrote: > > Please review these three fixes for Linux Docker/cgroup container support. > >

RFR: Container Fixes (8219652, 8217766, 8212528)

Please review these three fixes for Linux Docker/cgroup container support. https://bugs.openjdk.java.net/browse/JDK-8219562 - Line of code in osContainer_linux.cpp#L102 appears unreachable This change corrects a rarely used hotspot code path to be compatible with the Java based Metrics.

RE: RFR (XS): 8220409: [TESTBUG] jdk jtreg test jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java - testOverlapWithBaseModule tests the wrong thing

Thanks for the review, Alan. I pushed it. > -Original Message- > From: Alan Bateman > Sent: Montag, 11. März 2019 10:04 > To: Langer, Christoph ; Java Core Libs d...@openjdk.java.net>; jigsaw-dev > Subject: Re: RFR (XS): 8220409: [TESTBUG] jdk jtreg test >

Re: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux

Is vfork still guaranteed to be functional by the end of the Java 11 support frame, from the perspective of any organization which supports JDKs of this version? On Fri, Mar 8, 2019 at 9:22 AM Andrew Haley wrote: > > On 3/8/19 2:39 PM, Langer, Christoph wrote: > > please review the CSR backport

Re: jpackage --create-installer problem on Mac when installer-type is unspecified

Looking into the code of Arguments.generateBundle(Map params), I believe it's a bug to immediately throw an error when a bundler has configuration problems. Instead, that bundler should be removed from the platformBundlers List. Quick-and-dirty solution: diff -r e11f3bf34083

Re: RFR (S) 8074817: Resolve disabled warnings for libverify

On 3/10/19 1:17 PM, Alan Bateman wrote: > On 08/03/2019 17:35, Aleksey Shipilev wrote: >> Bug: >>    https://bugs.openjdk.java.net/browse/JDK-8074817 >> >> Fix: >>    http://cr.openjdk.java.net/~shade/8074817/webrev.03/ >> >> This hopefully resolves warnings in libverify. See bug report for

Re: RFR (XS): 8220409: [TESTBUG] jdk jtreg test jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java - testOverlapWithBaseModule tests the wrong thing

On 11/03/2019 08:50, Langer, Christoph wrote: Hi, please review this small test fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8220409 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8220409.0/ The test uses a wrong option "-add-modules" instead of "--add-modules" in one place. The

java.lang.CharSequence#compare - lexicographical ordering of custom Comparable CharSequence(s)

Hello, I stumbled on the specification of a static utility method CharSequence#compare introduced in Java 11 which says: * Compares two {@code CharSequence} instances lexicographically. Returns a * negative value, zero, or a positive value if the first sequence is

Re: [13] RFR: 8220227: Host Locale Provider getDisplayCountry returns error message under non-English Win10

Hi Naoto-san, Thank you for reviewing the fix. Could you re-review the updated webrev? http://cr.openjdk.java.net/~tnakamura/8220227/webrev.01/ Thanks, Toshio Nakamura naoto.s...@oracle.com wrote on 2019/03/09 02:39:48: > From: naoto.s...@oracle.com > To: Toshio 5 Nakamura , 18n-dev

RFR (XS): 8220409: [TESTBUG] jdk jtreg test jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java - testOverlapWithBaseModule tests the wrong thing

Hi, please review this small test fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8220409 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8220409.0/ The test uses a wrong option "-add-modules" instead of "--add-modules" in one place. Thanks Christoph

Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

On 3/10/19 9:19 PM, Martin Buchholz wrote: We should stop discussing this here, but ... ... I think that we really should, but ... On Sun, Mar 10, 2019 at 1:51 AM Peter Levart > wrote: In this particular case, this is not true. A lambda that captures

jpackage --create-installer problem on Mac when installer-type is unspecified

I'm experimenting with jpackage from the current EA available at https://jdk.java.net/jpackage/ , for the moment on Mac only. I have an existing application which I have previously deployed on multiple platforms using the then bundled javafxpackager. With the

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On 7/03/2019 12:48 am, Scott Palmer wrote: I don’t mean any offence, but I have to say, I strongly disagree with nearly everything you’ve written below. To me, the idea of making a stream of integers for a simple loop counter is hackish, confusing, verbose, and basically abusing the stream

JDK 12's String::transform vs F#'s |> operator

Hello, I've recently learned about JDK 12's new String::transform method: https://bugs.openjdk.java.net/browse/JDK-8203703 Obviously, this is useful. And obviously, this would be far more useful as a general pattern than just something for String. E.g. why not also for any Number subtype. For