Fwd: Re: [Request for help] Questions about make test TEST="micro" failures

Thanks David. Forward it to core-libs-dev. Forwarded Message Subject: Re: [Request for help] Questions about make test TEST="micro" failures Date: Wed, 27 Mar 2019 14:12:55 +1000 From: David Holmes Organisation: Oracle Corporation To: Jie Fu , hotspot-...@openjdk.

RFR: JDK-8221525: jpackage fails with non-ASCII characters in --copyright

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). - .properties file was written in default encoding (file.encoding=Cp1252). Native code was expecting UTF-8 and thus was not able to read non-ASCII char

Re: Review Request: JDK-8220282 Add MethodHandle tests on accessing final fields

This is a new version of the patch: http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8220282/webrev.01 I made further clean up to this new test. It extends MethodHandlesTest.HasFields class to include the test cases for instance final fields.  HasFields is used to test findGetter/findStaticGette

Re: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap

On 26/03/2019 11:56 pm, Aleksey Shipilev wrote: On 3/26/19 2:28 PM, Alan Bateman wrote: Also, are we not doing "[TESTBUG]" prefixes in synopsis anymore? I see you changed it in JIRA. The "testbug" label is used to tag test only issues, encoding in the bug description/commit message isn't real

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

The main source of confusion here seems to be due to that the coder is passed in as an argument, so it either needs to be trusted or has to be verified in the constructor. So, let's instead introduce AbstractStringBuilder(CharSequence) and make it do all manipulations. http://cr.openjdk.java

RFR (XS) 8221524: java/util/Base64/TestEncodingDecodingLength.java should be disabled on 32-bit platforms

Bug: https://bugs.openjdk.java.net/browse/JDK-8221524 It currently requests -Xmx8g, which is above the max representable memory for 32-bit VM. The test allocates byte[Integer.MAX_VALUE - C], which means we cannot trim the heap size. Therefore, we have to disable the test on 32-bit. Fix: diff

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

On 3/26/19 10:24 AM, Adam Farley8 wrote: Hiya Mandy, I've updated the webrev with your proposal, plus a few tweaks for formatting. http://cr.openjdk.java.net/~afarley/8216558.2/webrev Let me know what you think. This looks okay.  I took the liberty to take out the comment line (229-230

Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

On 3/26/19 4:57 AM, Lindenmaier, Goetz wrote: and also the cases when it requires to look at its caller frame. Never. Only the method that was executed when the exception is thrown is needed. I only mention the backtrace because it happens to store the top method and the corresponding byte

Re: RFR: JDK-8221256: Fix create-installer specific options on MAC

Hi Andy, Looks good. Thanks, Alexander On 3/26/2019 12:53 PM, Andy Herrick 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). [1] https://bugs.openjdk.java.net/browse/JDK-8221256 [2] http://c

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Roger, sorry I missunderstood you, yes I agree with what you're saying. Ivan, I see your view on the constructor, which prevents coder being set to LATIN1 in the case of !COMPACT_STRINGS. So if Roger is happy with your webrev, i'll go with that. Thanks Andrew Andrew Leonard Java Runtimes Develop

jpackage Proposal to replace Inno Setup in exe installers for Windows

Hi, RFE for jpackage to replace Inno Setup in exe installers for Windows was filed recently and available at https://bugs.openjdk.java.net/browse/JDK-8221333. RFE was filed based on an assumption it will not have a major impact on users of jpackage. Please let us know in the comments to the RF

Re: [PATCH] Some improvements for java.lang.Class

Hello Peter, I was unaware of mentioned detail (thank you a lot for pointing that out, it made me read the whole JEP280 again) so I've rebenchmarked my changes compiled with -XDstringConcat=inline. 1) as of Class::getTypeName for Object[] it turned out, that String::repeat performs slightly be

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

From the design point of view, I believe it is better to have the constructor AbstractStringBuilder(int, int, int) to check if the coder argument makes sense with respect to the value of COMPACT_STRING, so it won't be possible to create a StringBuilder with the coder==LATIN1, when it is not sup

RFR: JDK-8221256: Fix create-installer specific options on MAC

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). [1] https://bugs.openjdk.java.net/browse/JDK-8221256 [2] http://cr.openjdk.java.net/~herrick/8221256/ /Andy

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Hi Leonard, The introduction (in -01) of getCharSequenceCoder() and its use in StringBuilder and StringBuffer are fine. The change that is unnecessary is the change to the constructor in AbstractStringBuilder(coder, length, addition) to check COMPACT_STRINGS before using the coder. The exist

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

So my creation of getCharSequenceCoder() was in trying to use the same method as the StringBuffer(String) constructors, ie.String.coder(), however with the StringBuffer(CharSequence,..) constructor the seq can be a String or a StringBuilder or a StringBuffer, hence I created the static getCharS

Re: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions

+1 On 03/26/2019 01:01 PM, Brian Burkhalter wrote: I had to revise this again as I had put the new @throws UTFDataFomatException clause only on the package version of writeUTF() but not also on the public API version. CSR [2] withdrawn and updated also. Thanks, Brian [1] http://cr.openjdk.j

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Hi, We've got the subject open and its fresh, there's no need for a separate review cycle. The first fix (-01) does not seem to be consistent with the original design and handling of the coder.  The StringBuilder(String) and StringBuffer(String) constructors are the pattern that should be fo

Re: RFR: 8221473: Configuration::reads can use Set.copyOf

Hi Peter, On 26/03/2019 18:01, Peter Levart wrote: Would such method addition be worth it? Here is the impl of Set.copyOf: static Set copyOf(Collection coll) { if (coll instanceof ImmutableCollections.AbstractImmutableSet) { return (Set)coll; } else {

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Sorry chaps, I think my brain is getting confused!, I think we have conflicting reviews here? Roger, I added the getCharSequenceCoder() to AbstractStringBuilder so it was only defined in one place.. I agree with this being called in StringBuffer/Builder then we don't need the change to Abstract

Re: RFR (XS) 8221401: [TESTBUG] java/math/BigInteger/LargeValueExceptions.java should be disabled on 32-bit platforms

Looks all right. Thanks, Brian > On Mar 26, 2019, at 9:26 AM, Thomas Stüfe wrote: > > Looks fine and trivial. > > ..Thomas > > On Tue, Mar 26, 2019 at 2:02 PM Aleksey Shipilev wrote: > >> Ping, no takers? >> >> -Aleksey >> >> On 3/25/19 3:33 PM, Aleksey Shipilev wrote: >>> Bug: >>> http

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Hi Andrew, You are going to have to change the same code twice because the changes should be the StringBuffer and StringBuilder constructors and would remove the code that is added to the AbstractStringBuilder constructor.  That's a waste of review cycles. On 03/26/2019 11:45 AM, Andrew Leonard

Re: RFR: 8221473: Configuration::reads can use Set.copyOf

Hi, This change is OK, but I was thinking that in general, for cases like this one, it would be better to check that the Set obtained from the 'graph' Map is already immutable and throw an exception if that is not the case. Like Objects.requireNonNull method, there could be a similar static m

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

I'm happy with that Ivan. I've added the @bug id, good spot!, webrev-03 with that change added: http://cr.openjdk.java.net/~aleonard/8221430/webrev.03/ Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet

Re: ClassCastException: cannot assign SerializedLambda to field with ClassLoader

Hi, I think that Seth's case is a general problem with serialization of circular graph(s) with classes containing readResolve() method(s). The issue is being described here in full: https://bugs.openjdk.java.net/browse/JDK-6785441 In short: readResolve() method is specified to be invoked aft

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

Hiya Mandy, I've updated the webrev with your proposal, plus a few tweaks for formatting. http://cr.openjdk.java.net/~afarley/8216558.2/webrev Let me know what you think. Best Regards Adam Farley IBM Runtimes Mandy Chung wrote on 26/03/2019 03:51:29: > From: Mandy Chung > To: Adam Farle

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

On 3/26/19 8:45 AM, Andrew Leonard wrote: Hi Roger, No worries, the more the merrier! So that was one of my reasoning for adding getCharSequenceCode() was, I think what you're suggesting is my webrev.01, http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/

Re: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions

I had to revise this again as I had put the new @throws UTFDataFomatException clause only on the package version of writeUTF() but not also on the public API version. CSR [2] withdrawn and updated also. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8219196/webrev.04/ [2] https://bugs.openj

Re: RFR (XS) 8221401: [TESTBUG] java/math/BigInteger/LargeValueExceptions.java should be disabled on 32-bit platforms

Looks fine and trivial. ..Thomas On Tue, Mar 26, 2019 at 2:02 PM Aleksey Shipilev wrote: > Ping, no takers? > > -Aleksey > > On 3/25/19 3:33 PM, Aleksey Shipilev wrote: > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8221401 > > > > My major concern is to make tier1 passing on x86_32. T

Re: jpackage Packaging Tool Early Access Update 4

> On Mar 26, 2019, at 11:13 AM, Andy Herrick wrote: > > --overwrite was removed because our internal reviewers thought that was > inconsistent with other tools. > > the problem was that the option required us to fully remove the directory > tree /[.app], without regard to what is in it. >

Re: jpackage Packaging Tool Early Access Update 4

--overwrite was removed because our internal reviewers thought that was inconsistent with other tools. the problem was that the option required us to fully remove the directory tree /[.app], without regard to what is in it. other tools like jlink require a non-existent output path, and develo

Re: jpackage Packaging Tool Early Access Update 4

> On Mar 26, 2019, at 10:56 AM, Andy Herrick wrote: > > yes - this is a late regression in EA 4 which will shortly be remedied . > > The option --file-associations, and all of the mac specific options, need to > be valid in create-image mode on MAC. > > see: https://bugs.openjdk.java.net/br

Re: jpackage Packaging Tool Early Access Update 4

yes - this is a late regression in EA 4 which will shortly be remedied . The option --file-associations, and all of the mac specific options, need to be valid in create-image mode on MAC. see: https://bugs.openjdk.java.net/browse/JDK-8221256 /Andy On 3/26/2019 10:55 AM, Michael Hall wrote:

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Hi Roger, No worries, the more the merrier! So that was one of my reasoning for adding getCharSequenceCode() was, I think what you're suggesting is my webrev.01, http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ Ivan's view is that behaviour was an extended issue, which it is, but I though

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Hi Andrew, Sorry to be late to the review. For symmetry with the constructors StringBuffer(String), and StringBuilder(String) the determine the coder based on the input argument, I would recommend using the getCharSequenceCoder added in the -01 webrev and calling it from the StringBuffer(CharS

Re: ClassCastException: cannot assign SerializedLambda to field with ClassLoader

awesome ! thanks for the workaround peter wrote: > You can check my claims by changing the type of the field holding the > lambda to java.lang.Object and see if it works... (It should if my > memory serves me well :-) On Tue, Mar 26, 2019 at 3:54 AM Peter Levart wrote: > Hi Seth, > > I th

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Hi Ivan, Yes, i'm happy with that, as you say the simple constructor change fixes the immediate issue, but not necessarily the extended issue of a non-compactable CharSequence in COMPACT_STRINGS mode, but that's probably an enhanced issue to cover in a separate bug... I've created a new webrev.0

Re: jpackage Packaging Tool Early Access Update 4

> On Mar 19, 2019, at 11:17 AM, Andy Herrick wrote: > > The fourth EA build (Build 30) of jpackage tool is available at > https://jdk.java.net/jpackage/ > > Note this build contains significant Command Line Interface changes. > > Issues addressed since EA 3 (build 17): > > JDK-8219678

Re: RFR: 8221473: Configuration::reads can use Set.copyOf

Rémi, Alan, thanks for reviewing! /Claes On 2019-03-26 14:53, Remi Forax wrote: Looks good to me. Rémi

Re: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap

On 3/26/19 2:28 PM, Alan Bateman wrote: >> Also, are we not doing "[TESTBUG]" prefixes in >> synopsis anymore? I see you changed it in JIRA. >> > The "testbug" label is used to tag test only issues, encoding in the bug > description/commit message > isn't really reliable. Yes, some areas have used

Re: RFR: 8221473: Configuration::reads can use Set.copyOf

On 26/03/2019 13:44, Claes Redestad wrote: Or with this less verbose comment (suggested offline by Alan): diff -r 5ee30b6991a7 src/java.base/share/classes/java/lang/module/Configuration.java --- a/src/java.base/share/classes/java/lang/module/Configuration.java Mon Dec 03 16:25:27 2018 +0100 +

Re: RFR: 8221473: Configuration::reads can use Set.copyOf

Looks good to me. Rémi - Mail original - > De: "Claes Redestad" > À: "core-libs-dev" > Envoyé: Mardi 26 Mars 2019 14:44:06 > Objet: Re: RFR: 8221473: Configuration::reads can use Set.copyOf > On 2019-03-26 14:33, Claes Redestad wrote: >> Hi, >> >> replacing a lingering use of Collecti

Re: RFR: 8221473: Configuration::reads can use Set.copyOf

On 2019-03-26 14:33, Claes Redestad wrote: Hi, replacing a lingering use of Collections.unmodifiableSet with Set.copyOf in java.lang.module.Configuration is a small startup optimization. Bug: https://bugs.openjdk.java.net/browse/JDK-8221473 Or with this less verbose comment (suggested offline

RFR: 8221473: Configuration::reads can use Set.copyOf

Hi, replacing a lingering use of Collections.unmodifiableSet with Set.copyOf in java.lang.module.Configuration is a small startup optimization. Bug: https://bugs.openjdk.java.net/browse/JDK-8221473 Patch: diff -r 5ee30b6991a7 src/java.base/share/classes/java/lang/module/Configuration.java --- a

Re: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap

On 26/03/2019 13:02, Aleksey Shipilev wrote: On 3/25/19 4:10 PM, Alan Bateman wrote: On 25/03/2019 14:47, Aleksey Shipilev wrote: On 3/25/19 2:40 PM, Thomas Stüfe wrote: Note that this may not be enough for windows 32bit. Highest I can go there (win32 slowdebug build I just built) is 1400m

Re: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap

On 3/25/19 4:10 PM, Alan Bateman wrote: > On 25/03/2019 14:47, Aleksey Shipilev wrote: >> On 3/25/19 2:40 PM, Thomas Stüfe wrote: >>> Note that this may not be enough for windows 32bit. Highest I can go there >>> (win32 slowdebug build I >>> just built) is 1400m. >> That probably means something e

Re: RFR (XS) 8221401: [TESTBUG] java/math/BigInteger/LargeValueExceptions.java should be disabled on 32-bit platforms

Ping, no takers? -Aleksey On 3/25/19 3:33 PM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221401 > > My major concern is to make tier1 passing on x86_32. This is one of the tests > that fail. Smaller > heap size does not fit this test case, unfortunately. So, we

Re: RFR: JDK-8215019: Allow --install-dir on windows

looks good. /Andy On 3/25/2019 6:35 PM, Alexander Matveev wrote: Hi Andy, http://cr.openjdk.java.net/~almatvee/8215019/webrev.01/ Updated webrev with added missing message in HelpResources_zh_CN.properties and updated messages below: MSG_Help_win_install_dir=\ \Relative sub-path under the

RE: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

Hi Mandy, thanks for reading the JEP and giving detailed feedback! > In the "Basic algorithm to compute the message" section: > > "This dataflow analysis walks the bytecodes forward simulating the execution > stack." > > Please elaborate it. Given a stack trace, it starts with the most recent

Re: ClassCastException: cannot assign SerializedLambda to field with ClassLoader

> On 26 Mar 2019, at 07:54, Peter Levart wrote: > > Hi Seth, > > I think you stumbled on a "defect" of Java Serialization mechanism. Namely, > the inability for it to correctly deserialize object graphs containing a > cycle when an object in such cycle uses the "readResolve()" special method

RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633

Hi Deepak, > Thanks for review. I think Naoto and Ramanand are right, we do update the > copyright year when it is not a clean backport. Please find the updated > version of webrev. > > http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.01/ Ok, you are right... Still wondering, whether in

Re: ClassCastException: cannot assign SerializedLambda to field with ClassLoader

As I have suspected, this code works (see that there's no custom class loaders involved as they are unimportant in this situation): package test; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.ObjectInputStream; import java.

Re: ClassCastException: cannot assign SerializedLambda to field with ClassLoader

Hi Seth, I think you stumbled on a "defect" of Java Serialization mechanism. Namely, the inability for it to correctly deserialize object graphs containing a cycle when an object in such cycle uses the "readResolve()" special method to replace the deserialized object with a replacement object