Re: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable

Hi Jaikiran, > On Jul 10, 2019, at 2:56 AM, Jaikiran Pai wrote: > > Hello Lance, > On 10/07/19 2:25 AM, Lance Andersen wrote: >> ——— >> @implSpec This method is a no-op if this compressor has already >> 886 * been previously closed, >> >> >> >> Please remove “already” in both the

Re: 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause

Testing revealed the need for some changes in test/jdk/java/lang/System/LoggerFinder/internal. Webrev updated in place. Brian > On Jul 11, 2019, at 10:44 AM, Brian Burkhalter > wrote: > > https://bugs.openjdk.java.net/browse/JDK-8187898 > >

8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause

https://bugs.openjdk.java.net/browse/JDK-8187898 http://cr.openjdk.java.net/~bpb/8187898/webrev.00/ Override FilterOutputStream.write(byte[]) not to throw IOException. Including 2d-dev as this creates a source compatibility issue in PSPrinterJob which I fix in this patch. A CSR would of course

Re: RFR [14/java.xml] 8178843: A bug in an inner loop in MethodGenerator's getLocals method

Thanks Lance! -Joe On 7/10/19 6:38 PM, Lance Andersen wrote: +1 On Jul 10, 2019, at 7:57 PM, Joe Wang > wrote: Please review a cleanup that removes unused code. This code has two errors, one as indicated in the bug report, another attempting to loop through

Re: RFR: 8227587: Add internal privileged System.loadLibrary

Hi Roger, On 2019-07-11 16:10, Roger Riggs wrote: Hi Claes, JavaLangAccess.java: 316: Add @param tag done. System.java:  2282, 2287 Runtime.loadLibrary0 makes a second check for a security manager. Is there any potential gain by calling ClassLoader.loadLibrary directly? None of the

Re: RFR: 8227587: Add internal privileged System.loadLibrary

Hi Claes, JavaLangAccess.java: 316: Add @param tag System.java:  2282, 2287 Runtime.loadLibrary0 makes a second check for a security manager. Is there any potential gain by calling ClassLoader.loadLibrary directly? None of the internal uses would have a separatorChar. I expect most of the

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

Would it work to fix this by making DeleteOnExitHook::runHooks deal with dependencies? 1. Remove If deleted, or not directory which also takes care of not exists. 2. Sort remaining files by deepest child files/directories first. 3. Run delete again on the list. Otherwise files need to be

RFR: 8227587: Add internal privileged System.loadLibrary

Hi, by adding a method to load libraries with privileges to JavaLangAccess, we can simplify a slew of places where we are currently implementing adhoc privileged actions. This is a tiny but measurable gain on a range of startup tests. Webrev:

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

On 7/11/19 9:47 AM, Peter Levart wrote: http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/ Another thing to consider (done in above webrev.02) is what to do with unbalanced cancelDeleteOnExit(). I think it is better to throw exception than to

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

Hi, On 7/11/19 3:51 AM, Ivan Gerasimov wrote: On 7/10/19 5:17 PM, Brian Burkhalter wrote: I incorporated Peter’s version, adding the security check in cancelDeleteOnExit(), tweaking its verbiage along with that of deleteOnExit(), and modified the test DeleteOnExit to verify the new method.