Re: RFR (JAXP): 8054196: XPath: support any type

On 1/21/2015 5:09 PM, Lance Andersen wrote: Hi Joe, I think this is OK (as we discussed offline), one minor comment/suggestion below Best Lance On Jan 21, 2015, at 7:45 PM, huizhe wang > wrote: Thanks Lance for pointing me to Joe's -Xlint:all email thread. I

Re: RFR (JAXP): 8054196: XPath: support any type

Hi Joe, I think this is OK (as we discussed offline), one minor comment/suggestion below Best Lance On Jan 21, 2015, at 7:45 PM, huizhe wang wrote: > Thanks Lance for pointing me to Joe's -Xlint:all email thread. I re-compiled > with -Xlint:all and noticed 7 warnings in this webrev. I've fixed

Re: RFR (JAXP): 8054196: XPath: support any type

Thanks Lance for pointing me to Joe's -Xlint:all email thread. I re-compiled with -Xlint:all and noticed 7 warnings in this webrev. I've fixed them with a new webrev: New webrev: http://cr.openjdk.java.net/~joehw/jdk9/8054196/webrev01/ Below are the details. Refer to the previous webrev: http:

RE: [PATCH] JDK-8054565: FilterOutputStream.close may throw IOException if called twice and underlying flush or close fails

Hi Chris, Thanks for your help on this one! Will this be backported to JDK 8, or is that not allowed because of the spec change? Thanks, Nathan > Date: Mon, 22 Dec 2014 14:13:18 + > From: chris.hega...@oracle.com > To: core-libs-dev@openjdk.java.net; nathan.a.clem...@hotmail.com > Subject

Re: Explicit Serialization API and Security

At some point, the responsibility *must* fall on the author of the serializable class in question to avoid constructs which are exploitable - like finalizers, and classes that can have side-effects before validation can be completed. On 01/21/2015 02:26 PM, Peter Firmstone wrote: Don't forget

Re: 8050820: Please add java.util.Optional.stream() to convert Optional to Stream

> On 20 Jan 2015, at 18:59, Paul Sandoz wrote: > > Hi, > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8050820-Optional-stream/webrev/ > > This is one of those cases where i think adding a new method to Optional > carries enough weight. Agreed. The changes look good to me. -Chris. > It c

Re: RFR: JDK-8068427 Hashtable deserialization reconstitutes table with wrong capacity

Thanks Martin, Mike, Chris and Daniel, This has been pushed. Regards, Peter On 01/21/2015 05:44 PM, Martin Buchholz wrote: Looks good to me! On Wed, Jan 21, 2015 at 5:04 AM, Peter Levart > wrote: Hi Martin and others, I have also modified the test per

Re: Explicit Serialization API and Security

Don't forget that "null" may also be an invalid state. What I have learnt so far: 1. An attacker can craft a stream to obtain a reference to any object created during deserialization, using finalizers or circular links (there may be yet other undiscovered methods). 2. An attacker c

Re: Expected vs. observed performance of java.util.zip.CRC32 in Java 7 and 8

Hi, I cleaned up the results and converted to bytes and megabytes/second by multiplying byteSize with ops/sec. https://docs.google.com/spreadsheets/d/1SirRnW7JOqUvAZhx0b2HjJug8lQGHAUiDU8-6Zcb9Os/edit?usp=sharing Thanks, Ariel On Wed, Jan 21, 2015, at 12:40 PM, Andrew Haley wrote: > On 01/21/201

Re: [8u60] RFR 8069302 Deprecate Unsafe monitor methods in JDK 8u release

+1; do it. > On Jan 21, 2015, at 2:35 AM, Paul Sandoz wrote: > > Hi, > > The Unsafe monitor methods monitorEnter. monitorExit and tryMonitorEnter were > removed from JDK 9 [1]. > > I would like to mark those methods as deprecated in 8u60. I doubt no one will > notice :-) but it's the correct

Re: 8050820: Please add java.util.Optional.stream() to convert Optional to Stream

On Jan 21, 2015, at 3:01 AM, Paul Sandoz wrote: > > I updated the webrev in place to be more consistent in the use of braces and > better consistency for the primitive specializations: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8050820-Optional-stream/webrev/ >

Re: [9] RFR (M): 8069591: Customize LambdaForms which are invoked using MH.invoke/invokeExact

On Jan 21, 2015, at 9:31 AM, Remi Forax wrote: > > in Invokers.java, I think that checkCustomized should take an Object and not > a MethodHandle > exactly like getCallSiteTarget takes an Object and not a CallSite. The use of erased types (any ref => Object) in the MH runtime is an artifact of

Re: Expected vs. observed performance of java.util.zip.CRC32 in Java 7 and 8

On 01/21/2015 05:34 PM, Ariel Weisberg wrote: > If you could shed any light on what the performance should be it would > help when choosing whether to use the JDK CRC32 implementation or > another depending on the currently runtime. Please normalize the output to bytes/s; it's very confusing. And

Expected vs. observed performance of java.util.zip.CRC32 in Java 7 and 8

Hi, Hopefully this is the right mailing list. I have some questions about the performance of java.util.zip.CRC32 in OpenJDK. I heard that CRC32 became an intrinsic in Java 8 that uses hardware support if available. I tried it out, but got some odd numbers and I am having trouble nailing down the

Re: [9] RFR (M): 8069591: Customize LambdaForms which are invoked using MH.invoke/invokeExact

Hi Vladimir, in Invokers.java, I think that checkCustomized should take an Object and not a MethodHandle exactly like getCallSiteTarget takes an Object and not a CallSite. in MethodHandle.java, customizationCount is declared as a byte and there is no check that the CUSTOMIZE_THRESHOLD is not

Re: RFR: JDK-8068427 Hashtable deserialization reconstitutes table with wrong capacity

Looks good to me! On Wed, Jan 21, 2015 at 5:04 AM, Peter Levart wrote: > Hi Martin and others, > > I have also modified the test per Martin's suggestion to factor out the > serialClone() method. Here's the latest webrev: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Hashtable.8068427/webrev.0

[9] RFR (M): 8069591: Customize LambdaForms which are invoked using MH.invoke/invokeExact

http://cr.openjdk.java.net/~vlivanov/8069591/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8069591 Overhead of non-inlined MH.invoke/invokeExact calls significantly increased with LambdaForm sharing. The cause is JIT compiler can't produce a single nmethod for the whole MethodHandle chain

Re: Explicit Serialization API and Security

On 20/01/15 20:22, Peter Levart wrote: Hi Chris and Peter, It just occurred to me that the following scheme would provide failure atomicity for the whole Object regardless of whether readObject methods are used or not for various classes in hierarchy: - allocate uninitialized instance - call d

[8u60] Request for approval: JDK-8067344: Adjust java/lang/invoke/LFCaching/LFGarbageCollectedTest.java for recent changes in java.lang.invoke

Hello, Please approve the direct backport of the test bug fix to 8u60 The webrev is slightly different from that for JDK 9, but only in line numbers, all the rest is just the same. The bug: https://bugs.openjdk.java.net/browse/JDK-8067344 The 8u60 webrev: http://cr.openjdk.java.net/~kshefov/8

Re: RFR: JDK-8068427 Hashtable deserialization reconstitutes table with wrong capacity

This looks good to me Peter. -Chris. On 21/01/15 13:04, Peter Levart wrote: Hi Martin and others, I have also modified the test per Martin's suggestion to factor out the serialClone() method. Here's the latest webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/Hashtable.8068427/webrev.03/

Re: RFR 8059324: orElseThrow has different signatures for OptionalPrimitive and Optional

On 20/01/15 16:56, Paul Sandoz wrote: Hi, http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8059324-Optional-orElseThrow-signatures/webrev/ Looks ok to me. The patch fixes up the signatures of Optional{Int, Long, Double}.orElseThrow to be consistent with Optional.orElseThrow. I believe this is

Re: [9] Review request : JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id

Hi, Chris I have done a pre-integration testing for this fix on Linux, Windows, Mac and Solaris x64 and sparc. I have run all regression tests for core libraries, and no new failures appeared. Can I push this change now or should I wait for an approve by one more person? Thanks -Konstantin

Re: RFR: JDK-8068427 Hashtable deserialization reconstitutes table with wrong capacity

Hi Martin and others, I have also modified the test per Martin's suggestion to factor out the serialClone() method. Here's the latest webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/Hashtable.8068427/webrev.03/ Is this ok now? Regards, Peter On 01/09/2015 11:16 AM, Peter Levart wrote:

Re: RFR 8048689: Clarify documentation on BaseStream.spliterator

Looks good to me Paul. -Chris. On 20/01/15 16:51, Paul Sandoz wrote: Hi, http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8048689-BaseStream-spliterator/webrev/ Some clarifications to the characteristics of the Spliterator returned from BaseStream.spliterator() (otherwise known as the "escape-ha

Re: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors

Hi, I have pushed this change. Thanks Brad, Alan and Chris for reviews. Regards, Peter On 01/06/2015 08:52 PM, Bradford Wetmore wrote: I only looked at test, looks good to me. I'd rarely ask to remove extra prints in tests. It adds initial debugging data points in case something breaks down

Re: [9] RFR (M): 8063137: Never-taken branches should be pruned when GWT LambdaForms are shared

Duncan, sorry for that. Updated webrev inplace. Best regards, Vladimir Ivanov On 1/21/15 1:39 PM, MacGregor, Duncan (GE Energy Management) wrote: > This version seems to have inconsistent removal of ignore profile in the > hotspot patch. It’s no longer added to vmSymbols but is still referenced >

Re: 8050820: Please add java.util.Optional.stream() to convert Optional to Stream

On 01/21/2015 12:01 PM, Paul Sandoz wrote: On Jan 21, 2015, at 10:25 AM, Paul Sandoz wrote: Hi Andreas, On Jan 21, 2015, at 10:00 AM, Andreas Lundblad wrote: Hi Paul, My name is Andreas Lundblad, and I joined the langtools team a little more than a year ago. I'm not a Reviewer or anythi

Re: 8050820: Please add java.util.Optional.stream() to convert Optional to Stream

On Jan 21, 2015, at 10:25 AM, Paul Sandoz wrote: > Hi Andreas, > > On Jan 21, 2015, at 10:00 AM, Andreas Lundblad > wrote: >> Hi Paul, >> >> My name is Andreas Lundblad, and I joined the langtools team a little more >> than a year ago. I'm not a Reviewer or anything but I casually read thro

Re: [8u60] RFR 8069302 Deprecate Unsafe monitor methods in JDK 8u release

On 01/21/2015 11:35 AM, Paul Sandoz wrote: Hi, The Unsafe monitor methods monitorEnter. monitorExit and tryMonitorEnter were removed from JDK 9 [1]. I would like to mark those methods as deprecated in 8u60. I doubt no one will notice :-) but it's the correct thing to do. Paul. [1] http://h

[8u60] RFR 8069302 Deprecate Unsafe monitor methods in JDK 8u release

Hi, The Unsafe monitor methods monitorEnter. monitorExit and tryMonitorEnter were removed from JDK 9 [1]. I would like to mark those methods as deprecated in 8u60. I doubt no one will notice :-) but it's the correct thing to do. Paul. [1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/0a0a0986

Re: 8050820: Please add java.util.Optional.stream() to convert Optional to Stream

Hi Andreas, On Jan 21, 2015, at 10:00 AM, Andreas Lundblad wrote: > Hi Paul, > > My name is Andreas Lundblad, and I joined the langtools team a little more > than a year ago. I'm not a Reviewer or anything but I casually read through > your patch out of curiosity. > > You don't seem to be a

Re: 8050820: Please add java.util.Optional.stream() to convert Optional to Stream

On Tue, Jan 20, 2015 at 06:59:52PM +, Paul Sandoz wrote: > Hi, > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8050820-Optional-stream/webrev/ > > This is one of those cases where i think adding a new method to Optional > carries enough weight. > > It can be really awkward to use Optional

Re: [9] request for review: 8049171: Additional tests for jarsigner's warnings

Thanks for adding so many tests. Some suggestions: - JarUtils.java You can use the new InputStream.transferTo() method. I am not sure if I understand updateJar correctly. It looks like srcJarFile is opened multiple times so its entries are duplicated a lot in the destination. Or is there a sec