RE:[PING] RFR: JDK-8135259: InetAddress.getAllByName only reports "unknown error" instead of actual cause

Hi all, Please help me in getting this review done. Regards, Ramanand. -Original Message- From: Ramanand Patil Sent: Friday, February 05, 2016 10:46 PM To: core-libs-dev@openjdk.java.net Subject: RFR: JDK-8135259: InetAddress.getAllByName only reports "unknown error" instead of actual

Re: RFR: 8071368 Use more concrete types for NamedFunction constants in the code

Gentle Reminder! On 2/5/2016 9:18 PM, Vladimir Ivanov wrote: Proposed fix looks good. Quoting John: "The use of erased types (any ref => Object) in the MH runtime is an artifact of bootstrapping difficulties, early in the project. I hope it is not necessary any more." Best regards, Vladim

Re: RFR 8138884:MethodHandles.Lookup.findVirtual() Javadoc fails to consider private interface methods

Hi All, Please review my updated patch http://cr.openjdk.java.net/~srastogi/8138884/webrev.01/ Same is not applicable for "Lookup.unreflect()". Thanks, Shilpi Hi All, Please review my fix related to java doc. MethodHandles.Lookup.findVirtual() Javadoc fails to consider private methods of a

Re: OpenJDK bug question (JDK-6519463)

On 10/02/2016 2:20 PM, David Hoffer wrote: That issue has the same problem, it references files that are not in the bug report so it won't help, really need all files to be attached to the bug report. Is the attachment a.zip.Z not visible to you on the bug report? David That being said we th

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On 10/02/2016 1:42 PM, Mikael Vidstedt wrote: Can I please get a quick review of these updated webrevs: In terms of the incremental changes this looks fine. If you consider it all reviewed then nothing in the increments should change that. But looking at the JDK code I have some follow up s

Re: Compact Strings and APIs for fast decoding of string data

Hi Chris, I think basically you are asking a String constructor that takes a ByteBuffer. StringCoding then can take advantage of the current CompactString design to optimize the decoding operation by just a single byte[]/vectorized memory copy from the ByteBuffer to the String's internal byte

Re: OpenJDK bug question (JDK-6519463)

That issue has the same problem, it references files that are not in the bug report so it won't help, really need all files to be attached to the bug report. That being said we think we have tracked our problem down to a file transfer step after compression so I don't think our issue pertains to J

Re: OpenJDK bug question (JDK-6519463)

On 10/02/2016 4:51 AM, David Hoffer wrote: We have a production environment where we are getting errors similar to what was reported in JDK-6519463. I would like to test our code with the test file (buggedfile.bin) used in this bug report but the file is posted on an ftp server that is not publi

Re: New Collection framework?

On 9/02/2016 5:29 AM, Thomas Kamps wrote: Hi everyone, Did you ever think about a new Collection framework for Java? A new framework would need to be significantly better than the existing one to ever consider any kind of replacement. It would need to be compatible in such a way that users c

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

Can I please get a quick review of these updated webrevs: hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.05/hotspot/webrev/ jdk: http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.05/jdk/webrev/ incremental webrevs: hotspot: http://cr.openjdk.java.net/~mikael/web

Re: Unexpected BindException in Endpoint.publish

Hi Miroslav, Thank you for your sponsor! : https://bugs.openjdk.java.net/browse/JDK-8146086 Can I ask the schedule when does this fix backport to JDK8 ? Thanks, Yuji 2015-12-02 22:39 GMT+09:00 Miroslav Kos : > Hi Yuji, > thanks for the patch - it fixes the issue and looks ok to me. I'll integra

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi, Yet another webrev, http://cr.openjdk.java.net/~sdrach/8132734/webrev.06/ , with a change to JarEntryIterator to fix a problem discovered by performance tests — calling hasNext() twice as often as needed. I also removed the @since 9 ta

Re: JDK 9 RFR of JDK-8149492: Problem list CheckEncodings.sh

Hi Joe, Adding this test to the problem list looks fine to me. s'marks On 2/9/16 11:34 AM, joe darcy wrote: Hello, As noted in bug JDK-7008363, the test test/java/lang/StringCoding/CheckEncodings.sh "does nothing and is very slow at that" Until and unless the problems noted in JDK-7008363

Re: RFR 8046339: sun.rmi.transport.DGCAckHandler leaks memory

Hi Ivan, Thanks for picking up this old bug. The fix and the change to the regression test look good. s'marks On 2/8/16 11:17 PM, Ivan Gerasimov wrote: Hello! This is a request to help review a fix for the problem which can lead to memory leakage under some rare circumstances. The fix itse

Re: JDK 9 RFR of JDK-8149492: Problem list CheckEncodings.sh

+1 On 2/9/16 2:34 PM, joe darcy wrote: Hello, As noted in bug JDK-7008363, the test test/java/lang/StringCoding/CheckEncodings.sh "does nothing and is very slow at that" Until and unless the problems noted in JDK-7008363 are addressed, there is little point in running the test and it should

JDK 9 RFR of JDK-8149492: Problem list CheckEncodings.sh

Hello, As noted in bug JDK-7008363, the test test/java/lang/StringCoding/CheckEncodings.sh "does nothing and is very slow at that" Until and unless the problems noted in JDK-7008363 are addressed, there is little point in running the test and it should be put on the problem list. Please re

OpenJDK bug question (JDK-6519463)

We have a production environment where we are getting errors similar to what was reported in JDK-6519463. I would like to test our code with the test file (buggedfile.bin) used in this bug report but the file is posted on an ftp server that is not publicly available. Can this file be attached to

Re: [concurrency-interest] ClassLoader deadlock

The 0x040ebee8 monitor is most likely being held by native code. Regards, Peter Firmstone. On 7/02/2016 4:27 AM, Peter Levart wrote: On 02/06/2016 01:17 PM, Peter Firmstone wrote: The security manager is non blocking, unfortunately java system classes aren't. It doesn't seem so. At least

Re: [concurrency-interest] ClassLoader deadlock

Thanks Peter & David, That's good to know. I've altered the SecurityManager to perform a permission check prior to becoming the security manager, this ensures the cache has been created, to avoid any recursive deadlock prone calls. The class that both threads are attempting to load and init

New Collection framework?

Hi everyone, Did you ever think about a new Collection framework for Java? My main complains about the java.util Collections are: * No co/contra variance for assigning. Which forbids assigments like List foo = new List(); Currently it can be bypassed when using wildcards, but then you cannot ad

Compact Strings and APIs for fast decoding of string data

Hi, Aleksey Shipilev did a talk on his journey to implement compact strings and indified string concat at the JVM Tech Summit yesterday, and this reminded me that we (Neo4j) have a need for turning segments of DirectByteBuffers into Strings as fast as possible. If we already store the string da

Re: DeserializationPermission Proposal

On 02/08/2016 10:19 PM, Peter Firmstone wrote: Why not, just prior to instantiating an object just prior to deserializing, add each class' ProtectionDomain in the objects hierarchy to an AccessControlContext and pass this to the SecurityManager's two argument checkPermission call? This permis

Re: We don't need jdk.internal.ref.Cleaner any more

Peter, On 08/02/16 10:58, Peter Levart wrote: On 02/08/2016 10:33 AM, Chris Hegarty wrote: On 8 Feb 2016, at 06:27, Alan Bateman wrote: On 07/02/2016 22:20, Peter Levart wrote: : If the decision to remove sun.misc.Cleaner was partly influenced by the desire to maintain just 2 instead of

Re: RFR [9] 8148861: Remove sun.misc.ManagedLocalsThread from jaxws

Looks ok to me, will take care of it in standalone project. Thanks Miran On 08/02/16 17:20, Chris Hegarty wrote: Receiving some feedback off list, this code needs to be able to run on older releases, so the new Thread constructor, added in JDK 9, should be accessed reflectively. Webrev updated

Re: ObjectInputStream SPI

Peter, I, along with others within Oracle, are interested in this general area. We are tied up with other issues at the moment, but I hope to get this within the next couple of weeks. -Chris. On 04/02/16 00:40, Peter Firmstone wrote: In light of recent examples of gadget deserialization attack

Re: API review of VarHandles

Hi Jeremy, Sorry for the late reply. Catching after some distractions and being away. > On 22 Jan 2016, at 19:03, Jeremy Manson wrote: > > Couple of thoughts: > The Java Language Specification permits operations to be executed in orders > different than are apparent in program source code, su