URLClassLoader poisons the global JarFile cache

2020-06-05 Thread Charles Oliver Nutter
Hey folks, with some help from Claes Redestad I've filed an issue with analysis and reproduction of the legendary "zip file closed" error. https://bugs.openjdk.java.net/browse/JDK-8246714 It turns out that URLClassLoader is just plain broken when used to access jar files (which means this bug

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

2020-06-05 Thread Kim Barrett
> On Jun 5, 2020, at 7:57 PM, Magnus Ihse Bursie > wrote: > > On 2020-06-05 09:52, Kim Barrett wrote: >> [Changes are only to the build system, but since the changes have jdk-wide >> effect I’ve cc’d what I think are the relevant dev lists.] >> >> This change is part of JEP 347; the intent is

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

2020-06-05 Thread Kim Barrett
> On Jun 5, 2020, at 7:57 PM, Magnus Ihse Bursie > wrote: > > On 2020-06-05 13:59, Jim Laskey wrote: >> I know there was a discussion about this elsewhere but I would like to take >> the opportunity to correct this now >> >> make//autoconf/flags-cflags.m4:241 >> >> […] >> MacOSX has been

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

2020-06-05 Thread Magnus Ihse Bursie
On 2020-06-05 09:52, Kim Barrett wrote: [Changes are only to the build system, but since the changes have jdk-wide effect I’ve cc’d what I think are the relevant dev lists.] This change is part of JEP 347; the intent is to target JDK 16. Please review this change to the building of C++ code in

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

2020-06-05 Thread Magnus Ihse Bursie
On 2020-06-05 13:59, Jim Laskey wrote: I know there was a discussion about this elsewhere but I would like to take the opportunity to correct this now make//autoconf/flags-cflags.m4:241 elif test "x$TOOLCHAIN_TYPE" = xclang; then if test "x$OPENJDK_TARGET_OS" = xmacosx; then #

Re: RFR: JDK-8246706: [macos] Allow SigningPackageTest to be built with real certificates

2020-06-05 Thread Alexey Semenyuk
In SigningBase.java: --- KEYCHAIN = (value == null) ? "jpackagerTest.keychain" : value; --- Is "jpackagerTest.keychain" some legacy string? Should not it be "jpackageTest.keychain"? - Alexey On 6/5/2020 4:23 PM, Andy Herrick wrote: Please review fix to issue [1] at [2]. The fix enables

Re: Sometimes constraints are questionable

2020-06-05 Thread James Laskey
I’m fixing the two in java.base. The other two are in different modules and would require changes to export. So you can file on those.  > On Jun 5, 2020, at 5:36 PM, Stuart Marks wrote: > >  > >> On 6/3/20 10:36 AM, Stuart Marks wrote: >> 3) Integer wraparound/overflow during size

Re: Sometimes constraints are questionable

2020-06-05 Thread Stuart Marks
On 6/3/20 10:36 AM, Stuart Marks wrote: 3) Integer wraparound/overflow during size computation. AS.newLength generates this:     OutOfMemoryError: Required array length too large (3) is the only case generated by the library. In fact, AS.hugeLength() has oldLength and minGrowth

RFR: JDK-8246706: [macos] Allow SigningPackageTest to be built with real certificates

2020-06-05 Thread Andy Herrick
Please review fix to issue [1] at [2]. The fix enables running jpackage signing tests on macos with user supplied certificates. [1] https://bugs.openjdk.java.net/browse/JDK-8246706 [2] http://cr.openjdk.java.net/~herrick/8246706/webrev.01/index.html /Andy

Re: RFR: JDK-8246697 - Test: StringJoinerTest and related MergeTest failing with OOM

2020-06-05 Thread Jim Laskey
Thank you. > On Jun 5, 2020, at 3:21 PM, Igor Ignatyev wrote: > > LGTM > > -- Igor > >> On Jun 5, 2020, at 11:19 AM, Jim Laskey wrote: >> >> Updated diff >> >> >> diff -r 71ec718a0bd0 test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt Fri Jun 05 11:46:58 2020 -0300 >> +++

Re: RFR: JDK-8246697 - Test: StringJoinerTest and related MergeTest failing with OOM

2020-06-05 Thread Igor Ignatyev
LGTM -- Igor > On Jun 5, 2020, at 11:19 AM, Jim Laskey wrote: > > Updated diff > > > diff -r 71ec718a0bd0 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txtFri Jun 05 11:46:58 2020 -0300 > +++ b/test/jdk/ProblemList.txtFri Jun 05 15:18:36 2020 -0300 > @@ -883,7 +883,6

Re: RFR: JDK-8246697 - Test: StringJoinerTest and related MergeTest failing with OOM

2020-06-05 Thread Jim Laskey
Updated diff diff -r 71ec718a0bd0 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Fri Jun 05 11:46:58 2020 -0300 +++ b/test/jdk/ProblemList.txt Fri Jun 05 15:18:36 2020 -0300 @@ -883,7 +883,6 @@ # jdk_util java/util/ServiceLoader/ReloadTest.java 8242935

Re: RFR: JDK-8246697 - Test: StringJoinerTest and related MergeTest failing with OOM

2020-06-05 Thread Jim Laskey
Thank you. > On Jun 5, 2020, at 2:51 PM, Igor Ignatyev wrote: > > Hi Jim, > > I'd also recommend you to add `@requires os.maxMemory > 4G` so the tests > don't get executed on hosts which don't have enough memory for requested heap > size. > > -- Igor > >> On Jun 5, 2020, at 10:46 AM, Jim

Re: RFR: JDK-8246697 - Test: StringJoinerTest and related MergeTest failing with OOM

2020-06-05 Thread Igor Ignatyev
Hi Jim, I'd also recommend you to add `@requires os.maxMemory > 4G` so the tests don't get executed on hosts which don't have enough memory for requested heap size. -- Igor > On Jun 5, 2020, at 10:46 AM, Jim Laskey wrote: > > Followup: can I get a quick review for the following. Both tests

RFR: JDK-8246697 - Test: StringJoinerTest and related MergeTest failing with OOM

2020-06-05 Thread Jim Laskey
Followup: can I get a quick review for the following. Both tests were sensitive to heap size. jbs: https://bugs.openjdk.java.net/browse/JDK-8246697 diff -r 71ec718a0bd0 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Fri Jun 05 11:46:58 2020 -0300 +++ b/test/jdk/ProblemList.txt Fri

Re: RFR: JDK-8246627: Consolidate app image bundlers

2020-06-05 Thread Andy Herrick
Together these two changes might be a lot this late in the cycle, but it does make everything cleaner, and passes all test I have tried to run with them. I approve. /Andy On 6/4/2020 4:46 PM, Alexey Semenyuk wrote: Please review fix [2] for jpackage bug [1]. Move duplicated functionality

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

2020-06-05 Thread Daniel Fuchs
Hi Alexey, On 05/06/2020 17:33, Alexey Bakhtin wrote: Hi Daniel, Thank you for review Yes, I can move TlsChannelBinding class into the com.sun.jndi.ldap.sasl package and LdapClient related changes into the LdapSasl.saslBind method. Also, you are right with exceptions. I will rename them to

[PATCH] 8246633: Improve the performance of ObjectInputStream.resolveClass(ObjectStreamClass)

2020-06-05 Thread Peter Kessler OS
ObjectInputStream.resolveClass(ObjectStreamClass) is specified to find "the first class loader on the current thread's stack (starting from the currently executing method) that is neither the platform class loader nor its ancestor." Finding that class loader is done with a virtual frame walk

Re: Class.getCanonicalName() returns null for lambdas

2020-06-05 Thread Mandy Chung
On 6/5/20 6:42 AM, Christoph Dreis wrote: Hi, forgive me if this was discussed already, but I found that the implementation of hidden classes causes a change in behavior for Class.getCanonicalName(). A hidden class has no canonical name [1] and it can't be nominally referenced (like an

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

2020-06-05 Thread Alexey Bakhtin
Hi Daniel, Thank you for review Yes, I can move TlsChannelBinding class into the com.sun.jndi.ldap.sasl package and LdapClient related changes into the LdapSasl.saslBind method. Also, you are right with exceptions. I will rename them to the NamingException. However, I’d like to parse TLS

Re: RFR[8243655]: 'Map.replace javadoc code snippet typo'

2020-06-05 Thread Pavel Rappo
Extra points would be to substitute the resulting snippet for the actual implementation to see if it compiles and satisfies the tests. For example, like this: default boolean replace(K key, V oldValue, V newValue) { Map map = this; // synthetic line if (map.containsKey(key) &&

Re: RFR[8243655]: 'Map.replace javadoc code snippet typo'

2020-06-05 Thread Martin Buchholz
Looks good to me On Fri, Jun 5, 2020 at 8:20 AM Conor Cleary wrote: > > Hi, > > Could someone please take a look at my webrev for JDK-8243655 > 'Map.replace javadoc code snippet typo'? > > This fix addresses a typo in the javadoc for Map.replace(K, V, V) in the > default implementation code. The

Re: RFR[8243655]: 'Map.replace javadoc code snippet typo'

2020-06-05 Thread Jim Laskey
+1 > On Jun 5, 2020, at 12:20 PM, Conor Cleary wrote: > > Hi, > > Could someone please take a look at my webrev for JDK-8243655 'Map.replace > javadoc code snippet typo'? > > This fix addresses a typo in the javadoc for Map.replace(K, V, V) in the > default implementation code. The

RFR[8243655]: 'Map.replace javadoc code snippet typo'

2020-06-05 Thread Conor Cleary
Hi, Could someone please take a look at my webrev for JDK-8243655 'Map.replace javadoc code snippet typo'? This fix addresses a typo in the javadoc for Map.replace(K, V, V) in the default implementation code. The parameter 'value' in the conditional block is changed to 'oldValue' to reflect

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

2020-06-05 Thread Daniel Fuchs
Hi Alexey, Could we move the new code from LdapClient.java and LdapCtxt.java into the com.sun.jndi.ldap.sasl package, and possibly delay its execution until the com.sun.jndi.ldap.sasl.LdapSasl.saslBind method is called? The new TlsChannelBinding class should also be preferably moved to

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

2020-06-05 Thread Alexey Bakhtin
Hello Max, Thank you a lot for review. Could you check the new version of the patch : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ I’ve made the following changes: - TlsChannelBinding class is moved to java.naming module. java.security.sasl module is not affected any more - I pass

Re: RFR: JDK-8246696 Test: java/util/StringJoiner/StringJoinerTest.java failing with OOM

2020-06-05 Thread Jim Laskey
Right. The request and the content is right the subject of the e-mail was wrong. Sorry about that. > On Jun 5, 2020, at 11:48 AM, Igor Ignatyev wrote: > > Hi Jim, > > you should use another bug id, one which you are going to use to fix the > problem, in the problem list. > > -- Igor > >>

Re: RFR: JDK-8246697 Test: java/util/StringJoiner/StringJoinerTest.java failing with OOM

2020-06-05 Thread Igor Ignatyev
Hi Jim, you should use another bug id, one which you are going to use to fix the problem, in the problem list. -- Igor > On Jun 5, 2020, at 7:41 AM, Jim Laskey wrote: > > Can I get a quick review for the following. Getting some unexpected OOM from > test. Pulling until I figure it out. > >

Re: RFR: JDK-8246697 Test: java/util/StringJoiner/StringJoinerTest.java failing with OOM

2020-06-05 Thread sundararajan . athijegannathan
Looks good. -Sundar On 05/06/20 8:11 pm, Jim Laskey wrote: Can I get a quick review for the following. Getting some unexpected OOM from test. Pulling until I figure it out. jbs: https://bugs.openjdk.java.net/browse/JDK-8246696 diff -r 345693999a92 test/jdk/ProblemList.txt ---

RFR: JDK-8246697 Test: java/util/StringJoiner/StringJoinerTest.java failing with OOM

2020-06-05 Thread Jim Laskey
Can I get a quick review for the following. Getting some unexpected OOM from test. Pulling until I figure it out. jbs: https://bugs.openjdk.java.net/browse/JDK-8246696 diff -r 345693999a92 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Fri Jun 05 11:35:06 2020 -0300 +++

Re: RFR(S/T) : 8245874 : requires.extraPropDefns.vmOpts doesn't need -Xbootclasspath/a:bootClasses

2020-06-05 Thread Igor Ignatyev
Vladimir, Leonid, Thank you for your reviews! pushed. -- Igor > On Jun 4, 2020, at 3:55 PM, Leonid Mesnik wrote: > > Looks good. > > Leonid > On Jun 5, 2020, at 1:02 AM, Vladimir Ivanov > wrote: > > Looks good. > > Best regards, > Vladimir Ivanov > > On 27.05.2020 20:25, Igor Ignatyev

Class.getCanonicalName() returns null for lambdas

2020-06-05 Thread Christoph Dreis
Hi, forgive me if this was discussed already, but I found that the implementation of hidden classes causes a change in behavior for Class.getCanonicalName(). When using the following example code: interface Function { void doSomething(); } public class Example { public static

Re: RFR: JDK-824662: Refactor JLinkBundlerHelper and StandardBundlerParam classes

2020-06-05 Thread Andy Herrick
looks OK. /Andy On 6/4/2020 4:22 PM, Alexey Semenyuk wrote: Please review fix [2] for jpackage bug [1]. Move functionality to collect data about app (main class name, main jar, module name, etc) from JLinkBundlerHelper and StandardBundlerParam classes in dedicated LauncherData class. Remove

Re: RFR: 8246592: Simplify checking of boolean file attributes

2020-06-05 Thread Claes Redestad
Thanks, Roger! On 2020-06-05 14:18, Roger Riggs wrote: Looks good.

Re: RFR: 8246592: Simplify checking of boolean file attributes

2020-06-05 Thread Roger Riggs
Looks good. Thanks for the extra attention. Roger On 6/5/20 6:09 AM, Claes Redestad wrote: Hi Roger, yes, things were a bit inconsistent whether this is checking all or one. I went with all (even though all usage only asks for one) and updated to use plural consistently. /Claes On

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

2020-06-05 Thread Jim Laskey
I know there was a discussion about this elsewhere but I would like to take the opportunity to correct this now make//autoconf/flags-cflags.m4:241 elif test "x$TOOLCHAIN_TYPE" = xclang; then if test "x$OPENJDK_TARGET_OS" = xmacosx; then # On MacOSX we optimize for size, something

Re: RFR: 8246592: Simplify checking of boolean file attributes

2020-06-05 Thread Claes Redestad
Hi Roger, yes, things were a bit inconsistent whether this is checking all or one. I went with all (even though all usage only asks for one) and updated to use plural consistently. /Claes On 2020-06-05 11:23, Roger Riggs wrote: Hi Claes, Also, since the requested attribute is a bit mask the

Re: RFR: 8246592: Simplify checking of boolean file attributes

2020-06-05 Thread Roger Riggs
Hi Claes, Also, since the requested attribute is a bit mask the test should be that all of the attributes are present, not just some, iIt might prevent a mistake down the line. Probably the method name and argument names should be plural. Line: 120: should be 119 public boolean

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

2020-06-05 Thread Chris Hegarty
> On 4 Jun 2020, at 21:16, Mandy Chung wrote: > > ... > I finalized an updated CSR per all feedbacks which includes the deprecation > `sun.misc.Unsafe::shouldBeInitialized`. >https://bugs.openjdk.java.net/browse/JDK-8245871 > > updated webrev: >

Re: RFR(S/T) : 8245874 : requires.extraPropDefns.vmOpts doesn't need -Xbootclasspath/a:bootClasses

2020-06-05 Thread Vladimir Ivanov
Looks good. Best regards, Vladimir Ivanov On 27.05.2020 20:25, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8245874/webrev.00 8 lines changed: 2 ins; 0 del; 6 mod; Hi all, could you please review this small and trivial cleanup in TEST.ROOT files of test/jdk/ and

RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

2020-06-05 Thread Kim Barrett
[Changes are only to the build system, but since the changes have jdk-wide effect I’ve cc’d what I think are the relevant dev lists.] This change is part of JEP 347; the intent is to target JDK 16. Please review this change to the building of C++ code in the JDK to enable the use of C++14