Re: RFR [9] 8146484: Examine sun.misc.MessageUtils

2016-01-06 Thread Alan Bateman
On 06/01/2016 05:28, Chris Hegarty wrote: sun.misc.MessageUtils provides low-level access for writing “error” messages to stdout and stderr. It is, effectively, used in just one place in the JDK, String coding, when the specific encoding is not available. Since this is the only usage, the minim

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

2016-01-06 Thread Stephen Colebourne
Just to note that I once needed this and even commented on Stack Overflow about it: http://stackoverflow.com/questions/166340/write-a-password-protected-zip-file-in-java I'd just note that setting the password on each entry is a bit painful, as you'd normally expect to just set the password once.

Re: RFR [9] 8146484: Examine sun.misc.MessageUtils

2016-01-06 Thread Chris Hegarty
On 06/01/16 10:12, Alan Bateman wrote: On 06/01/2016 05:28, Chris Hegarty wrote: sun.misc.MessageUtils provides low-level access for writing “error” messages to stdout and stderr. It is, effectively, used in just one place in the JDK, String coding, when the specific encoding is not available. S

Re: RFR:8146218: Producing streams in java.time?

2016-01-06 Thread Stephen Colebourne
Thanks for the patch. The docs say that if the end date is before the start date, the stream is empty. While I can see just about why LongStream.range() works that way, I don't think this API should. The minimum is an exception, but it would be easy to support negative in the days-only case or the

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

2016-01-06 Thread KUBOTA Yuji
Hi Sherman, Thank you for your feedback! At first, I'd like to confirm your thought about ZipCryption to prevent misunderstand. By following reasons, we should remove (or modified) ZipCryption to not have any "encryption" related field/method in DeflaterOutputStream / InflaterInputStream. 1. Fo

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

2016-01-06 Thread KUBOTA Yuji
Hi Stephen, Thank you for your note. After discussion about the design, we will re-implement API. Please check it, and give feedback us when the time comes :) Thanks, Yuji 2016-01-06 19:27 GMT+09:00 Stephen Colebourne : > Just to note that I once needed this and even commented on Stack Overflow

Re: RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base

2016-01-06 Thread Chris Hegarty
Roger, On 05/01/16 21:24, Roger Riggs wrote: Hi Chris, On 1/5/2016 2:33 PM, Chris Hegarty wrote: On 5 Jan 2016, at 18:24, Roger Riggs wrote: The follow on work to adding the Cleaner is to replace uses of finalization with uses of the Cleaner. For the 'easy' cases in the java.base module, i

Re: RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base

2016-01-06 Thread Daniel Fuchs
Hi Roger, I was wondering whether URLJarFile::finalize could be simply removed. The change you are proposing looks strange to me: if this method remains, then either the method should continue to call close() or it should call super.finalize(), shouldn't it? Since this is a sun.net class then m

Re: RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base

2016-01-06 Thread Roger Riggs
Hi Chris, On 1/6/2016 9:39 AM, Chris Hegarty wrote: Roger, On 05/01/16 21:24, Roger Riggs wrote: Hi Chris, On 1/5/2016 2:33 PM, Chris Hegarty wrote: On 5 Jan 2016, at 18:24, Roger Riggs wrote: The follow on work to adding the Cleaner is to replace uses of finalization with uses of the Cle

Re: RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base

2016-01-06 Thread Roger Riggs
Hi Daniel, On 1/6/2016 9:52 AM, Daniel Fuchs wrote: Hi Roger, I was wondering whether URLJarFile::finalize could be simply removed. The change you are proposing looks strange to me: if this method remains, then either the method should continue to call close() or it should call super.finalize(

Re: RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base

2016-01-06 Thread Alan Bateman
On 05/01/2016 18:24, Roger Riggs wrote: The follow on work to adding the Cleaner is to replace uses of finalization with uses of the Cleaner. For the 'easy' cases in the java.base module, it is useful to introduce a private Cleaner for the java.base module. It is proposed to be held weakly, t

Re: RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base

2016-01-06 Thread Chris Hegarty
On 06/01/16 14:54, Roger Riggs wrote: Hi Chris, On 1/6/2016 9:39 AM, Chris Hegarty wrote: Roger, On 05/01/16 21:24, Roger Riggs wrote: Hi Chris, On 1/5/2016 2:33 PM, Chris Hegarty wrote: On 5 Jan 2016, at 18:24, Roger Riggs wrote: The follow on work to adding the Cleaner is to replace us

Re: RFR [9] 8146484: Examine sun.misc.MessageUtils

2016-01-06 Thread Mandy Chung
+1 Mandy > On Jan 5, 2016, at 9:28 PM, Chris Hegarty wrote: > > sun.misc.MessageUtils provides low-level access for writing “error” messages > to stdout and stderr. It is, effectively, used in just one place in the JDK, > String > coding, when the specific encoding is not available. Since this

Re: RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base

2016-01-06 Thread Roger Riggs
Hi Alan, On 1/6/2016 10:32 AM, Alan Bateman wrote: On 05/01/2016 18:24, Roger Riggs wrote: The follow on work to adding the Cleaner is to replace uses of finalization with uses of the Cleaner. For the 'easy' cases in the java.base module, it is useful to introduce a private Cleaner for the j

Re: RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base

2016-01-06 Thread Peter Levart
On 01/05/2016 10:16 PM, Roger Riggs wrote: Hi Daniel, webrev updated to revert changes to MeteredStream as too risky. http://cr.openjdk.java.net/~rriggs/webrev-cleaning-finalizers/index.html Hi Roger, I briefly skimmed over the webrev, and found the following issue in ProcessImpl: 420

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

2016-01-06 Thread Xueming Shen
On 1/6/16 5:25 AM, KUBOTA Yuji wrote: Hi Sherman, Thank you for your feedback! At first, I'd like to confirm your thought about ZipCryption to prevent misunderstand. By following reasons, we should remove (or modified) ZipCryption to not have any "encryption" related field/method in DeflaterOut

Re: RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base

2016-01-06 Thread Roger Riggs
Hi Peter, Thanks for the review and catching that. Will fix. Roger On 1/6/2016 2:02 PM, Peter Levart wrote: On 01/05/2016 10:16 PM, Roger Riggs wrote: Hi Daniel, webrev updated to revert changes to MeteredStream as too risky. http://cr.openjdk.java.net/~rriggs/webrev-cleaning-finalizers

RFR 9: 8146574 (process) ProcessHandle test cleanup

2016-01-06 Thread Roger Riggs
Please review a few cleanups of the ProcessHandle tests. - Switch to the jdk.test.lib (from lib/testlibrary ) - Cleanup import statements - Remove TEST.properties and use explicit @run testng argument in each test Webrev: http://cr.openjdk.java.net/~rriggs/webrev-testlibrary-8146574/ Is

use of Unsafe for ASCII detection

2016-01-06 Thread Martin Buchholz
Hi guys, It turns out that much of the world's computers is busy doing UTF-8 decoding, so lots of people have expended much effort to make it faster. Much of that text is ASCII, so it's definitely worth having special ASCII-only loops. Like this: static boolean isAscii1(byte[] bytes) { fo

Re: RFR (JAXP): 8144966: Catalog API: Null handling and reference to Reader

2016-01-06 Thread huizhe wang
Thanks Mandy. Please see inline. On 1/4/2016 6:50 PM, Mandy Chung wrote: On Dec 23, 2015, at 2:55 PM, huizhe wang wrote: Hi, This is an improvement to the new Catalog API on null handling. At the package level, a null argument shall result in NPE. However, an exception was made to the metho

RFR (M): 8135250: Replace custom check/range functionality with check index/range methods in java.util.Arrays

2016-01-06 Thread Kharbas, Kishor
Hello all, Requesting the community to review a patch which replaces custom bound checking functionality with calls to methods in java.util.Objects. The methods affected are CounterMode.crypt() and AESCrypt.encryptBlock(), AESCrypt.decryptBlock() Bug id: https://bugs.openjdk.java.net/browse

Re: RFR (JAXP): 8144966: Catalog API: Null handling and reference to Reader

2016-01-06 Thread Mandy Chung
> On Jan 6, 2016, at 4:11 PM, huizhe wang wrote: > > >> >> What if “paths” is non-empty but all entries are invalid and no catalog file >> is read - will it read the system property? > > It will not read the system property. The assumption is that the paths > specified are meant to be used.