Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

pt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ > where I would suppose latest jtreg sources were used, don't help. > > Am I missing something? Is it possible to post, or upload to cr.o.j.n, the jtr of the failing test? -Chris. > Best regards > Christop

Re: RFR of JDK-8153543: java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java fails intermittently

> On 22 Nov 2016, at 02:50, Hamlin Li wrote: > > Would you please review the patch for below bug? > > bug: https://bugs.openjdk.java.net/browse/JDK-8153543 > webrev: http://cr.openjdk.java.net/~mli/8153543/webrev.00/ Looks fine Hamlin. -Chris. > Root cause: between "TestLibrary.getUnusedRand

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

Hi Christoph, Can you please ensure that your build of jtreg contains the fix for 7901792 [1]. 7901792 grants /lib/testng.jar all permissions. -Chris. [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 > On 22 Nov 2016, at 08:38, Langer, Christoph wrote: > > Hi, > > I'm currently str

Re: RFR 8132964 Spliterator documentation on Priority(Blocking)Queue

> On 21 Nov 2016, at 20:57, Martin Buchholz wrote: > > Looks good to me! +1 -Chris. > On Mon, Nov 21, 2016 at 12:52 PM, Paul Sandoz > wrote: > >> Hi, >> >> Please review specification clarifications to PriorityQueue and >> PriorityBlockingQueue for the spliterator. Ordinarily i would not s

RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order

JDK-8155977 updated ObjectInputStream::resolveClass, and resolveProxyClass, to work with the platform class loader, but inadvertently removed the text describing the order in which the call stack is searched, for the 'loader'. The omission, from Java SE 8, is " ... closest such method to the curr

Re: RFR of JDK-8168975: java/rmi/activation/Activatable tests fail due to "Port already in use" in RMID.restart()

> On 16 Nov 2016, at 07:36, Hamlin Li wrote: > > Would you please review below fix? > > bug: https://bugs.openjdk.java.net/browse/JDK-8168975 > webrev: http://cr.openjdk.java.net/~mli/8168975/webrev.00/ The approach builds on the mechanism put in for 8168975, and seems reasonable. The system

Re: NPE on "return" bytecode of java.net.NetworkInterface

On 14/11/16 15:29, Andrew Haley wrote: On 14/11/16 14:47, David M. Lloyd wrote: Since this method is called from a native method, is it possible that somehow the native method is generating an NPE, but the Java method is still in the stack context? I assume that what is happening here is some

Re: RFR 9: 8169556 : Wrap FileInputStream's native skip and available methods

On 10 Nov 2016, at 19:09, Roger Riggs wrote: > > Hi, > > Please review this request to enable instrumentation on the FileInputStream > skip and available methods > by wrapping native methods with java methods as proposed and contributed by > Sunny Chan. > > webrev: > http://cr.openjdk.java.n

Re: JDK 9 RFR of JDK-8169041: com/sun/corba/cachedSocket should be added to exclusiveAccess.dirs

Looks ok Amy. -Chris. > On 10 Nov 2016, at 03:31, Amy Lu wrote: > > Please review the patch to add com/sun/corba/cachedSocket to > exclusiveAccess.dirs so as tests won't run concurrently. > > This is to address one potential issue that corba tests (start and use orbd > service) may run into

Re: RFR 8164934: Optional.map() javadoc code example is incorrect

On 8 Nov 2016, at 23:52, Paul Sandoz wrote: > > Hi, > > Please review an update to the api note of Optional.map() which > embarrassingly contained erroneous code (labouring under the misapprehension > that exception transparency is supported!). > > I tweaked the example to refer to a Stream w

Re: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module

;> Why jdk.compiler? Why not simply java.compiler? >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 02/11/16 12:51, Sergei Kovalev wrote: >>>>> Fixed >>>>> >>>>> http://cr.openjdk.java.net/~skovalev/8169055/webrev.01/ >>>>> >>>>> >>>>> 02.11.16 15:34, Chris Hegarty wrote: >>>>>>> On 2 Nov 2016, at 12:31, Sergei Kovalev >>>>>>> wrote: >>>>>>> >>>>>>> javax.lang.model.SourceVersion >>>>>> This type is in the java.compiler module. >>>>>> >>>>>> -Chris. >>>>> >>>> >>> >> >

Re: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module

> On 2 Nov 2016, at 12:31, Sergei Kovalev wrote: > > javax.lang.model.SourceVersion This type is in the java.compiler module. -Chris.

Re: JDK 9 RFR of JDK-8143097: Test java/net/ipv6tests/UdpTest.java fails

On 2 Nov 2016, at 11:06, Amy Lu wrote: > > On 11/2/16 6:17 PM, Chris Hegarty wrote: >> Amy, >> >>> On 2 Nov 2016, at 09:43, Amy Lu wrote: >>> >>> Please reviewthe patch for java/net/ipv6tests/UdpTest.java >>> >>> bug: ht

Re: JDK 9 RFR of JDK-8151511: Test case in CollectionAndMapModifyStreamTest for LinkedHashMap overrides that for HashMap

On 2 Nov 2016, at 02:47, Amy Lu wrote: > > Please review the patch for fixing typo in steam tests: > > bug: https://bugs.openjdk.java.net/browse/JDK-8151511 > webrev: http://cr.openjdk.java.net/~amlu/8151511/webrev.00/ This looks good. Thanks Amy. -Chris. > 1) In CollectionAndMapModifyStreamT

Re: JDK 9 RFR of JDK-8143097: Test java/net/ipv6tests/UdpTest.java fails

Amy, > On 2 Nov 2016, at 09:43, Amy Lu wrote: > > Please reviewthe patch for java/net/ipv6tests/UdpTest.java > > bug: https://bugs.openjdk.java.net/browse/JDK-8143097 > webrev: http://cr.openjdk.java.net/~amlu/8143097/webrev.00/ I think what you have will probably be ok, given the 50% toleranc

RFR 8168980 [9]: Reinstate sun.reflect.ReflectionFactory.newConstructorForSerialization(Class, Constructor)

Recent changes for 8164908 [1] inadvertently removed the 2-arg newConstructorForSerialization method. This should be reinstated. https://bugs.openjdk.java.net/browse/JDK-8168980 http://cr.openjdk.java.net/~chegar/8168980/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8164908

Re: RFR: 8164805: Fail to create a MR modular JAR with a versioned entry in base-versioned empty package

On 19/10/16 19:34, Steve Drach wrote: Hi, Please review the following changeset. This fix allows jar tool to add a new public class in a versioned directory in a modular multi-release jar file if the class is in a concealed package. When this event takes place, a warning message is emitted s

Re: RFR 9: 8164908: ReflectionFactory support for IIOP and custom serialization

Roger, On 20/10/16 18:57, Roger Riggs wrote: Hi, Thanks for the comments.. Webrev's updated in place with comments so far. (Including David's and Amy's) http://cr.openjdk.java.net/~rriggs/webrev-reflection-factory-8164908/ This looks very good Roger. A few very minor comments: 1) The exp

Re: RFR:JDK-8075205 java/net/URLClassLoader/closetest/CloseTest.java and GetResourceAsStream.java failed with existing dir

> On 17 Oct 2016, at 09:51, Srinivasan Raghavan > wrote: > > Hi all > > Please review the fix for the bug > > Bug :https://bugs.openjdk.java.net/browse/JDK-8075205 > > The tests uses classes directory for the output files. This can result in the > files being left over after the test is co

Re: RFR: 8168073: Speed up URI creation during module bootstrap

On 17/10/2016 22:18, Claes Redestad wrote: > >> On 2016-10-17 21:35, Alan Bateman wrote: >>> >>> JavaNetHttpCookieAccess, JavaNetInetAddressAccess and >>> JavaNetSocketAccess are the other 3 that are used to get at non-public >>> types in java.net so I don't think JavaNetUriAccess would be out of

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Roger, I addressed all, or most, of your comments in the following webrev. 1) Refactored out the use of sun.nio.ch in the test library, so that a reduced number of tests need their @modules tag updated. ( @modules support with test library usage it a pain ) 2) Use Boolean.getBoolean

Re: RFR: 8167005: Comment on the need for an empty constructor in ArrayList$Itr

> On 4 Oct 2016, at 11:55, Claes Redestad wrote: > > > On 2016-10-04 12:52, Aleksey Shipilev wrote: >> On 10/04/2016 12:50 PM, Claes Redestad wrote: >>> Webrev: http://cr.openjdk.java.net/~redestad/8167005/webrev.01/ +1 -Chris.

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

added createRMIDOnEphemeralPort, rather than change the current implementation, as it is being used in other places. We can revert this once other usages are updated and verified. -Chris. On 29/09/16 20:09, Chris Hegarty wrote: On 29 Sep 2016, at 16:25, Chris Hegarty wrote: I have asked

Re: RFR 9: 8155760 Implement Serialization Filtering

Roger, On 14/09/16 10:46, Chris Hegarty wrote: On 08/09/16 20:09, Roger Riggs wrote: ... This looks very good Roger, just a few comments: 1) The pattern separator in the java.security file should be ';' Right? 925 #jdk.serialFilter=patte

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

On 29 Sep 2016, at 16:25, Chris Hegarty wrote: > > I have asked Hamlin to hold off on this for a day or so. I have an > alternative proposal that eliminates the free port anti-pattern. It is possible to use the inheritedChannel mechanism to have the rmid process create the server c

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

I have asked Hamlin to hold off on this for a day or so. I have an alternative proposal that eliminates the free port anti-pattern. -Chris. > On 29 Sep 2016, at 14:55, Roger Riggs wrote: > > Hi Hamlin, > > One more suggested improvement. Instead of two copy/paste copies of the > launch wi

Re: RFR: jsr166 jdk9 integration wave 11

On 21 Sep 2016, at 20:33, Martin Buchholz wrote: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > > Notable here is an attempt to make a minimal completion stage more acceptable > as a return value from APIs, by making > completableFuture.minimalCompletionStag

Re: We need to add blocking methods to CompletionStage!

Until now CS and CF have not appeared in Java SE API signatures, outside of the j.u.c package. They are, however, currently being proposed for use in API signatures for Java SE 9 [1][2], namely j.l.Process[Handle]::onExit, and more extensively in the proposed new HTTP Client. CF was chosen, in som

Re: RFR 9: 8165261: RMI API to export an object with a serialization filter

On 12/09/16 21:42, Roger Riggs wrote: Please review an update to enable serialization filtering for exported RMI objects. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-rmi-filter-8165261/ This looks good to me Roger. -Chris.

Re: RFR 9: 8155760 Implement Serialization Filtering

On 08/09/16 20:09, Roger Riggs wrote: Please review updates to the Serialization filtering API and implementation: - The ObjectInputFilter pattern based filters support matching on module names as well as package and class names. - Rename of system property and java.security property for conf

Re: RFR: 8161016: Strange behavior of URLConnection with proxy

On 12/08/16 20:56, Ramanand Patil wrote: Hi Aleksey, Thank you for your review. In the exception handler block: when last proxy fails, it was using a DIRECT connection, but in the fixed version it was just a re-try once with the last proxy before failing the connection. Considering your point

Re: RFR: 8164669: Lazier initialization of java.time

+1. -Chris. On 23/08/16 21:52, Stephen Colebourne wrote: This looks fine to me. I suspect that we could hand write a parser to avoid the regex, but this probably suffices. Stephen On 23 August 2016 at 19:49, Claes Redestad wrote: Hi, this tiny cleanup reduces number of loaded classes from a

Re: RFR: 8163476: java/lang/StackWalker/VerifyStackTrace.java fails after JDK-8163369

> On 9 Aug 2016, at 13:26, Claes Redestad wrote: > > > > On 2016-08-09 13:48, Claes Redestad wrote: >> Hi, >> >> change to enable DMH pre-generation caused a subtle change in the >> stacktrace, which caused this test to fail. >> >> Please review this patch which reverts the stackframe to lo

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

On 29/07/16 12:54, Daniel Fuchs wrote: Hi, Here is the new webrev with Chris & James feedback taken in. http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ This looks good to me Daniel. -Chris. best regards, -- daniel On 28/07/16 22:55, Daniel Fuchs wrote: On 28/07/16 21:31, Ja

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

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

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 m

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 [9] 8160513: ClassNotFoundException sun.misc.GC when running Tomcat 9 with JDK 9

that they remove the reflective access to sun.misc.GC, in their JDK 9 trunk. -Chris. regards Mark On 26/07/2016 16:24, Chris Hegarty wrote: The GC.Daemon thread has no need of any user defined class loader, so should set its context class loader to null before starting, so as to not inadvertently

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

Hi Daniel, On 25/07/16 19:10, Daniel Fuchs wrote: Hi, Please find below a fix for: 6543126: Level.known can leak memory https://bugs.openjdk.java.net/browse/JDK-6543126 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.00 Since mirroredLevel is a strong reference to the same

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

doc/java/io/ObjectInputStream.html > > > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html > > > > On 7/25/2016 10:54 AM, Chris Hegarty wrote: >> Roger, >> >> Mainly looks good. Some comments on the spec: >>

RFR [9] 8160513: ClassNotFoundException sun.misc.GC when running Tomcat 9 with JDK 9

The GC.Daemon thread has no need of any user defined class loader, so should set its context class loader to null before starting, so as to not inadvertently retain a reference to the creating thread’s context class loader. http://cr.openjdk.java.net/~chegar/8160513/ https://bugs.openjdk.java.net/

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Roger, Mainly looks good. Some comments on the spec: - Use the Present Simple Tense consistently, e.g. "Return*S* an ObjectInputFilter computed from a string of patterns." - ObjectInputFilter. Was there a comment already on the use of links? For example the following is showing in the

RFR [9] 8154017: Shutdown hooks are racing against shutdown sequence, if System.exit()-calling thread is interrupted

The shutdown hooks race against the shutdown sequence if the thread invoking System.exit() is interrupted. This happens because ApplicationShutdownHooks::runHooks joins the shutdown hooks. This may lead to premature VM shutdown, with shutdown hooks not fully executed. http://cr.openjdk.java.net/

Re: RFR 8159821 "PrimitiveStream.iterateFinite" methods contain incorrect code sample

Looks good Paul. -Chris. > On 17 Jun 2016, at 17:48, Paul Sandoz wrote: > > Hi, > > Please review minor corrections to the JavaDoc of the finite (predicate > accepting) iterate methods of Int/Long/DoubleStream. > > Thanks, > Paul. > > diff -r 6e55599ce242 > src/java.base/share/classes/java

Re: RFR: 8159590: Remove deprecated methods from jdk.internal.misc.VM

016, at 13:39, Chris Hegarty wrote: > > On 15 Jun 2016, at 14:30, Claes Redestad wrote: >> >> Hi, >> >> after VM.java was encapsulated and moved from sun.misc to jdk.internal.misc, >> the rationale for keeping a number of deprecated methods and constants

Re: RFR: 8159590: Remove deprecated methods from jdk.internal.misc.VM

On 15 Jun 2016, at 14:30, Claes Redestad wrote: > > Hi, > > after VM.java was encapsulated and moved from sun.misc to jdk.internal.misc, > the rationale for keeping a number of deprecated methods and constants no > longer applies and these methods should be removed: > > Webrev: http://cr.open

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

> On 15 Jun 2016, at 19:33, Mark Sheppard wrote: > > Hi, > please oblige and review the updated webrev: > > http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev.01/ I’m happy with the code changes here. Trivially, an alternative stylistic option for the method declaration: private st

Re: JDK 9 RFR of JDK-8071859: AnnotationInvocationHandler.equals(Object) return true when apply to annotation

On 16 Jun 2016, at 00:21, Joseph D. Darcy wrote: > > Hello, > > Please review the changes to address > >JDK-8071859: AnnotationInvocationHandler.equals(Object) return true when > apply to annotation >http://cr.openjdk.java.net/~darcy/8071859.0/ This looks good to me Joe. -Chris.

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

> On 9 Jun 2016, at 15:18, Roger Riggs wrote: > > Hi Mark, > > IIOPInputStream.java: > > - Does adding doPriv overhead to every field access have a noticeable impact > on performance? > If most of the fields are accessible or can easily be checked as being in > the base module, > I could s

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

Oh BTW, I assume the changes to the java.corba module-info are not needed right? Maybe left over from some debugging? -Chris. > On 9 Jun 2016, at 13:35, Chris Hegarty wrote: > > >> On 8 Jun 2016, at 23:18, Mark Sheppard wrote: >> >> >> Hi >> please

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

> On 8 Jun 2016, at 23:18, Mark Sheppard wrote: > > > Hi > please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev/ > > http://cr.openjdk.java.net/~msheppar/8146975/jdk9/test/webrev/ > > which address the issue raised in > https://bugs.openj

Re: RFR: 8114827: JDK 9 multi-release enabled jar tool

Hi Steve, > On 2 Jun 2016, at 02:02, Steve Drach wrote: > > Hi, > > Please review the following changeset that makes it easier to create > multi-release jar files with jar tool. > > webrev: http://cr.openjdk.java.net/~sdrach/8114827/webrev.01/ > issue: https://bugs.openjdk.java.net/browse/

Re: RFR 8157816, Mark 4 httpclient tests as intermittently failing

This is sad, but I agree. Reviewed. -Chris. On 30/05/16 08:18, Felix Yang wrote: Hi all, please review the change to mark following tests with keyword 'intermittent'. These tests have been observed to fail intermittently for a while. test/java/net/httpclient/SplitResponse.java test/java/net

Re: RFR 8157996: Unneeded import in lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java

> On 26 May 2016, at 23:51, Alexandre (Shura) Iline > wrote: > > http://cr.openjdk.java.net/~shurailine/8157996/webrev.01/ Looks good Shura. > Thank you. > > Shura > >> On May 26, 2016, at 3:29 PM, Alexandre (Shura) Iline >> wrote: >> >> >>> On May 26, 2016, at 3:16 PM, Mandy Chung wro

Re: RFR: JDK-8157850 Jar tests should pass through VM options

> On 25 May 2016, at 20:21, Martin Buchholz wrote: > > Agreed and Reviewed! +1. This looks fine. Hopefully it can be simplified, somewhat, in the future. -Chris. > > On Wed, May 25, 2016 at 11:57 AM, Andrey Nazarov > wrote: >> Hi Martin, >> >> See my comments inline. >>> On 25 May 2016, a

RFR [9] 8157825: Remove JDK 9 specific methods from sun.misc.Unsafe

sun.misc.Unsafe, in the jdk.unsupported module, should not have any new public methods that were not already part of its API in JDK 8. This issue will remove three such methods, getUncompressedObject, getJavaMirror, and getKlassPointer, that were added by JDK-8022853, in JDK 9. diff --git a/sr

Re: RFR: JDK-8153768 Miscellaneous changes imported from jsr166 CVS 2016-05

> On 23 May 2016, at 21:32, Martin Buchholz wrote: > > JSR166 CVS has some unfinished work in progress, but enough minor > changes have accumulated that we should integrate into openjdk9: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ > https://bu

Re: JDK 9 RFR Replace @since 1.9 with @since 9 on new math methods

> On 22 May 2016, at 17:51, joe darcy wrote: > > Hello, > > Some recently added math methods since "@since 1.9" rather than "@since 9"; > please review the patch below to use "@since 9" instead. Looks fine Joe. -Chris. > Thanks, > > -Joe > > diff -r 997dcff5075f src/java.base/share/classe

Re: RFR [9] 8157154: jmod jlink properties file need copyright header

Yes of course. I'll add the year range before pushing. -Chris > On 19 May 2016, at 22:26, Mandy Chung wrote: > > Should the start year be 2015? You can fix up before you push. > > Mandy > >> On May 19, 2016, at 2:20 PM, Chris Hegarty wrote: >> >&g

RFR [9] 8157154: jmod jlink properties file need copyright header

Quite trivially, the copyright headers were omitted from these new property files. This review request simply adds the standard header to: jdk/src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties jdk/src

Re: RFR(s): 8133977 add specification for serial form of immutable collections

at pattern here would seem > desirable if possible. ie. a single Ser class for all new serialized > forms in java.util, starting with immutable collections. It would be nice, and generally useful going forward. -Chris. > Stephen > > > On 17 May 2016 at 11:43, Chris Hegarty wro

Re: RFR(s): 8133977 add specification for serial form of immutable collections

On 17 May 2016, at 09:55, Stephen Colebourne wrote: > CollSer should not be public, especially not just for serialization > reasons. Right, and I see no reason to refer to it by name in the javadoc, the link should be sufficient. > Stuart, I disagree with using an int for the flags, it should

Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds

On 13 May 2016, at 19:04, Brian Burkhalter wrote: > Correction: wrong link provided below: > > http://cr.openjdk.java.net/~bpb/8130679/webrev.02/ Looks good to me Brian. -Chris. > Sorry for the confusion. > > Brian > > On May 13, 2016, at 10:42 AM, Brian Burkhalter > wrote: > >> I have

Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds

On 10 May 2016, at 00:29, Brian Burkhalter wrote: > Hi Roger, > > So modified: > > http://cr.openjdk.java.net/~bpb/8130679/webrev.01/ This looks good to me. I have to admit that I reviewed the current wording in Reader.read, but on reflection it would be better to update it to reflect this w

Re: RFR [9] 8153737: Unsupported Module

On 9 May 2016, at 20:43, Richard Opalka wrote: > Fixed in JBoss Marshalling upstream. Thanks for fixing this, and getting back to us on the list. I assume then that, at least, this part of JBoss is working on JDK 9 b115, right? -Chris. > Thanks, > > Rio > > On 04/27/20

Re: Proposed patch: further wrapping of FileInputStream's native method

The changes in your patch look ok. It is not clear, at least to me, why these methods are all that interesting, or even why they were not covered by 8054720. Maybe Brian Burkhalter, or others may know. -Chris. On 09/05/16 04:27, Chan, Sunny wrote: Previously in JDK-8054720

Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

is correct is a separate matter. I am planning to create a standalone test case and take it with javac ppl. Thank you. Shura On May 4, 2016, at 8:30 AM, Chris Hegarty wrote: On 4 May 2016, at 14:32, Alan Bateman wrote: On 04/05/2016 11:24, Chris Hegarty wrote: : The tests cause compilati

Re: Review Request JDK-8155977: Update ObjectInputStream::resolveClass and resolveProxyClass to work with platform class loader

On 5 May 2016, at 17:59, Mandy Chung wrote: > >> On May 5, 2016, at 6:10 AM, Alan Bateman wrote: >> >> In resolveClass then "is class loader corresponding to the closest .." >> should probably be "is the class loader ...". You didn't introduce this of >> course, just noticed it while reading

Re: RFR(m): 8139233 add initial compact immutable collection implementations

On 5 May 2016, at 01:21, Stuart Marks wrote: > Hi Daniel, > > On 5/4/16 3:08 AM, Daniel Fuchs wrote: >> I wonder about serial interoperability with earlier >> versions of the JDK. For instance it will not be possible to >> send a Set created with Set.of(...) in JDK 9 to a JDK 8 VM. >> I wonder

Re: RFR(m): 8139233 add initial compact immutable collection implementations

On 5 May 2016, at 01:21, Stuart Marks wrote: > Hi Daniel, > > On 5/4/16 3:08 AM, Daniel Fuchs wrote: >> I wonder about serial interoperability with earlier >> versions of the JDK. For instance it will not be possible to >> send a Set created with Set.of(...) in JDK 9 to a JDK 8 VM. >> I wonder

Re: Review Request JDK-8155977: Update ObjectInputStream::resolveClass and resolveProxyClass to work with platform class loader

On 4 May 2016, at 20:29, Mandy Chung wrote: > The default implementation of ObjectInputStream::resolveClass and > resolveProxyClass finds the user-defined class loader on the stack and > assumes that only system classes are loaded by null loader. As JDK modules > are deprivileged, classes on

Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

On 4 May 2016, at 14:32, Alan Bateman wrote: > > On 04/05/2016 11:24, Chris Hegarty wrote: >> : >> The tests cause compilation of test library classes, but only some tests >> actually use the methods that provoke compilation. Similar to above, tests >> that don’t a

Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

On 4 May 2016, at 11:07, Alan Bateman wrote: > On 04/05/2016 09:40, Chris Hegarty wrote: >> On 3 May 2016, at 16:10, Chris Hegarty wrote: >> >>>>> Can you please take a look on: >>>>> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ >&

Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

On 3 May 2016, at 16:10, Chris Hegarty wrote: >>> >>> Can you please take a look on: >>> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ Taking another look over this before sponsoring…. The test library dependency seems to be on java.compiler, and not jdk

Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

On 2 May 2016, at 22:48, Steve Drach wrote: > Looks fine to me, +1. -Chris. > although I am not an official reviewer. Thanks for doing this. > >> On May 2, 2016, at 1:03 PM, Alexandre (Shura) Iline >> wrote: >> >> Hi, >> >> Can you please take a look on: >> http://cr.openjdk.java.net/~s

Re: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package

On 2 May 2016, at 23:37, Paul Sandoz wrote: > Hi, > > Please review: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-jdk/webrev/ > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-hotspot/webrev/ The changes look fine

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

> On 1 May 2016, at 08:45, Alan Bateman wrote: > > On 30/04/2016 01:10, Steve Drach wrote: >> Hopefully the last one ;-) This webrev removes the lowercase of protocol, >> and incorporates better (in my mind) seperation of choices for choosing the >> loader, similar to what Paul suggested. Ev

Re: Review request: 8154190 & 8155513: Deprivilege java.compiler and jdk.charsets

> On 30 Apr 2016, at 06:02, Mandy Chung wrote: > > JDK-8154190: Deprivilege java.compiler module > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8154190/webrev.00/ > > JDK-8155513: Deprivilege jdk.charsets module > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155513

Re: RFR (XS) 8155090: String concatenation fails with a custom SecurityManager that uses concatenation

> On 28 Apr 2016, at 21:54, Claes Redestad wrote: > > Hi Aleksey, > > On 2016-04-28 22:10, Aleksey Shipilev wrote: >> Hi, >> >> Please review the fix for a shady bootstrapping issue, when a custom >> SecurityManager is using string concatenation: >> https://bugs.openjdk.java.net/browse/JDK-8

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

On 28 Apr 2016, at 09:11, Alan Bateman wrote: > > On 27/04/2016 22:58, Steve Drach wrote: >> Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 >> >> >> Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev/ >>

RFR [9] 8155578: OpenJDK build failed after JDK-8044773

This is a review for a trivial, but build-fatal, addition of a qualified export to the jdk.net module, that was mistakenly omitted from the changes for 8044773. $ hg diff -U 11 diff --git a/src/java.base/share/classes/module-info.java b/src/java.base/share/classes/module-info.java --- a/src/java.

Re: RFR [9] 8153737: Unsupported Module

Hi Rio, > We are missing sun/reflect/ReflectionFactory$GetReflectionFactoryAction inner > class > > in jdk.unsupported module: > > java.lang.NoClassDefFoundError: > sun/reflect/ReflectionFactory$GetReflectionFactoryAction >at > jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@9

Re: RFR (XS) 8155215: java.lang.String concatenation spec is unnecessarily strong

On 27 Apr 2016, at 11:33, Aleksey Shipilev wrote: > Hi, > > Please review this tiny spec improvement that syncs up JLS and > java.lang.String Javadoc. java.lang.String Javadoc unnecessarily locks > down the implementation details for String concat (e.g. usage of > StringBuilder): > http://cr.o

Re: RFR(XS): 8155156: Remove remaining sun.misc.* imports from the jdk repo

On 26 Apr 2016, at 18:33, Volker Simonis wrote: > Hi, > > can I please have a review for this trivial change: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8155156/ > https://bugs.openjdk.java.net/browse/JDK-8155156 Thank you Volker. Reviewed. -Chris. > The fix for "8153737: Unsuppo

RFR [9] 8147543: Remove sun.misc.ManagedLocalsThread

Another remaining JEP 260 task that can now be resolved ( remove a non-Critical API from sun.misc ). With all the subtasks of 8147543 [1] complete, i.e. all the dependencies on ManagedLocalsThread have been removed, it is time to remove the type itself ( its functionality has been superseded by th

Re: RFR [9] 8154919: Remove superfluous jdk.unsupported from tools/launcher/modules/limitmods/LimitModsTest.java

n 22 Apr 2016, at 10:07, Alan Bateman wrote: > On 22/04/2016 09:47, Chris Hegarty wrote: >> The jdk.unsupported module was added to the LimitModsTest.java test >> temporally, until the problematic dependency from the java.logging >> module on the jdk.unsupported module could

RFR [9] 8154919: Remove superfluous jdk.unsupported from tools/launcher/modules/limitmods/LimitModsTest.java

The jdk.unsupported module was added to the LimitModsTest.java test temporally, until the problematic dependency from the java.logging module on the jdk.unsupported module could be resolved. This is now resolved, see 8153158 [1]. It was an oversight of the changes for 8153158 that this test was n

Re: Review request 8154837: Class::getPackage with exploded modules when classes in modules defined to the boot loader

On 21 Apr 2016, at 23:03, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8154837/webrev.00/ This looks good to me Mandy. -Chris. > The module location from an exploded image is file URL rather than file path. > This issue can be reproduced with > jdk/test/j

Re: RFR: 8154853: java/util/TimeZone/OldIDMappingTest.sh fails after JDK-8154231

On 21 Apr 2016, at 15:53, Claes Redestad wrote: > Hi, > > initializing USE_OLDMAPPING after using it - deep inside load(dis) - seems > like a very bad idea in hindsight. > > webrev: http://cr.openjdk.java.net/~redestad/8154853/webrev.01/ > bug: https://bugs.openjdk.java.net/browse/JDK-8154853

Re: RFR: 8154231: Simplify access to System properties from JDK code

On 20 Apr 2016, at 20:34, Claes Redestad wrote: > > > On 2016-04-20 20:51, Chris Hegarty wrote: >> On 20 Apr 2016, at 15:44, Claes Redestad wrote: >> >>> Hello, >>> >>> now that the sun.security.action package is encapsulated we can simp

Re: RFR: 8154231: Simplify access to System properties from JDK code

On 20 Apr 2016, at 15:44, Claes Redestad wrote: > Hello, > > now that the sun.security.action package is encapsulated we can simplify > internal code to get System properties. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154231 > Webrev: http://cr.openjdk.java.net/~redestad/8154231/webr

Re: RFR [9] 8148863: Remove sun.misc.ManagedLocalsThread from corba

hog" with Async-Request-Invoker-Thread, please Ok. Thanks for reviewing. -Chris. > just like naming children very emotive :-) > > regards > Mark > > On 19/04/2016 11:17, Chris Hegarty wrote: >> On 19 Apr 2016, at 09:55, Alan Bateman wrote: >> >>>

Re: RFR [9] 8148863: Remove sun.misc.ManagedLocalsThread from corba

On 19 Apr 2016, at 09:55, Alan Bateman wrote: > > On 18/04/2016 21:50, Chris Hegarty wrote: >> This change updates the code in the cobra module to use the new >> Thread constructor that suppresses inheritable-thread-local initial >> values. >> >> http:/

RFR [9] 8148863: Remove sun.misc.ManagedLocalsThread from corba

This change updates the code in the cobra module to use the new Thread constructor that suppresses inheritable-thread-local initial values. http://cr.openjdk.java.net/~chegar/8148863/ https://bugs.openjdk.java.net/browse/JDK-8148863 I’m open to suggestions for better names for the Threads. -Chri

Re: 8154159: rmic should not have a supported entry point

On 18/04/16 15:57, Alan Bateman wrote: When we brought the module system into JDK 9 then it included a new entry point for the RMI compiler (rmic). This was a mistake (conflicts with the policy for root modules that we have in JEP 261) and should not have been brought into JDK 9. The following

RFR [9] 8147553: Remove sun.misc.ManagedLocalsThread from java.management

8056152 added a new constructor to java.lang.Thread to constructing Threads that do not inherit inheritable-thread-local initial values. Given there is now a supported API for creating such threads, other areas of the JDK should be updated to use it. This change updates the code in java.manage

RFR [9] 8153158: Remove sun.misc.ManagedLocalsThread from java.logging

8056152 added a new constructor to java.lang.Thread to constructing Threads that do not inherit inheritable-thread-local initial values. Given there is now a supported API for creating such threads, other areas of the JDK should be updated to use it. This change updates the code in java.logging

RFR [9] 8153372: Remove sun.misc.ManagedLocalsThread from jdk.httpserver

8056152 added a new constructor to java.lang.Thread to constructing Threads that do not inherit inheritable-thread-local initial values. Given there is now a supported API for creating such threads, other areas of the JDK should be updated to use it. This change updates the code in the jdk.http

<    1   2   3   4   5   6   7   8   9   10   >