Re: RFR [9] 8153737: Unsupported Module

> On Apr 7, 2016, at 10:14 AM, Chris Hegarty wrote: > > Enough technical debt has been paid down that we can now create the new > JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. > This module will initially contain, and export, the sun.misc package, > and will eventually e

RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

I’ve put up a new webrev that addresses the issue of having spaces before (and after) the value “true” in the Multi-Release attribute. > Hi, > Please review this simple fix to require that the jar manifest Multi-Release > attribute has a value of “true" in order to be effective, i.e. to assert t

Re: RFR 8153123 : Streamline StackWalker code

Hi, Daniel On 04/07/2016 04:24 AM, Daniel Fuchs wrote: In http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/hotspot/src/share/vm/prims/jvm.cpp.frames.html 548 objArrayOop fa = objArrayOop(JNIHandles::resolve_non_null(frames)); 549 objArrayHandle frames_array_h(THREAD, fa); 550

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

Hi Paul, We would like to have an an API for Intel's 3D XPoint memory sooner than the JDK 10 timeframe and proposed this API because it seems simple enough to consider for JDK 9. As you suggest, we will participate in the Panama discussions in this area. Any additional guidance you have woul

RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place

Hi, I've run into a peculiar issue with Xerces. The problem is happening when a DTD shall be skipped, the DTD is larger than the buffer of the current entity and a CRLF sequence occurs just one char before the buffer end. The reason is that method skipDTD of class XMLDTDScannerImpl (abou

Re: RFR [9] 8153737: Unsupported Module

On 07/04/2016 18:14, Chris Hegarty wrote: Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. This module will initially contain, and export, the sun.misc package, and will eventually export the sun.reflect

RFR [9] 8153737: Unsupported Module

Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. This module will initially contain, and export, the sun.misc package, and will eventually export the sun.reflect package too ( once it has been sanitized ).

Re: RFR: jsr166 jdk9 integration wave 6

On 04/07/2016 11:29 AM, Paul Sandoz wrote: I am struggling to square the CF updates to the test. AFAICT the cleaning of a CF stack is now less aggressive. A dependent’s stack stack will now only be cleared if it has not completed (rather than if also the computation is nested). Thus in theor

Re: RFR: jsr166 jdk9 integration wave 6

> On 7 Apr 2016, at 16:55, Martin Buchholz wrote: > > On Thu, Apr 7, 2016 at 6:17 AM, Paul Sandoz wrote: >> >>> On 6 Apr 2016, at 22:17, Martin Buchholz wrote: > >> Looks good. >> >> Regarding CompletableFutureTest.testManyDependents i presume that kind of >> test was not failing before th

Re: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations

Hi Tagir, another minor issue. The testFlags() methods in IntPrimitiveOpsTests / LongPrimitiveOpsTests each have a duplicated assert: IntPrimitiveOpsTests: assertFalse(IntStreams.of(1, 10).boxed().spliterator() .hasCharacteristics(Spliterator.SORTED)); LongPrimitiveOpsTests: a

Re: RFR: jsr166 jdk9 integration wave 6

On Thu, Apr 7, 2016 at 6:17 AM, Paul Sandoz wrote: > >> On 6 Apr 2016, at 22:17, Martin Buchholz wrote: > Looks good. > > Regarding CompletableFutureTest.testManyDependents i presume that kind of > test was not failing before the modifications to CompletableFuture? Right - technically it was n

Re: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations

Hi Tagir, a few comments below a) IntPipeline: public final mapToObj(IntFunction mapper, int opFlags) should be private, not public b) IntPipeline: asDoubleStream() - as already discussed, 0 should be passed as the opFlags value to the DoublePipeline.StatelessOp constructor c) I think, the new

RFR 8151705 VarHandle.AccessMode enum names should conform to code style

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151705-VH-AccessMode-names/webrev/ I was persuaded (in internal CCC review) to change the enum VarHandle.AccessMode constant names to conform to the expected Java style. Previously, for convenience, the names corresponded exac

Re: RFR: jsr166 jdk9 integration wave 6

> On 6 Apr 2016, at 22:17, Martin Buchholz wrote: > > We missed Aleksey's changes, which broke our integration. > Looks good. Regarding CompletableFutureTest.testManyDependents i presume that kind of test was not failing before the modifications to CompletableFuture? I am struggling to squa

Re: RFR 8153123 : Streamline StackWalker code

Hi Brent, This looks good! Thanks for taking care of this one. In http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/hotspot/src/share/vm/prims/jvm.cpp.frames.html 548 objArrayOop fa = objArrayOop(JNIHandles::resolve_non_null(frames)); 549 objArrayHandle frames_array_h(THREAD, fa);

Re: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport )

On 2016-04-04 13:34, Alan Bateman wrote: On 04/04/2016 12:04, Erik Joelsson wrote: Makefile looks good. If you move Java_sun_rmi_transport_GC_maxObjectInspectionAge out of libjava, should you also remove it from the mapfile for libjava? Yes, libjava/mapfile-vers will need to be updated t

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

On Wed, Apr 6, 2016 at 8:28 PM, Iris Clark wrote: > Hi, Volker. > > Sorry for the delay. I agree that the old implementation isn't quite > correct. I can't see us potentially having a JCP MR for a security or patch > release (9.0.0.X and 9.0.X respectively). > > I could see a MR for an very un

RFR 8152645 VarHandle lookup access control tests

Hi, Please review a test to verify access control of looking up fields using a VarHandle: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8152645-VH-access-control/webrev/ For completeness i also added tests for M