Re: RFR: JDK-8066013 (prefs) Unused variable in src/java.prefs/share/classes/java/util/prefs/MacOSXPreferences.java

Your change [1] looks fine to me Steve. -Chris. [1] diff --git a/src/java.prefs/macosx/classes/java/util/prefs/MacOSXPreferences.java b/src/java.prefs/macosx/classes/java/util/prefs/MacOSXPreferences.java --- a/src/java.prefs/macosx/classes/java/util/prefs/MacOSXPreferences.java +++

8139891: Prepare Unsafe for true encapsulation

As part of the preparation for JEP 260 [1], Unsafe needs to be separable from the base module [2], so it can be exported by a new, yet to be defined, jdk.unsupported module, and have a separate evolution policy that is not exposed. That is, the JDK needs an internal Unsafe that can be evolved and

Re: RFR [9] 8140606: Update library code to use internal Unsafe

On 28 Oct 2015, at 22:14, Alan Bateman <alan.bate...@oracle.com> wrote: > On 28/10/2015 19:55, Chris Hegarty wrote: >> Following on from 8139891 "Prepare Unsafe for true encapsulation” [1], >> the JDK library code should use the internal Unsafe class, and not >&

Re: RFR [9] 8140606: Update library code to use internal Unsafe

until VarHandles arrive. Since the major 166 sync is done, the amount of change in this area should be small. I can help out with incoming changes also, until you fork. -Chris. > On Wed, Oct 28, 2015 at 12:55 PM, Chris Hegarty <chris.hega...@oracle.com> > wrote: > Following

Re: RFR: 6823565: Excessive use of HandleList class in de-serialization code causes OutOfMemory

On 27 Oct 2015, at 13:56, Aleksey Shipilev wrote: > On 10/27/2015 04:51 PM, Claes Redestad wrote: >> >> >> On 2015-10-27 14:21, Aleksey Shipilev wrote: >>> On 10/25/2015 04:27 AM, Claes Redestad wrote: when deserializing objects with references to themselves,

RFR [9] 8140606: Update library code to use internal Unsafe

Following on from 8139891 "Prepare Unsafe for true encapsulation” [1], the JDK library code should use the internal Unsafe class, and not sun.misc.Unsafe. http://cr.openjdk.java.net/~chegar/8140606/00/ This will be pushed to jdk9/dev once 8139891 makes its way from hs-rt. -Chris. [1]

Re: 8139891: Prepare Unsafe for true encapsulation

Thanks for looking at this John. Comments inline… On 23 Oct 2015, at 02:06, John Rose <john.r.r...@oracle.com> wrote: > On Oct 22, 2015, at 7:28 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: >> >> To this end I've put together a webrev containing the cha

Re: 8139891: Prepare Unsafe for true encapsulation

put for the aliasing in case >> internal refactoring messes things up. Possibly. CheckIntrinsics, in a fast debug build, will catch if there is a mismatch. I hope to also add some new tests to the hotspot forest to make sure Unsafe continues to work as expected. -Chris. >> Paul. >&

Re: 8139891: Prepare Unsafe for true encapsulation

On 23/10/15 10:14, Andrew Haley wrote: On 22/10/15 15:48, Christoph Engelbert wrote: I don’t like to say it but it sounds very wrong to have another Unsafe like thinggy in the future instead of providing public alternatives right from the start. I agree it might be a faster to just write

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

On 09/11/15 12:34, Peter Levart wrote: On 11/09/2015 01:32 PM, Peter Levart wrote: On 11/09/2015 11:43 AM, Chris Hegarty wrote: On 02/11/15 10:45, Aleksey Shipilev wrote: On 11/02/2015 02:56 AM, Chris Hegarty wrote: In line with the intended location for other VM annotations, see 8138732

Re: 8141652 : Rename methods Objects.nonNullElse* to requireNonNullElse*

On 10 Nov 2015, at 18:55, Roger Riggs wrote: > A few of the proposed replacements of ?: with requireNonNullElse were > unsuitable > because in the particular context, null is an allowed replacement value. > > The webrev has been updated to revert changes: > - two uses

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

On 11 Nov 2015, at 13:11, Doug Lea <d...@cs.oswego.edu> wrote: > On 11/11/2015 07:06 AM, Chris Hegarty wrote: > >>>>>> http://cr.openjdk.java.net/~chegar/8140687/00/ >>>>> >>> >>> While this is up for review, could someone

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

On 9 Nov 2015, at 12:49, Doug Lea <d...@cs.oswego.edu> wrote: > On 11/09/2015 05:43 AM, Chris Hegarty wrote: >> On 02/11/15 10:45, Aleksey Shipilev wrote: >>> On 11/02/2015 02:56 AM, Chris Hegarty wrote: >>>> In line with the intended location for other

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

To me, it sounds like @Contended, in its current form, is not quite ready for prime-time ( inclusion in Java SE 9 ). There is some concern about its implementation, and I’m not sure how the loader restriction, and the control through a -XX flag, would translate into SE spec. There is certainly

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

On 02/11/15 10:45, Aleksey Shipilev wrote: On 11/02/2015 02:56 AM, Chris Hegarty wrote: In line with the intended location for other VM annotations, see 8138732 [1], @sun.misc.Contended should be moved to the jdk.internal.vm.annotation package. http://cr.openjdk.java.net/~chegar/8140687/00

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

> On 2 Nov 2015, at 12:54 a.m., David Holmes <david.hol...@oracle.com> wrote: > > Hi Chris, > > hotspot and jdk changes look fine to me. Thanks for looking at this David. -Chris. > Thanks, > David > >> On 2/11/2015 9:56 AM, Chris Hegarty wrote: &

RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

In line with the intended location for other VM annotations, see 8138732 [1], @sun.misc.Contended should be moved to the jdk.internal.vm.annotation package. http://cr.openjdk.java.net/~chegar/8140687/00/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8138732

Re: java.lang.reflect.Method.copyOf

On 14 Oct 2015, at 15:15, Remi Forax wrote: > - Mail original - >> De: "Paul Sandoz" >> Cc: "core-libs-dev" >> Envoyé: Mercredi 14 Octobre 2015 13:46:38 >> Objet: Re: java.lang.reflect.Method.copyOf >> >> >>>

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

Peter, On 15 Oct 2015, at 09:12, Peter Levart wrote: > On 10/14/2015 07:43 PM, Roger Riggs wrote: >> Hi Alan, Mandy, >> >> I looked at a few of the many uses of finalize and the likely changes. >> The zip Inflater and Deflater are relatively simple cases. >> Some

Re: RFR (xs) : 8038502: Deflater.needsInput() should use synchronization

Looks good to me Sean. All other state seems to be accessed when holding zsRef. -Chris. On 15 Oct 2015, at 10:02, Seán Coffey wrote: > bug report : https://bugs.openjdk.java.net/browse/JDK-8038502 > > The len instance variable should be read/written while holding the

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

Roger, On 14 Oct 2015, at 18:43, Roger Riggs wrote: > Hi Alan, Mandy, > > I looked at a few of the many uses of finalize and the likely changes. > The zip Inflater and Deflater are relatively simple cases. > Some finalizers are not used and can be removed. It is not

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

On 15 Oct 2015, at 14:21, Roger Riggs wrote: > ... > > Also, I've seen a few calls to super.finalize() where there were no finalizers > in any of the superclasses. It would be considered good design to always > include it. > I don't know if the optimization for empty

Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils

On 7 Oct 2015, at 20:15, Chris Hegarty <chris.hega...@oracle.com> wrote: > On 7 Oct 2015, at 20:04, Alan Bateman <alan.bate...@oracle.com> wrote: > >> On 07/10/2015 19:19, Chris Hegarty wrote: >>> This primary motivation behind this bug [1] is the clearing ou

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On 7 Oct 2015, at 23:44, Stephen Colebourne wrote: > On 7 October 2015 at 23:24, Roger Riggs wrote: >> Please consider and comment: >> >> T nonNullOf(T obj, T defaultObj); >> T nonNullOf(T, obj, Supplier defaultSupplier); >> >> Details are

Re: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes

> On 15 Oct 2015, at 21:59, e...@zusammenkunft.net wrote: > > Hello, > > This does change a bit the semantic of the length check. If the stream would > return more bytes than the zipentry says the new version would ignore them, > the old version was consuming then and then fail the check.

Re: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes

> On 15 Oct 2015, at 11:08 p.m., Claes Redestad <claes.redes...@oracle.com> > wrote: > > > On 2015-10-15 23:21, Chris Hegarty wrote: >>> On 15 Oct 2015, at 21:59, e...@zusammenkunft.net wrote: >>> >>> Hello, >>> >>> This

Re: JDK 9 RFR of JDK-8139925 Problem list LFMultiThreadCachingTest.java on windows

Looks fine Joe. -Chris. > On 19 Oct 2015, at 8:43 p.m., joe darcy wrote: > > Hello, > > Please review the fix below to address > >JDK-8139925: Problem list LFMultiThreadCachingTest.java on windows > > The test in question, > >

Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils

> On 8 Oct 2015, at 13:34, Sean Mullan <sean.mul...@oracle.com> wrote: > > Looks fine to me, though I have one question below. Thanks for looking at this Sean. > On 10/7/15 2:19 PM, Chris Hegarty wrote: >> This primary motivation behind this bug [1] is the cle

Re: JDK 9 RFR of JDK-8139407: Mark java/rmi/registry/readTest/readTest.sh as intermittently failing

Looks ok to me Amy. -Chris. On 12/10/15 09:27, Amy Lu wrote: Test java/rmi/registry/readTest/readTest.sh is known to fail intermittently, this patch is to mark the test accordingly with keyword 'intermittent'. bug: https://bugs.openjdk.java.net/browse/JDK-8139407 webrev:

Re: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException

On 12 Oct 2015, at 17:54, Mandy Chung wrote: > >> On Oct 12, 2015, at 8:09 AM, Vyom Tewari wrote: >> >> Hi All, >> >> Please review my changes for below bug. >> >> Bug:JDK-8068887 : java.lang.Throwable could use >>

Re: JEP 269: Convenience Factory Methods for Collections

On 7 Oct 2015, at 10:30, Stephen Colebourne wrote: > On 7 October 2015 at 01:13, Stuart Marks wrote: >> My question is, is this enough of a problem that we should allow nulls in >> these collections? I would prefer not to do this, but if there is

Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils

On 7 Oct 2015, at 20:04, Alan Bateman <alan.bate...@oracle.com> wrote: > On 07/10/2015 19:19, Chris Hegarty wrote: >> This primary motivation behind this bug [1] is the clearing out of >> sun.misc, in preparation for JEP 260 [2]. >> >> > It would be nice

RFR [9] 8138978: Examine usages of sun.misc.IOUtils

This primary motivation behind this bug [1] is the clearing out of sun.misc, in preparation for JEP 260 [2]. sun.misc.IOUtils is a JDK internal convenience utility class that provides a single method that offers bulk blocking InputStream read semantics. In 9, java.io.InputStream has been

Re: Array equality, comparison and mismatch

On 7 Oct 2015, at 16:55, Paul Sandoz <paul.san...@oracle.com> wrote: > >> On 6 Oct 2015, at 10:58, Chris Hegarty <chris.hega...@oracle.com> wrote: >>>> It was not immediately obvious to me that the common prefix can be 0. >>>> Should this be called

Re: Array equality, comparison and mismatch

On 6 Oct 2015, at 09:50, Paul Sandoz <paul.san...@oracle.com> wrote: >> >> On 5 Oct 2015, at 17:35, Chris Hegarty <chris.hega...@oracle.com> wrote: >> >> Paul, >> >> On 22/09/15 17:30, Paul Sandoz wrote: >>> Hi, >>> >>&

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

On 1 Oct 2015, at 15:12, Roger Riggs wrote: > …. > > Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/ > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ This is nice addition. Some comments / questions: 1) Should the behaviour,

RFR [9] 8139307: Remove sun.misc.ConditionLock and Lock

The functionality provided by these classes has long since been provided by supported APIs in java.util.concurrent.locks. Nothing internal, or external ( to the best of my knowledge ), to the JDK is depending on these classes. They should simply be removed. $ hg rm

Re: RFC: draft API for JEP 269 Convenience Collection Factories

On 09/10/15 13:08, Peter Levart wrote: Hi, On 10/09/2015 04:39 AM, Paul Benedict wrote: I don't think the statements "Creates an unmodifiable set containing X elements" is always true. Since sets cannot have duplicates, it's possible passing in X elements gives you less than that based on

Re: RFR [9] 8139307: Remove sun.misc.ConditionLock and Lock

On 9 Oct 2015, at 19:51, Stuart Marks <stuart.ma...@oracle.com> wrote: > On 10/9/15 10:23 AM, Chris Hegarty wrote: >> The functionality provided by these classes has long since been provided >> by supported APIs in java.util.concurrent.locks. Nothing internal, or >>

RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate

This is a little temporary solution to get the jrt-fs up and running again with JDK 8, until JDK-8137017 [1] can be resolved. It is fair game for an unchecked Exception or Error thrown during class initialization to result in a NCDFE. The code in BasicImageReader should catch

Re: RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate

On 9 Oct 2015, at 20:26, Alan Bateman wrote: > I looked more closely at this and I think it's best to handle NCDFE rather > than the more general LinkageError. Ok, I make the follow change before pushing: diff --git

Re: RFR <8064470 > JNI exception pending in jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c

Hi Vyom, On 1 Sep 2015, at 09:38, Vyom Tewari wrote: > Hi everyone, > > Can you please review my changes for below bug. > > Bug: >JDK-8064470 : JNI exception pending in > jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c > > Webrev: >

Re: RFR 8080486: JNI exception pending in jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c

The changes look fine to me too. -Chris. On 04/09/15 16:04, Daniel Fuchs wrote: Hi Vyom, I'm not a net/JNI expert but what you are proposing looks good to me too. Ivan has already given his assent. Unless I hear objections - or comments from other reviewers, I will sponsor this change and

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

Hi Vyom, On 07/09/15 10:26, Vyom Tewari wrote: Hi everyone, Can you please review my changes for below bug. Bug: JDK-8080402 : File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java Webrev: http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/ This change ensure

Re: RFR 8072466: Deadlock when starting MulticastSocket and DatagramSocket

This looks like a nice cleanup, and fix. Thanks Ivan. -Chris. On 05/09/15 15:25, Ivan Gerasimov wrote: Hi everyone! The fix didn't bring enough attention back in February for some reason. So, I'd like to re-request a review. I've added a regression test, which reliably reproduces a deadlock

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

On 7 Sep 2015, at 17:41, Mark Sheppard wrote: > a couple of other considerations in the context of this issue perhaps? > > in this s is being duped onto fd, and part of the dup2 operation is the > closing of fd, but > what's is the expected state of file descriptor

Re: RFR: 8134984: Text files should end in exactly one newline

There was a thread a while back, over on the tools mailing list about the enforcement of this [1]. -Chris. [1] http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-May/thread.html > On 2 Sep 2015, at 21:05, Martin

Re: RFR(m) 2: 8072722: add stream support to Scanner

This looks very nice, just a minor spec comment.. > On 9 Sep 2015, at 01:53, Stuart Marks wrote: > > > > On 9/4/15 1:35 AM, Paul Sandoz wrote: >> Hi Stuart, >> >> This is looking very good. >> >> Just some comments on the tricky aspect related to late-binding of the

Re: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails intermittently - incorrect user

Roger, The timeouts, in this test, are just to ensure that the test does not block indefinitely, if it encounters a bug in the JDK, right? If a timeout is ever triggered then there is a bug, right? If this is the case then, we have used larger timeouts in other areas ( net, concurrency ) to

Re: RFR(m) 2: 8072722: add stream support to Scanner

On 09/09/15 09:37, Paul Sandoz wrote: On 9 Sep 2015, at 10:04, Chris Hegarty <chris.hega...@oracle.com> wrote: << After stream execution completes, this scanner is left in an indeterminate state and cannot be reused. >> I think this note is good, but the webrev/spec

Re: RFR 9: 8132883 : The spec of allChildren/children of j.l.Process/ProcessHandle need to be relaxed

On 10 Sep 2015, at 15:43, Roger Riggs <roger.ri...@oracle.com> wrote: > Hi Chris, > > Corrected, 'the' reads better than 'this' and avoids potential confusion. Looks good. -Chris. > Thanks, Roger > > > On 9/10/2015 10:34 AM, Chris Hegarty wrote: >> These

Re: RFR 9: 8132883 : The spec of allChildren/children of j.l.Process/ProcessHandle need to be relaxed

These spec clarifications look ok to me. Being pedantic, should the ProcessHandle changes say 'the process’, rather than 'this process’? -Chris. On 10 Sep 2015, at 15:17, Roger Riggs wrote: > Please review a couple of clarifications to the >

Re: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails intermittently - incorrect user

nks, -Chris. > Roger > > > On 9/10/2015 9:43 AM, Chris Hegarty wrote: >> Roger, >> >> The timeouts, in this test, are just to ensure that the test does not block >> indefinitely, if it encounters a bug in the JDK, right? If a timeout is >> ever triggered then

Re: RFR 8073542 : File Leak in jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c

The changes look good to me Vyom. -Chris. On 16/09/15 10:08, Vyom Tewari wrote: Hi All, Please review my changes for below bug. Bug: JDK-8073542 : File Leak in jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c Webrev:

Re: RFR: 8136583: Core libraries should use blessed modifier order

Martin, On 16/09/15 01:42, Martin Buchholz wrote: Hi, Chris and Paul, I'd like you to do a very boring code review. This change is entirely machine generated. (the script is more interesting)

Re: RFR: 8136656: Check in blessed-modifier-order.sh

On 16 Sep 2015, at 20:36, Martin Buchholz wrote: > Hi guys, > > Here's the requested script checkin: > > https://bugs.openjdk.java.net/browse/JDK-8136656 > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order.sh/ Looks fine. Just add an appropriate

Re: RFR: 8136656: Check in blessed-modifier-order.sh

On 17 Sep 2015, at 17:08, Martin Buchholz <marti...@google.com> wrote: > Done! The updated webrev ( in-place ) looks good to me Martin. -Chris. > On Thu, Sep 17, 2015 at 1:14 AM, Chris Hegarty <chris.hega...@oracle.com> > wrote: > On 16 Sep 2015, at 20:36, Martin Buchh

Re: RFR 9: 8132735: java/lang/ProcessHandle/TreeTest failed with java.lang.AssertionError: Start with zero children

Looks ok to me Roger. -Chris. On 16 Sep 2015, at 22:44, Roger Riggs wrote: > Please review this test fix so the test code only operates on processes it > spawns. > On Windows, other processes may show up as children that are not part of the > test. > > Webrev: >

Re: JDK 9 RFR of JDK-8137232: Mark 3 more core-libs tests as intermittently failing

Looks fine Amy. -Chris. On 28/09/15 11:58, Amy Lu wrote: Below tests are known to fail intermittently: java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java java/net/NetworkInterface/NetworkInterfaceStreamTest.java

Re: RFR 9: 8137313 : TreeTest.java intermittently fails with a timeout

Adding additional diagnostic information to help find the root cause of the intermittent failures seems like the right thing to do. Reviewed. -Chris. On 30/09/15 15:21, Roger Riggs wrote: Please review an enhancement to the test to help diagnose this failure in the ProcessHandle TreeTest.

Re: RFR: 8137289: java/util/logging/DrainFindDeadlockTest.java hangs

On 29 Sep 2015, at 19:15, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > 8137289: java/util/logging/DrainFindDeadlockTest.java hangs > https://bugs.openjdk.java.net/browse/JDK-8137289 > > webrev: >

Re: RFR 8080418 Add Optional.or()

> On 25 Sep 2015, at 11:58, Paul Sandoz wrote: > > Hi, > > Please review this change to add a method Optional.or that allows one to > better compose optionals: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/ > > I also took the

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 24 Sep 2015, at 08:40, Paul Sandoz wrote: > On 23 Sep 2015, at 18:11, Rémi Forax wrote: >>> >>> Because i want to support the simple cases without pulling in indy. >> >> and what about using an anonymous class instead ? >> > > Not an anonymous

RFR [9] 8137056: Move SharedSecrets and interface friends out of sun.misc

In preparation for JEP 260 "Encapsulate Most Internal APIs” [1], SharedSecrets and friend interfaces should be moved out of 'sun.misc’ [2] and located in a truly private package. This is so that they are not part of the proposed to be exported ‘sun.misc' package.

Re: RFR [9] 8137056: Move SharedSecrets and interface friends out of sun.misc

On 24 Sep 2015, at 15:37, Alan Bateman <alan.bate...@oracle.com> wrote: > On 24/09/2015 15:16, Chris Hegarty wrote: >> In preparation for JEP 260 "Encapsulate Most Internal APIs” [1], >> SharedSecrets and friend interfaces should be moved out of >> 'sun.misc’ [2

Re: [9] RFR: 8061466 - RELAX NG API visible but not accessible

Miran, Did you use 'hg mv’? if so, then webrev ( without a file.list ) typically picks up that the file has moved and only highlights the differences. This typically helps with the review. -Chris. On 24 Sep 2015, at 14:57, Miroslav Kos wrote: > Hi everybody, > > I'd

Re: RFR 9: 8129744 : Documentation in Month refers to quarters

The changes look good to me Roger. -Chris. On 24 Sep 2015, at 14:23, Roger Riggs wrote: > Please review two java.time editorial changes: > - 8129744: a trivial editorial change in java.time.Month javadoc. > - 8129556: TemporalAdjusters dayOfWeekInMonth wrongly says

Re: [9] RFR: 8061466 - RELAX NG API visible but not accessible

On 25/09/15 11:46, Miroslav Kos wrote: On 25/09/15 11:46, Alan Bateman wrote: On 25/09/2015 10:36, Miroslav Kos wrote: Hi, I prepared the webrev again with hg move: http://cr.openjdk.java.net/~mkos/8061466/jaxws.02/index.html For sure, jprt built again and all tests rerun. The move and

Re: RFR: 8132541 : (process) ProcessBuilder support for redirection to discard output

On 21 Sep 2015, at 18:47, Roger Riggs wrote: > Ping? > > Can a Reviewer take a look and comment? Looks good Roger. -Chris. > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/ > > > Thanks, Roger > > > On 09/11/2015 01:11 PM, Remi Forax wrote:

Re: RFR: jsr166 openjdk9 integration

> On 23 Sep 2015, at 20:33, Martin Buchholz wrote: > > On Wed, Sep 23, 2015 at 3:16 AM, Paul Sandoz > wrote: > >> Hi, >> >> I trawled through the patches and could not find anything obvious that >> clobbered

Re: RFR (xs) : 8077874 : [TESTBUG] The test com/sun/corba/cachedSocket/7056731.sh should not be run on JRE

Looks fine to me Sean. -Chris. On 17 Sep 2015, at 14:50, Seán Coffey wrote: > Test bug correction to allow the jdb command to be launched via compilejdk > parameter where necessary. I've checked for similar usage across other corba > tests and this one seems to be the

Re: RFR: JDK-8137088: Drop building of interim_java.corba

On 25/09/15 14:08, Erik Joelsson wrote: Hello, Please review this change to the build of JDK 9, which drops building of interim-corba. The interim build of java.corba has historically been needed for rmic -iiop but it is no longer needed in the build since the JMX remote API dropped support

Re: Array equality, comparison and mismatch

Paul, On 22/09/15 17:30, Paul Sandoz wrote: Hi, Please review the following which adds methods to Arrays for performing equality, comparison and mismatch: https://bugs.openjdk.java.net/browse/JDK-8033148

Re: Pattern.splitAsStream JavaDoc doubt

On 07/12/15 13:55, Paul Sandoz wrote: On 7 Dec 2015, at 11:18, Chris Hegarty <chris.hega...@oracle.com> wrote: Tagir, It would seem most useful to update the implementation to match the current spec. Yes, it’s an oversight and lacked a test for such case. Tagir, thanks for f

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

Many threads created by the platform are short lived and perform some simple async operation on behalf of the platform. These threads typically use/extend sun.misc.ManagedLocalsThread. This is a convenient internal API that can be used to create threads that do not wish to inherit initial values

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

e. The usage pattern of extending Thread is also very common. -Chris. > Roger > > > On 12/08/2015 09:15 AM, Chris Hegarty wrote: >> Many threads created by the platform are short lived and perform some >> simple async operation on behalf of the platform. These thr

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

> On 8 Dec 2015, at 8:19 p.m., Mandy Chung <mandy.ch...@oracle.com> wrote: > > >> On Dec 8, 2015, at 6:50 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: >> >> >>> On 8 Dec 2015, at 14:33, Roger Riggs <roger.ri...@oracle.com> wrote: &

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

Thanks Max, I'm ok with this version, if you are. I'll include it in the final push. -Chris. On 02/12/15 15:13, Wang Weijun wrote: On Dec 2, 2015, at 10:52 PM, Wang Weijun wrote: My fault to use an internal class. I should have simply used the hex encoding. Please

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

Updated to remove all use of reflection. If someone really wants to run S11N on an older JDK, then it is a simple edit to uncomment/comment 3 lines. http://cr.openjdk.java.net/~chegar/Base64-test-updates.01/webrev/ -Chris. On 02/12/15 14:15, Chris Hegarty wrote: On 02/12/15 14:03, Alan

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

t; Amy > >> On 12/2/15 11:03 PM, Chris Hegarty wrote: >> Updated to remove all use of reflection. If someone really >> wants to run S11N on an older JDK, then it is a simple >> edit to uncomment/comment 3 lines. >> >> http://cr.openjdk.java.net/~chegar/Base64-t

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

On 2 Dec 2015, at 20:23, Roger Riggs wrote: > Please review the java.lang.ref.Cleaner and tests following the > recommendation to simplify the public > interface to support only phantom cleanup. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/

Re: Pattern.splitAsStream JavaDoc doubt

Tagir, It would seem most useful to update the implementation to match the current spec. To that end, your first patch looks like the most appropriate change, pattern-patch.txt. -Chris. On 06/12/15 12:21, Tagir F. Valeev wrote: Hello! Currently Pattern.splitAsStream JavaDoc says [1]: *

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

102 * They are serializable if all elements are serializable. To avoid any ambiguity or "leaking", would it make sense to have the serial form of these types be defined, in a similar manner to what was done for Serializable types in the java.time package [1]. This can be done as a follow up,

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: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 3 Dec 2015, at 15:58, Roger Riggs <roger.ri...@oracle.com> wrote: > Hi Chris, > > Thanks for the review and comments: > > The webrev and javadoc have been updated. > > On 12/03/2015 08:55 AM, Chris Hegarty wrote: >> On 2 Dec 2015, at 20:23, Roger Rig

RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

The regression tests in the jdk should be updated, where possible, to use java.util.Base64. http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ -Chris.

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

On 02/12/15 14:03, Alan Bateman wrote: On 02/12/2015 12:08, Chris Hegarty wrote: The regression tests in the jdk should be updated, where possible, to use java.util.Base64. http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ Should S11N be updated to serialize with JDK 8 so

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

thread-local values, then they can. As was said, this will not be that commonly used. I’ll finalise this as is, unless there are any objections. -Chris. On 9 Dec 2015, at 16:58, mark.reinh...@oracle.com wrote: > 2015/12/8 5:36 -0800, david.hol...@oracle.com: >> On 9/12/2015 12:15 AM, Chri

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

bug 4006245 */ target = null; /* Speed the release of some of these resources */ threadLocals = null; inheritableThreadLocals = null; inheritedAccessControlContext = null; blocker = null; uncaughtExceptionHandler = null; } } -Chris. > On 12/08/2015 08:15 AM

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

On 11 Dec 2015, at 11:17, Alan Bateman <alan.bate...@oracle.com> wrote: > On 11/12/2015 09:24, Chris Hegarty wrote: >> : >>> Nit: >>> 687 * the specified stack size, and inherits initial values for >>> Not sure if italic font of stack size is inten

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

This looks good Stuart. -Chris. On 10 Dec 2015, at 00:22, 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: > >

RFR [9] Remove sun.misc.Request and RequestProcessor

sun.misc.Request and RequestProcessor are not used by the JDK, and I can find no usage outside the JDK either. I would like to propose their removal. $ hg rm src/java.base/share/classes/sun/misc/RequestProcessor.java $ hg rm src/java.base/share/classes/sun/misc/Request.java -Chris.

Re: RFR [9] Remove sun.misc.Request and RequestProcessor

I’ll follow up on additional cleanups later. -Chris. > Roger > > > On 12/11/2015 11:30 AM, Chris Hegarty wrote: >> sun.misc.Request and RequestProcessor are not used by the JDK, and I can >> find no usage outside the JDK either. I would like to propose their removal. >>

Re: RFR [9] Moved sun.misc.ProxyGenerator to jdk.internal.reflect

On 15 Dec 2015, at 17:15, Mandy Chung <mandy.ch...@oracle.com> wrote: > >> On Dec 15, 2015, at 4:00 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: >> >> No new code here, just giving sun.misc.ProxyGenerator a more appropriate >> location, in j

Re: RFR [9] Moved sun.misc.ProxyGenerator to jdk.internal.reflect

On 15 Dec 2015, at 19:26, Mandy Chung <mandy.ch...@oracle.com> wrote: >> On Dec 15, 2015, at 10:41 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: >> >> >> Webrev updated in-place. > > Thank you for moving it to java.lang.reflect. > > F

RFR [9] Moved sun.misc.ProxyGenerator to jdk.internal.reflect

No new code here, just giving sun.misc.ProxyGenerator a more appropriate location, in jdk.internal.reflect ( since it contains the code to generate a dynamic proxy class for the java.lang.reflect.Proxy ). http://cr.openjdk.java.net/~chegar/proxyGeneratorWebrev/webrev/ Note: ProxyGenerator could

Re: RFR [9] Remove sun.misc.Queue and replace usages with standard Collections

r? -Chris. > On 11/12/15 20:22, Chris Hegarty wrote: >> More technical debt in sun.misc… >> >> Java SE has had support for Queues in Collections for many major releases, >> sun.misc.Queue seems to predate that. I cannot find any usages outside of the >> JDK, and

Re: Reference.reachabilityFence

> On 12 Dec 2015, at 11:27 a.m., Peter Levart wrote: > > Hi Paul, > > Your latest code does not build with jdk9/dev as it uses > @jdk.internal.vm.annotation.DontInline, but in jdk9/dev the @DontInline is > still in java.lang.invoke. > > Is there a plan to push the

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

On 10 Dec 2015, at 19:59, Mandy Chung <mandy.ch...@oracle.com> wrote: > On 12/10/2015 03:48 AM, Chris Hegarty wrote: >> Updated webrev: >> http://cr.openjdk.java.net/~chegar/8056152/01/webrev/ > > Looks good. Thanks Mandy. > Nit: > 687 * the specified stack

RFR [9] Remove sun.misc.Queue and replace usages with standard Collections

More technical debt in sun.misc… Java SE has had support for Queues in Collections for many major releases, sun.misc.Queue seems to predate that. I cannot find any usages outside of the JDK, and just one in the JDK, AppletPanel. LinkedBlockingQueue appears to provide the necessary minimum

<    8   9   10   11   12   13   14   15   16   17   >