RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs)

Hi, i wanted to start a discussion/review-process for JDK5108778 some time ago. Please see a previous try below. The patches are now pretty old, and I will rebase and update them to the created sub-issues - JDK-8143008 (jaxp) - JDK-8143009 (jaxws) - JDK-8143010 (corba) for a sub-repo-discussion/

Re: RFR (JAXP): 8072081 : Supplementary characters are rejected in comments

Thanks Lance! Yes, all tests passed. Best, Joe On 12/9/2015 6:43 PM, Lance @ Oracle wrote: Hi joe, Looks ok. Assume the jck runs clean as well? Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Orac

Re: RFR 8144675: Add a filtering collector

Hi Shinya, Thanks for doing this work. This looks very nice! (And thanks to Paul for helping move it through the process.) I have only a minor comment, which is that it might be good to clarify in the example why a filtering collector is necessary instead of just adding a filter() step into

Re: RFR (JAXP): 8072081 : Supplementary characters are rejected in comments

Hi joe, Looks ok. Assume the jck runs clean as well? Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad > On Dec 9, 2015, at 5:37 PM, huizhe wang wrote: > >

Re: [9] RFR of 8032027: Add BigInteger square root methods

Guava's tests check the explicit definition of square root (mentioned by Joe above) on 2^n +/- 1 for all n up to Double.MAX_EXPONENT + 1, because why not? On Wed, Dec 9, 2015 at 6:12 PM Joseph D. Darcy wrote: > Hi Brian, > > New version looks good. > > One more case to try: start with a BigInteg

Re: [9] RFR of 8032027: Add BigInteger square root methods

Hi Brian, New version looks good. One more case to try: start with a BigInteger that would overflow to Double.POSITIVE_INFINITY when the doubleValue method was called. If this case doesn't take too long to run, it would be a fine additional case to add to the test. 2^1024 should be fine input

question on jdk_collections group in jdk/test/TEST.groups

Hi, maybe somebody can fill me in on the history here. There's a nice test group called jdk_collections defined in jdk/test/TEST.groups. It runs the tests for the collections in java/util (but not java/util/concurrent) and it excludes all the stuff in java/util that isn't collections-related.

Re: [9] RFR of 8032027: Add BigInteger square root methods

Hi Joe, On Dec 1, 2015, at 7:25 PM, Joseph D. Darcy wrote: > Current version looks okay. One more request, before pushing please add > explicit test cases for the for the largest number having 63 bits and the > smallest number having 64 bits. No need for another round of webrevs for that. Wel

Re: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type

Hi Joel, Sorry for the delay in reviewing. For the specification, it should seem reasonable to me to have the default implementation of AnnotatedType.getAnnotatedOwnerType() to return null rather than throwing an UnsupportedOperationException. Following experience with similar structures in

Re: RFR(s): JDK-8144952: add wildcards to the Map.ofEntries() method

Looks fine Stuart; thanks, -Joe On 12/9/2015 4:22 PM, Stuart Marks wrote: Hi all, Joe Darcy pointed out that API changes I pushed into jdk9-dev yesterday are missing wildcards from the Map.ofEntries() method. Please see this bug: https://bugs.openjdk.java.net/browse/JDK-8144952 The Map

RFR(s): JDK-8144952: add wildcards to the Map.ofEntries() method

Hi all, Joe Darcy pointed out that API changes I pushed into jdk9-dev yesterday are missing wildcards from the Map.ofEntries() method. Please see this bug: https://bugs.openjdk.java.net/browse/JDK-8144952 The Map.ofEntries() method currently has the following declaration: static Map of

Re: RFR(m): updated: JEP 269 initial API and skeleton implementation (JDK-8139232)

On 12/8/15 6:58 AM, Maurizio Cimadamore wrote: I'm not too worried about the fact that typing 'EnumSet' is more verbose than just 'Set', obviously; but it would seem reasonable to try (within reasonable bounds) to provide uniform way to create collections and a smooth user experience. I think

Re: RFR: jsr166 jdk9 integration wave 2

I finally studied ForkJoinTask.getThrowableException - I was not aware that we were doing reflection based exception cloning. In practice it probably muddles through, but it just seems too hacky to use in a java core library. We're relying on common conventions, but in principle we are invoking r

RFR (JAXP): 8072081 : Supplementary characters are rejected in comments

Hi, Please review https://bugs.openjdk.java.net/browse/JDK-8072081. Supplementary characters are supported as character data in xml 1.0, and also names in xml 1.1. This patch fixed the bug that rejected supplementary characters in comments, and also made sure they are accepted in names. we

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

On 8 Dec 2015, at 14:49, David M. Lloyd wrote: > Great! Now all we need is a way to tell threads to remove all thread locals > on exit, and the scourge of ITL might be somewhat mitigated. :-) David, The fields of Thread that hold references to TLs and ITLs are cleared at exit, as seen from the

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

David, Mandy, Mark, Roger, Thanks for your feedback. I understand that ‘stackSize’ is rarely used, but to avoid having to provide more than one additional constructor I opted to keep it. If someone really wants to create a Thread with a specific stack size and not inherit initial inheritable threa

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi, The example is revised to caution about inner classes and lambdas. [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html Thanks, Roger On 12/9/2015 11:04 AM, Peter Levart wrote: Hi Chris, On 12/09/2015 04:03 PM, Chris H

Re: RFR(XS): 8143127: InvokerBytecodeGenerator emitConst should handle Byte, Short, Character

On Dec 2, 2015, at 5:24 AM, Claes Redestad wrote: > > Picking up this tiny improvement again, I realized there are a few other > bytecode minifying tricks we could consider while we're at it: > > http://cr.openjdk.java.net/~redestad/8143127/webrev.02/ >

Re: Potential performance improvement for java.util.AbstractList?

On Tue, Dec 8, 2015 at 10:17 PM, Nicholas Cull wrote: > Yes, the time performance of size() appears to be unspecified by the whole > Collections framework: the implementation of equals() in AbstractSet uses > size() as an optimization, though AbstractCollection does not. Naively it > seems > odd

Re: RFR(XS): 8143127: InvokerBytecodeGenerator emitConst should handle Byte, Short, Character

Thanks Vladimir! /Claes On 2015-12-09 13:10, Vladimir Ivanov wrote: Looks good. Best regards, Vladimir Ivanov On 12/2/15 4:24 PM, Claes Redestad wrote: On 2015-11-18 23:26, Aleksey Shipilev wrote: By the way, I see there is a cleaner way to implement emitIconstInsn, see java.lang.invoke.Ty

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

2015/12/8 5:36 -0800, david.hol...@oracle.com: > On 9/12/2015 12:15 AM, Chris Hegarty wrote: >> ... >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/8056152/00/webrev/ > > Addition to Thread looks good to me. > > I vote in favor of maintaining consistency of the existing Thread > constructio

Re: RFR [9] Remove sun.misc.Unsafe dependency from sun.nio.cs.StringUTF16

+1 On 12/9/15 3:44 AM, Chris Hegarty wrote: Looks like the Compact Strings work inadvertently introduced a dependency on sun.misc.Unsafe. ( just temporary confusion with having two Unsafes until the jdk.unsupported module is defined ) diff --git a/src/java.base/share/classes/sun/nio/cs/StringUT

Re: 8141370: com/sun/jndi/ldap/LdapTimeoutTest.java failed intermittently

This change to restructure the test looks fine. Thanks. > On 8 Dec 2015, at 16:11, Rob McKenna wrote: > > Thanks, just spotted that myself after attempting to run it in a loop via > jtreg. (in case jtreg is somehow involved in causing the intermittent > failure) Will be corrected pre-push. >

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Chris, On 12/09/2015 04:03 PM, Chris Hegarty wrote: Peter, On 09/12/15 07:05, Peter Levart wrote: Hi, I think the only way to try to prevent such things is with a good example in javadoc that "screams" of possible miss-usages. public static class CleanerExample implements AutoCloseable {

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Peter, On 09/12/15 07:05, Peter Levart wrote: Hi, I think the only way to try to prevent such things is with a good example in javadoc that "screams" of possible miss-usages. public static class CleanerExample implements AutoCloseable { private static final Cleaner cleaner = ...; //

Re: [PING-2] RFR 6425769: jmx remote bind address

On Wed, 2015-12-09 at 14:58 +0100, Jaroslav Bachorik wrote: > On 9.12.2015 14:55, Severin Gehwolf wrote: > > On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: > > > Hi Jaroslav, > > > > > > On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > > > > On 1.12.2015 11:17, Severin Gehw

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Unfortunately I think you're right that docs with loud warnings is the best that can be done here. But this will become fertile ground for leaks nonetheless. IDEs will need to be taught not to suggest any refactoring that may start capturing 'this'. sent from my phone On Dec 9, 2015 2:05 AM, "Pe

Re: [PING-2] RFR 6425769: jmx remote bind address

On 9.12.2015 14:55, Severin Gehwolf wrote: On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: Hi Jaroslav, On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: On 1.12.2015 11:17, Severin Gehwolf wrote: On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: On Wed, 2015-11-0

Re: [PING-2] RFR 6425769: jmx remote bind address

On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: > Hi Jaroslav, > > On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > > On 1.12.2015 11:17, Severin Gehwolf wrote: > > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > > > > On Wed, 2015-11-04 at 11:54 +0100, Severin

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

At the risk of going off topic with respect to this thread, I really think java should allow specifying at least what should be captured explicitly (if unspecified, behaves like today). It's counterintuitive that capturing just a field of 'this' captures the entire object, although some other lang

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/ The hotspot changes look good to me. Roland.

RE: ConcurrentMap::compute clarification

Yes, I think the containsKey check is just not appropriate here. Doing the check means the information gained from reading oldValue becomes immediately stale. This means oldValue has to be read again. But reading oldValue means the information received from the check on whether the loop has to r

Re: RFR(XS): 8143127: InvokerBytecodeGenerator emitConst should handle Byte, Short, Character

Looks good. Best regards, Vladimir Ivanov On 12/2/15 4:24 PM, Claes Redestad wrote: On 2015-11-18 23:26, Aleksey Shipilev wrote: By the way, I see there is a cleaner way to implement emitIconstInsn, see java.lang.invoke.TypeConvertingMethodAdapter.iconst: void iconst(final int cst) {

Re: RFR [9] Remove sun.misc.Unsafe dependency from sun.nio.cs.StringUTF16

+1 Paul. > On 9 Dec 2015, at 12:44, Chris Hegarty wrote: > > Looks like the Compact Strings work inadvertently introduced a > dependency on sun.misc.Unsafe. ( just temporary confusion with > having two Unsafes until the jdk.unsupported module is defined ) > > diff --git a/src/java.base/share/c

RFR [9] Remove sun.misc.Unsafe dependency from sun.nio.cs.StringUTF16

Looks like the Compact Strings work inadvertently introduced a dependency on sun.misc.Unsafe. ( just temporary confusion with having two Unsafes until the jdk.unsupported module is defined ) diff --git a/src/java.base/share/classes/sun/nio/cs/StringUTF16.java b/src/java.base/share/classes/sun/ni

Re: ConcurrentMap::compute clarification

Hi Paul, many thanks for confirmation. I'm going to fill the bug. Cheers, Jaromir On Wed, Dec 9, 2015 at 1:21 PM, Paul Sandoz wrote: > Hi Jaromir, > > Thanks, you found a bug, seems to be a hangover from the Map default > implementation. > > One fix might be: > > if (oldValue != null) { >

Re: ConcurrentMap::compute clarification

Hi Jaromir, Thanks, you found a bug, seems to be a hangover from the Map default implementation. One fix might be: if (oldValue != null) { // something to remove if (remove(key, oldValue)) { // removed the old value as expected return null; } // some other value

Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

The logic looks fine. In the main code, this part .getLong(INSTANT_SECONDS); can be replaced with .toEpochSecond(); which will be slightly faster. In the test case, this part .plus(15, ChronoUnit.MINUTES); can be replaced with .plusMinutes(15) And .with(ChronoField.OFFSET_SECONDS, ZoneOff

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 12/09/2015 08:54 AM, David Holmes wrote: On 9/12/2015 5:05 PM, Peter Levart wrote: Hi, I think the only way to try to prevent such things is with a good example in javadoc that "screams" of possible miss-usages. Problem is that many people - myself included - would not have a clue when