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

Hi Claes, On 17/06/2016 8:20 AM, Claes Redestad wrote: Hi David, On 2016-06-16 23:11, David Holmes wrote: On 16/06/2016 10:52 PM, Claes Redestad wrote: On 06/16/2016 02:48 PM, Chris Hegarty wrote: Apologies, you corrected me off-line, TG.allowThreadSuspension calls VM.unsuspendSomeThreads

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

> On 16 Jun 2016, at 14:44, Steve Drach wrote: > > This webrev uses methods instead of fields to return the base and runtime > values used internally by JarFile. I’ve also optimized it a bit. > > http://cr.openjdk.java.net/~sdrach/8150680/webrev.02/ >

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

Hi David, On 2016-06-16 23:11, David Holmes wrote: On 16/06/2016 10:52 PM, Claes Redestad wrote: On 06/16/2016 02:48 PM, Chris Hegarty wrote: Apologies, you corrected me off-line, TG.allowThreadSuspension calls VM.unsuspendSomeThreads ( which is a no-op ) and not VM.unsuspendThreads ( which

[9] RFR: 8159548: Formatter returns unexpected strings if locale is null.

Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8159548 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8159548/webrev.00/ The previous fix to 8146156 overly localized the formatted text for the "null" locale. The offending localiz

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

This webrev uses methods instead of fields to return the base and runtime values used internally by JarFile. I’ve also optimized it a bit. http://cr.openjdk.java.net/~sdrach/8150680/webrev.02/ > On Jun 15, 2016, at 4:31 PM, Joseph D. Dar

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

On 16/06/2016 10:52 PM, Claes Redestad wrote: On 06/16/2016 02:48 PM, Chris Hegarty wrote: Apologies, you corrected me off-line, TG.allowThreadSuspension calls VM.unsuspendSomeThreads ( which is a no-op ) and not VM.unsuspendThreads ( which I thought it did ). In which case I am ok with the

Re: RFR 9: 8155808: Process.getInputStream().skip() method is faulty

Ping? On 6/13/2016 11:06 AM, Roger Riggs wrote: A latent issue with Process InputStreams support for the skip method was reported[1]. Though the InputStream returned is a BufferedInputStream, in some cases, the skip method calls FileInputStream.seek on the pipe containing output from the proc

Re: Proposal: java.lang.reflect.Proxy and default methods

> On Jun 16, 2016, at 12:29 PM, Mandy Chung wrote: > > Can you elaborate how proxy and default methods affects your library to able > to run with security manager? So in this particular case, I wanted to create an interface type where some methods are automatically generated from declarative

Re: Proposal: java.lang.reflect.Proxy and default methods

Can you elaborate how proxy and default methods affects your library to able to run with security manager? This is a good enhancement. I have created a JBS issue to track that [1]. There is no such existing enhancement request in JBS. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8159746

Re: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST

Hi, Late to this thread… I think for consistency it’s ok to apply in all three cases. I will push today. — Another trivial fix in Collections would be to go through the nested classes and mark appropriate classes as final. Paul. > On 28 May 2016, at 11:27, Louis Wasserman wrote: > > Do you

Re: Proposal: java.lang.reflect.Proxy and default methods

Hi everyone, I am glad this was discussed on the list again. I just wanted to throw out there, as a library developer and end user, I now have had to reproduce this hack in no fewer than four different projects for various reasons. It is even worse because it means that my library cannot run unde

RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors

Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8143211 Webrev: http://cr.openjdk.java.net/~mhaupt/8143211/webrev.00/ The change puts the tryFinally and loop method handle combinator implementations, which were introduced as part of the JEP 274 effort, on a La

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

On 06/16/2016 02:48 PM, Chris Hegarty wrote: Apologies, you corrected me off-line, TG.allowThreadSuspension calls VM.unsuspendSomeThreads ( which is a no-op ) and not VM.unsuspendThreads ( which I thought it did ). In which case I am ok with the change. Ok, thanks! :-) I think we should

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

Apologies, you corrected me off-line, TG.allowThreadSuspension calls VM.unsuspendSomeThreads ( which is a no-op ) and not VM.unsuspendThreads ( which I thought it did ). In which case I am ok with the change. I think we should add ‘forRemoval = true’ while here. -Chris. > On 16 Jun 2016, a

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

OK grand so, will make that change ... thanks Chris regards Mark On 16/06/2016 06:40, Chris Hegarty wrote: 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

Question about signature polymorphic, the VM spec of Java 7+, and VarHandles

Hi, the Java VM spec tells you the following how to "detect" signature polymorphic methods in bytecode: === A method is signature polymorphic if and only if all of the following conditions hold : - It is declared in the java.lang.invoke.MethodHandle class. - It has a single formal parameter of