Re: Files.read/readAllBytes can loop once with zero size buffer

Hi, yes something like that. I have no strong opinion. After discovering this, I switched to a hand rolled implementation with file name depended estimated buffer sizes. But usually inside the JDK, Edge cases are handled better, usually with some Math.min()/Math.max logic. IMHO that really depends

AW: Files.read/readAllBytes can loop once with zero size buffer

Hello, It could always read with a initial buffer of 0.5-16k and return a truncated copy if it read less (and a omit truncation by returning shared static 0 length array if empty). But this will only optimize the 0 byte case. Gruss Bernd -- http://bernd.eckenfels.net >From Win 10 Mobile Von:

Re: RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration which is needed to undeclare default namespace

Hi Christoph, On 7/28/2016 6:10 AM, Langer, Christoph wrote: Hi, please review my change for the XSLT namespace issue. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8162598.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-816

Re: [8u40] RFR 6642881: Improve performance of Class.getClassLoader()

Hi Leela, On 29/07/2016 12:59 PM, Leela Mohan wrote: I think, change in the file unsafe.cpp is incorrect. ( http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ ) Below function is accessing naked oops when thread has transitioned to "native": *+ static jobject get_class_loader(JNIEnv* en

Re: RFR: 8162439: Runtime.Version.parse needs fast-path for major versions

Hi Paul, On 07/28/2016 02:55 PM, Paul Sandoz wrote: On 27 Jul 2016, at 19:36, Claes Redestad wrote: On 07/25/2016 08:01 PM, Iris Clark wrote: Hi, Claes. Webrev: http://cr.openjdk.java.net/~redestad/8162439/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8162439 I think that this c

Re: Files.read/readAllBytes can loop once with zero size buffer

What do you suggest instead? The extra allocation of a zero-size buffer is not that bad. I think it's best to optimize for files with correct metadata, while tolerating ones with buggy metadata. On Thu, Jul 28, 2016 at 1:13 PM, Fabian Lange wrote: > Hi, > I just noticed that when one uses File

Re: JDK 9 RFR of JDK-8162746: VersionCheck.java failure after change for JDK-8160921

Hi Joe: When the binary p2launcher was renamed to jweblauncher (JDK-8160921), the test tools/launcher/VersionCheck.java did not get the corresponding update and started failing. Please review the patch below to address this. Looks good to me. Thanks- Tim Thanks, -Joe --- a/test/tools

JDK 9 RFR of JDK-8162746: VersionCheck.java failure after change for JDK-8160921

Hello, When the binary p2launcher was renamed to jweblauncher (JDK-8160921), the test tools/launcher/VersionCheck.java did not get the corresponding update and started failing. Please review the patch below to address this. Thanks, -Joe --- a/test/tools/launcher/VersionCheck.javaThu J

Re: RFR: 6543126: Level.known can leak memory

On 28/07/16 21:31, James Perkins wrote: I just happened to take a glance at this and noticed the remove method on the KnownLevels doesn't quite look right. Using Optional.of(nameToLevels.get(mirroredLevel.name)).ifPresent((x) -> x.remove(this)); will produce an NPE if the level is not present. If

Re: RFR: 6543126: Level.known can leak memory

I just happened to take a glance at this and noticed the remove method on the KnownLevels doesn't quite look right. Using Optional.of(nameToLevels.get(mirroredLevel.name)).ifPresent((x) -> x.remove(this)); will produce an NPE if the level is not present. If the intention is that the levels may not

Files.read/readAllBytes can loop once with zero size buffer

Hi, I just noticed that when one uses Files.readAllBytes() to read for example from the Linux proc file system, where file size is claimed to be 0, Files.read() will allocate a buffer of size 0 before then adjusting in a second loop (arraycopying the zero size buffer) In my opinion an initial size

Re: RFR: 8158295 Add a multi-release jar validation mechanism to jar tool

I’ve updated the webrev to incorporate the changes suggested by Oleg Barbashov. This changeset has a couple of minor changes to the tests and I’ve changed the Validator class to be an instance of Consumer. http://cr.openjdk.java.net/~sdrach/8158295/webrev.03/index.html

Re: RFR: 8158295 Add a multi-release jar validation mechanism to jar tool

> On Jul 28, 2016, at 11:59 AM, Oleg G. Barbashov > wrote: > > 27.07.2016 15:34, Oleg G. Barbashov пишет: >> >> 07.07.2016 23:32, Steve Drach пишет: >>> Hi, >>> >>> Please review the following: >>> >>> webrev: http://cr.openjdk.java.net/~sdrach/8158295/webrev.01/ >>>

Re: RFR: 8158295 Add a multi-release jar validation mechanism to jar tool

27.07.2016 15:34, Oleg G. Barbashov пишет: 07.07.2016 23:32, Steve Drach пишет: Hi, Please review the following: webrev: http://cr.openjdk.java.net/~sdrach/8158295/webrev.01/ issue: https://bugs.openjdk.java.net/browse/JDK-8158295

Re: RFR [9] 8134779 & 8134847: Minor usability issues with the jmod tool

On 28/07/2016 17:30, Chris Hegarty wrote: This is a minor change for a couple of usability issues with the jmod tool. It now issues a warning when it encounters duplicate entries, or an out of place module-info.class. http://cr.openjdk.java.net/~chegar/8134779_8134847/ This looks okay to me.

RFR [9] 8134779 & 8134847: Minor usability issues with the jmod tool

This is a minor change for a couple of usability issues with the jmod tool. It now issues a warning when it encounters duplicate entries, or an out of place module-info.class. http://cr.openjdk.java.net/~chegar/8134779_8134847/ https://bugs.openjdk.java.net/browse/JDK-8134779 https://bugs.openjdk

Re: RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration which is needed to undeclare default namespace

Hi Christoph, On 28/07/16 16:05, Langer, Christoph wrote: Looks good in general, even though the idiom >if (existing instanceof Stack) > caught my eye. I didn't like it either but found no better way to get rid of the warnings. If you have a better idea here, let me know :) The followin

Re: Change of the toString implementation for annotations

Another remark about "printability". Array types are printed in their internal form, i.e. "java.lang.Void[].class" becomes "Ljava.lang.Void;.class" in the string form. While I very much agree over the improvements of the toString implementation of the unresolved values, I still wonder if this spec

RE: RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration which is needed to undeclare default namespace

Hi Daniel, thanks for reviewing. Here my comments: > Looks good in general, even though the idiom >if (existing instanceof Stack) > caught my eye. I didn't like it either but found no better way to get rid of the warnings. If you have a better idea here, let me know :) > Thanks for the new

Re: RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration which is needed to undeclare default namespace

Hi Christoph, Looks good in general, even though the idiom if (existing instanceof Stack) caught my eye. Thanks for the new test! I wonder if it should be made more strict - with a golden record of the expected results. In particular, to check that the xmlns="" in element is removed only whe

Re: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access

Paul, I have marked this bug (JDK-8162458) as an 'integration_blocker' in order to keep JDK-8151163 from leaving JDK9-hs in its current state. Dan On 7/28/16 4:33 AM, Paul Sandoz wrote: Hooking in nio dev. I think this issue is important to review/push soon (i.e. this week) so as it does no

Re: RFR [9] 8156824: com.sun.jndi.ldap.pool.PoolCleaner should clear its context class loader

On 28/07/16 15:11, Chris Hegarty wrote: On 28 Jul 2016, at 14:52, Daniel Fuchs wrote: > > On 28/07/16 14:22, Chris Hegarty wrote: >> Another issue where an internal platform thread is unnecessarily >> retaining a reference to its creating thread’s context class loader. >> In this case, it appea

Re: RFR [9] 8156824: com.sun.jndi.ldap.pool.PoolCleaner should clear its context class loader

> On 28 Jul 2016, at 14:52, Daniel Fuchs wrote: > > On 28/07/16 14:22, Chris Hegarty wrote: >> Another issue where an internal platform thread is unnecessarily >> retaining a reference to its creating thread’s context class loader. >> In this case, it appears to be safe to use an InnocuousThread

Re: RFR [9] 8156824: com.sun.jndi.ldap.pool.PoolCleaner should clear its context class loader

On 28/07/16 14:22, Chris Hegarty wrote: Another issue where an internal platform thread is unnecessarily retaining a reference to its creating thread’s context class loader. In this case, it appears to be safe to use an InnocuousThread, which will have a null context class loader. http://cr.open

Re: RFR [9] 8156824: com.sun.jndi.ldap.pool.PoolCleaner should clear its context class loader

On 28/07/2016 14:22, Chris Hegarty wrote: Another issue where an internal platform thread is unnecessarily retaining a reference to its creating thread’s context class loader. In this case, it appears to be safe to use an InnocuousThread, which will have a null context class loader. http://cr.o

Re: Change of the toString implementation for annotations

Hi Joe, thank you for your answer. Can I ask for the rationale of using {} instead of [] only for classes? If the goal was to come closer to the source code representation, would this not imply to use curly braces for all array of an annotation? Thank you for your time! Best regards, Rafael 2016-0

RFR [9] 8156824: com.sun.jndi.ldap.pool.PoolCleaner should clear its context class loader

Another issue where an internal platform thread is unnecessarily retaining a reference to its creating thread’s context class loader. In this case, it appears to be safe to use an InnocuousThread, which will have a null context class loader. http://cr.openjdk.java.net/~chegar/8156824/01/ https://b

RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration which is needed to undeclare default namespace

Hi, please review my change for the XSLT namespace issue. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8162598.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8162598 The issue has already been discussed in this thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/0425

Re: RFR: 8162439: Runtime.Version.parse needs fast-path for major versions

> On 27 Jul 2016, at 19:36, Claes Redestad wrote: > > On 07/25/2016 08:01 PM, Iris Clark wrote: >> Hi, Claes. >> >>> Webrev: http://cr.openjdk.java.net/~redestad/8162439/webrev.01/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162439 >> I think that this change looks good. We provide a sh

Re: RFR [9] 8157570: sun.rmi.transport.GC retains a strong reference to the context class loader ( was :8160513 )

Hi Chris, Looks good to me! best regards, -- daniel On 28/07/16 12:40, Chris Hegarty wrote: On 28 Jul 2016, at 12:28, Alan Bateman wrote: On 28/07/2016 11:22, Chris Hegarty wrote: [ switching to 8157570 as it better describes the issue, rather than the affect ] Looks good to me Chris

Re: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access

> On 28 Jul 2016, at 12:40, Alan Bateman wrote: > > On 27/07/2016 12:47, Paul Sandoz wrote: > >> Hi, >> >> I made an embarrassing mistake in the fix for >> >> https://bugs.openjdk.java.net/browse/JDK-8151163 >> All Buffer implementations should leverage Unsafe unaligned accessors >> >> T

Re: RFR: 8160605: java/util/SplittableRandom/SplittableRandomTest.java failed with timeout

> On 27 Jul 2016, at 19:42, Martin Buchholz wrote: > > Hi Paul, > > This deletes the testng ports of jsr166 tck random tests. > > If you can remember doing any work worth keeping, other than explicitly > testing -Djava.util.secureRandomSeed=true (which we are adding to our tck > tests), let

Re: RFR [9] 8157570: sun.rmi.transport.GC retains a strong reference to the context class loader ( was :8160513 )

On 28/07/2016 12:40, Chris Hegarty wrote: Thanks for the review Alan. Webrev updated in-place http://cr.openjdk.java.net/~chegar/8157570/ Looks good.

Re: RFR [9] 8157570: sun.rmi.transport.GC retains a strong reference to the context class loader ( was :8160513 )

On 28 Jul 2016, at 12:28, Alan Bateman wrote: > > On 28/07/2016 11:22, Chris Hegarty wrote: > >> [ switching to 8157570 as it better describes the issue, rather than the >> affect ] >> >> >>> Looks good to me Chris. >>> Another possibility might be to use InnocuousThread? >> Good idea Daniel.

Re: RFR [9] 8157570: sun.rmi.transport.GC retains a strong reference to the context class loader ( was :8160513 )

On 28/07/2016 11:22, Chris Hegarty wrote: [ switching to 8157570 as it better describes the issue, rather than the affect ] Looks good to me Chris. Another possibility might be to use InnocuousThread? Good idea Daniel. I updated the webrev to use InnocuousThread, and added an assert, since

Re: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access

On 27/07/2016 12:47, Paul Sandoz wrote: Hi, I made an embarrassing mistake in the fix for https://bugs.openjdk.java.net/browse/JDK-8151163 All Buffer implementations should leverage Unsafe unaligned accessors The offset calculation for Unsafe access was incorrect, it’s easy to get conf

Re: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access

Hooking in nio dev. I think this issue is important to review/push soon (i.e. this week) so as it does not leak out beyond the hs repo. — Incidentally this patch also fixes what might have been a long standing bug in the compact method of buffer views. Here is ByteBufferAsIntBufferB’s compact

RE: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

Hi Daniel Thank you very much for your comments! Please check my reply inline below: > > Hi Frank, > > Please see my comments inline. > > On 27/07/16 10:27, Frank Yuan wrote: > > Hi Daniel > > > > Would you like to have a look at the following changes before I finish all > > rework? > > It sh

RFR [9] 8157570: sun.rmi.transport.GC retains a strong reference to the context class loader ( was :8160513 )

[ switching to 8157570 as it better describes the issue, rather than the affect ] > Looks good to me Chris. > Another possibility might be to use InnocuousThread? Good idea Daniel. I updated the webrev to use InnocuousThread, and added an assert, since this is no test. http://cr.openjdk.java.n

RE: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

> > +/* > > + * Install a SecurityManager along with a default Policy to allow > > testNG to > > + * run when there is a security manager. > > + */ > > +private JAXPPolicyManager() { > > +// Backing up policy and security manager for restore > > +policyBackup =