Re: WeakReference with null referent

2018-07-09 Thread Zheka Kozlov
I also created an issue in IDEA bug tracker: https://youtrack.jetbrains.com/issue/IDEA-195298. This at least should be handled by an IDE.

Re: [11] RFR(XS) 8206952: java/lang/Class/GetPackageBootLoaderChildLayer.java fails with Graal

2018-07-09 Thread Vladimir Kozlov
Thank you, Mandy Vladimir On 7/9/18 10:02 PM, mandy chung wrote: +1 Mandy On 7/9/18 10:04 PM, Vladimir Kozlov wrote: https://bugs.openjdk.java.net/browse/JDK-8206952 Don't run the test with Graal because --limit-modules flag excludes Graal module: diff -r 1835f9fca157

Re: [11] RFR(XS) 8206952: java/lang/Class/GetPackageBootLoaderChildLayer.java fails with Graal

2018-07-09 Thread mandy chung
+1 Mandy On 7/9/18 10:04 PM, Vladimir Kozlov wrote: https://bugs.openjdk.java.net/browse/JDK-8206952 Don't run the test with Graal because --limit-modules flag excludes Graal module: diff -r 1835f9fca157 test/jdk/java/lang/Class/GetPackageBootLoaderChildLayer.java ---

Re: [11] RFR(XS) 8206952: java/lang/Class/GetPackageBootLoaderChildLayer.java fails with Graal

2018-07-09 Thread Ekaterina Pavlova
Good. Thanks for fixing! -katya On 7/9/18 10:04 PM, Vladimir Kozlov wrote: https://bugs.openjdk.java.net/browse/JDK-8206952 Don't run the test with Graal because --limit-modules flag excludes Graal module: diff -r 1835f9fca157 test/jdk/java/lang/Class/GetPackageBootLoaderChildLayer.java

[11] RFR(XS) 8206952: java/lang/Class/GetPackageBootLoaderChildLayer.java fails with Graal

2018-07-09 Thread Vladimir Kozlov
https://bugs.openjdk.java.net/browse/JDK-8206952 Don't run the test with Graal because --limit-modules flag excludes Graal module: diff -r 1835f9fca157 test/jdk/java/lang/Class/GetPackageBootLoaderChildLayer.java --- a/test/jdk/java/lang/Class/GetPackageBootLoaderChildLayer.java +++

Re: ArrayList.ensureCapacity should expand the default capacity empty array

2018-07-09 Thread Martin Buchholz
Thanks Alex, I filed https://bugs.openjdk.java.net/browse/JDK-8206945 I've had similar thoughts for years, but none have ended up in the actual code. I haven't seem the approach you used in your reallocate. On Thu, Jul 5, 2018 at 10:04 AM, Alex Foster wrote: > Hi, > > > I think that

Re: WeakReference with null referent

2018-07-09 Thread mandy chung
On 7/9/18 12:59 PM, Per Liden wrote: On 2018-07-09 20:49, mandy chung wrote: On 7/9/18 11:31 AM, Zheka Kozlov wrote: It is possible to create a WeakReference/SoftReference/PhantomReference with a null value in which case the Reference will never be enqueued. This is quite obvious

Re: WeakReference with null referent

2018-07-09 Thread Roger Riggs
Hi, After so many years of accepting null, throwing NPE would an incompatible change and break existing uses. Documenting it as ill advised or useless is would be a useful caution. Regards, Roger On 7/9/18 3:59 PM, Per Liden wrote: On 2018-07-09 20:49, mandy chung wrote: On 7/9/18

Re: WeakReference with null referent

2018-07-09 Thread Per Liden
On 2018-07-09 20:49, mandy chung wrote: On 7/9/18 11:31 AM, Zheka Kozlov wrote: It is possible to create a WeakReference/SoftReference/PhantomReference with a null value in which case the Reference will never be enqueued. This is quite obvious (since null cannot be weakly/softly/phantom

Re: WeakReference with null referent

2018-07-09 Thread mandy chung
On 7/9/18 11:31 AM, Zheka Kozlov wrote: It is possible to create a WeakReference/SoftReference/PhantomReference with a null value in which case the Reference will never be enqueued. This is quite obvious (since null cannot be weakly/softly/phantom reachable). But I think it's worth being

WeakReference with null referent

2018-07-09 Thread Zheka Kozlov
It is possible to create a WeakReference/SoftReference/PhantomReference with a null value in which case the Reference will never be enqueued. This is quite obvious (since null cannot be weakly/softly/phantom reachable). But I think it's worth being mentioned in the JavaDoc. What do you think?

ArrayList.ensureCapacity should expand the default capacity empty array

2018-07-09 Thread Alex Foster
Hi, I think that ensureCapacity should actually ensure the capacity by expanding the default capacity empty array, otherwise you could end up with a situation like this: List> ls = getLists();// Large list of ArrayLists ls.forEach(l -> l.ensureCapacity(10)); //later...

RFR: 8206863: A closed JarVerifier.VerifierStream should throw IOException

2018-07-09 Thread Martin Buchholz
Here's another fix from Tobias and myself: 8206863: A closed JarVerifier.VerifierStream should throw IOException http://cr.openjdk.java.net/~martin/webrevs/jdk/JarVerifier-stream-closed/ https://bugs.openjdk.java.net/browse/JDK-8206863

Re: RFR: 8148188: Enhance the security libraries to record events of interest

2018-07-09 Thread Seán Coffey
Erik, Thanks for reviewing. Comments inline.. On 09/07/18 17:21, Erik Gahlin wrote: Thanks Sean. Some feedback on the code in the security libraries. - We should use camel case naming convention for variables (not underscore). Sure. I see two offending variable names which I'll fix up. -

Re: RFR: 8148188: Enhance the security libraries to record events of interest

2018-07-09 Thread Erik Gahlin
Thanks Sean. Some feedback on the code in the security libraries. - We should use camel case naming convention for variables (not underscore). - Looking at sun/security/ssl/Finished.java, I wonder if it wouldn't be less code and more easy to read, if we would commit the event in a local

Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]

2018-07-09 Thread Kevin Rushforth
For the first point, it means that jpackager should use jopt for the argument parsing (to be fully compatible with the GNU style of options). For the second point, it means to change a lot of code that may break because it's less mechanical than introducing try-with-resources. This seems

Re: RFR: 8148188: Enhance the security libraries to record events of interest

2018-07-09 Thread Seán Coffey
As per request from Erik, I separated the tests out into individual ones to test the JFR and Logger functionality. I introduced a new separate test for the CertificateChainEvent event also. Originally this was wrapped into the TLSHandshakeEvent test. Thanks to Erik for extra refactoring and

Re: [11] RFR: 8206445: JImageListTest.java failed in Windows

2018-07-09 Thread Alan Bateman
On 09/07/2018 11:38, Srinivas Dama wrote: Hi, Please review webrev: http://cr.openjdk.java.net/~sdama/8206445/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8206445 testListEmptyFile looks okay but you can reduce the code if if you use Path.of("."). testListNotAnImage can use

[11] RFR: 8206445: JImageListTest.java failed in Windows

2018-07-09 Thread Srinivas Dama
Hi, Please review webrev: http://cr.openjdk.java.net/~sdama/8206445/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8206445 Regards, Srinivas

Re: RFR(M): 8203826: Chain class initialization exceptions into later NoClassDefFoundErrors

2018-07-09 Thread Peter Levart
Hi David, On 07/09/2018 09:33 AM, David Holmes wrote: On 9/07/2018 5:22 PM, Peter Levart wrote: Hi David, On 07/09/2018 03:37 AM, David Holmes wrote: Hi Peter, On 7/07/2018 2:10 AM, Peter Levart wrote: Hi, On 07/05/2018 01:01 AM, David Holmes wrote: I dispute "they will understand this

Re: RFR(M): 8203826: Chain class initialization exceptions into later NoClassDefFoundErrors

2018-07-09 Thread David Holmes
On 9/07/2018 5:22 PM, Peter Levart wrote: Hi David, On 07/09/2018 03:37 AM, David Holmes wrote: Hi Peter, On 7/07/2018 2:10 AM, Peter Levart wrote: Hi, On 07/05/2018 01:01 AM, David Holmes wrote: I dispute "they will understand this might have happened in another thread". What if the

Re: RFR(M): 8203826: Chain class initialization exceptions into later NoClassDefFoundErrors

2018-07-09 Thread Peter Levart
Hi David, On 07/09/2018 03:37 AM, David Holmes wrote: Hi Peter, On 7/07/2018 2:10 AM, Peter Levart wrote: Hi, On 07/05/2018 01:01 AM, David Holmes wrote: I dispute "they will understand this might have happened in another thread". What if the stack trace was like the following... Yes