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

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

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

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

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

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.

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

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: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

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.

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

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

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

+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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

> 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 >

RFR 9: 8146574 (process) ProcessHandle test cleanup

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/

use of Unsafe for ASCII detection

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) {

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

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:

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

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

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

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.