Re: RFR 9: 8176272 : (process) ProcessHandle::onExit fails to wait for non-child process

> On 15 Mar 2017, at 18:53, Roger Riggs wrote: > > Hi Thomas, > > Good idea. Though it is unlikely that the pid would be re-used between the > checks of isAlive > but that will remove any window. > > Updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-processhandle-onexit-8176272/ind

RFR 8175013: Add @Generated Annotation

Hi all, Per the discussion [1], please find the webrev for adding a replacement annotation for javax.annotation.Generated . The CCC has been approved. The webrev can be found at: http://cr.openjdk.java.net/~lancea/8175013/webrev.00/

Re: RFR 8175013: Add @Generated Annotation

On 16/03/2017 13:42, Lance Andersen wrote: Hi all, Per the discussion [1], please find the webrev for adding a replacement annotation for javax.annotation.Generated . It would be good to have a link from the old @Generated to the new. -Alan

Re: RFR 9: 8176272 : (process) ProcessHandle::onExit fails to wait for non-child process

Thanks Roger. This looks good to me now. Thomas On Wed, Mar 15, 2017 at 7:53 PM, Roger Riggs wrote: > Hi Thomas, > > Good idea. Though it is unlikely that the pid would be re-used between > the checks of isAlive > but that will remove any window. > > Updated webrev: > http://cr.openjdk.java.

Re: RFR 8175013: Add @Generated Annotation

I can ask Roman to include that in the update that he is working on. Best Lance > On Mar 16, 2017, at 9:51 AM, Alan Bateman wrote: > > > > On 16/03/2017 13:42, Lance Andersen wrote: >> Hi all, >> >> Per the discussion [1], please find the webrev for adding a replacement >> annotation for j

Re: RFR 9: 8176272 : (process) ProcessHandle::onExit fails to wait for non-child process

Hi Thomas, Chris. I updated the webrev with Chris's suggestion and will push after tests complete. http://cr.openjdk.java.net/~rriggs/webrev-processhandle-onexit-8176272/index.html Thanks for the review and

Re: RFR 8175013: Add @Generated Annotation

And deprecate the old. Maybe it will be done as a part of another commit given javax.annotation.Generated is in another workspace. so i've added compiler-dev, since this will be commited to langtools. Rémi - Mail original - > De: "Alan Bateman" > À: "Lance Andersen" , "core-libs-dev"

Re: RFR 8175013: Add @Generated Annotation

Hi Remi, > On Mar 16, 2017, at 10:32 AM, Remi Forax wrote: > > And deprecate the old. We will be deprecating the Java EE modules in Java SE so in a sense that is happening. It would require an MR to common annotations to deprecate the annotation in javax.annotation. and the Java EE folks do

RFR[9] 8160956: Runtime.Version.compareTo/compareToIgnoreOpt problem

Hello, Please review the following trivial change for [1]: http://cr.openjdk.java.net/~prappo/8160956/webrev.00/ The code change fixes the implementation and makes it adhere to the specification for Version comparison: /** * Compares this version to another. * ... *

Re: RFR[9] 8160956: Runtime.Version.compareTo/compareToIgnoreOpt problem

2017/3/16 8:17:03 -0700, pavel.ra...@oracle.com: > Please review the following trivial change for [1]: > > http://cr.openjdk.java.net/~prappo/8160956/webrev.00/ Looks good to me. > ... > > P.S. While we are in this area, may I ask if anybody knows why exactly Version > class has lost its 'fin

RE: RRF(XS)(10): 8176797: [TESTBUG] tools/launcher/Settings.java -Xss size is too small

Hi Chris, This looks good, thanks for fixing this. Thanks, Christian -Original Message- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-boun...@openjdk.java.net] On Behalf Of Chris Plummer Sent: Thursday, March 16, 2017 12:59 AM To: hotspot-runtime-dev ; core-libs-dev@openjdk.jav

Re: RRF(XS)(10): 8176797: [TESTBUG] tools/launcher/Settings.java -Xss size is too small

Hi Chris, changes look good, the only note, seems like formatting moved a bit -"-Xss" + stackSize + "000", "-XshowSettings", "-jar", testJar.getAbsolutePath()); +"-Xss" + (stackSize * 1024), "-XshowSettings", "-jar", testJar.getAbsolutePath()); Best regards,

Re: RFR 8175013: Add @Generated Annotation

+1, I think retention beyond SOURCE makes sense. Stephen On 16 March 2017 at 15:44, Ron Shapiro wrote: > Are there any plans to make the new @Generated annotation have CLASS > retention? We have a number of compile-time tools that would like to know > when files are generated. No need at runtime

RE: RFR 9: 8165641 : Deprecate Object.finalize

Hi, The design decision to manage native threads on behalf of the Java programmer was made a long time ago. One consequence of that decision is that today there is no alternative threading library for Java that would allow me to terminate a thread that’s gone into an infinite loop, to give an

Re: RRF(XS)(10): 8176797: [TESTBUG] tools/launcher/Settings.java -Xss size is too small

Hello, I can't recall why String vs int. Formatting seems off, 81 tr = doExec(javaCmd, "-Xms64m", "-Xmx512m", 82 "-Xss" + stackSize + "k", "-XshowSettings", "-jar", testJar.getAbsolutePath()); 83 containsAllOptions(tr); 84 if (!tr.isOK()) { 85

Re: RRF(XS)(10): 8176797: [TESTBUG] tools/launcher/Settings.java -Xss size is too small

Hi Kumar, I explained the formatting changein a previous email, but I see now the formatting change I did on line 82 makes it inconsistent with similar source on line 82, so I'll change it back. thanks, Chris On 3/16/17 9:56 AM, Kumar Srinivasan wrote: Hello, I can't recall why String vs

RFR[9] 8176882: Incorrect integer comparison in version numbers

Hello, Please review the following trivial change for [1]: http://cr.openjdk.java.net/~prappo/8176882/webrev.00/ Thanks, -Pavel [1] https://bugs.openjdk.java.net/browse/JDK-8176882

Re: RFR[9] 8176882: Incorrect integer comparison in version numbers

> On 16 Mar 2017, at 10:22, Pavel Rappo wrote: > > Hello, > > Please review the following trivial change for [1]: > > http://cr.openjdk.java.net/~prappo/8176882/webrev.00/ > +1 Paul.

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

The changes to the JDK core classes are quite extensive. This will need rigorous functional and performance testing and it is very late in the release cycle to make these kinds of changes. But I'll leave that to the core-libs folk to comment on. I have the same concern. Can we fix the immediat

Re: RFR[9] 8160956: Runtime.Version.compareTo/compareToIgnoreOpt problem

> On 16 Mar 2017, at 08:27, mark.reinh...@oracle.com wrote: > > 2017/3/16 8:17:03 -0700, pavel.ra...@oracle.com: >> Please review the following trivial change for [1]: >> >> http://cr.openjdk.java.net/~prappo/8160956/webrev.00/ > > Looks good to me. > >> ... >> >> P.S. While we are in this a

JDK 10 RFR of 8176894: Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute in TreeMap

Hi All, Please, review: https://bugs.openjdk.java.net/browse/JDK-8176894 http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.00/ The issue was created for JDK10 in order to don't disturb JDK9 before launch. -- Best regards, Sergey Kuksenko

Re: JDK 10 RFR of 8176894: Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute in TreeMap

On 03/16/2017 08:04 PM, Sergey Kuksenko wrote: > http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.00/ Looks good. I assume there are enough tests to cover these paths? *) Missing whitespace (multiple times in the similar line): if(replaceOld) { Thanks, -Aleksey

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

On 3/15/17 6:19 PM, David Holmes wrote: src/share/vm/classfile/javaClasses.hpp Given the the only call to java_lang_String::set_debug_intrinsics is within an ifdef, shouldn't the declaration and definition of the method also be guarded the same way? OK I'll change it. dl

Re: RFR 8175013: Add @Generated Annotation

On 16/03/2017 15:44, Ron Shapiro wrote: Are there any plans to make the new @Generated annotation have CLASS retention? We have a number of compile-time tools that would like to know when files are generated. No need at runtime, but it would be good to have this information stick around. JSR

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

On 3/16/17 2:52 AM, Tobias Hartmann wrote: As a safety net, I added asserts around the intrinsic calls, and a try/catch that so any out of bounds exception turns into an assert error as well. So the assert and try/catch are only necessary to catch invalid offsets passed to the C1 intrinsic, ri

Re: RFR[9] 8160956: Runtime.Version.compareTo/compareToIgnoreOpt problem

Paul, One more question. I have read Version's javadoc and my impression is that Version could be a value-type class. Is that right? > On 16 Mar 2017, at 18:05, Paul Sandoz wrote: > >> >> On 16 Mar 2017, at 08:27, mark.reinh...@oracle.com wrote: >> >> 2017/3/16 8:17:03 -0700, pavel.ra...@ora

Re: RFR[9] 8160956: Runtime.Version.compareTo/compareToIgnoreOpt problem

> On 16 Mar 2017, at 13:27, Pavel Rappo wrote: > > Paul, > > One more question. I have read Version's javadoc and my impression is that > Version could be a value-type class. Is that right? > I suppose it could if there were such a thing as of today. It's not explicitly called out as being v

JDK 9 ServiceLoader bug

Hi All, I’ve found what I believe could (or should) be considered a bug with the way the ServiceLoader interacts with the classpath in JDK 9. Consider the following code: package example; import java.util.ServiceLoader; public class Main { public static void main(Str

Re: RFR[9] 8160956: Runtime.Version.compareTo/compareToIgnoreOpt problem

Exactly: * * This is a value-based * class; use of identity-sensitive operations (including reference equality * ({@code ==}), identity hash code, or synchronization) on instances of * {@code Optional} may have unpredictable results and should be avoided. * > On 16 Mar 2017, at 20:41, Paul Sando

Re: RFR[9] 8160956: Runtime.Version.compareTo/compareToIgnoreOpt problem

2017/3/16 14:31:21 -0700, pavel.ra...@oracle.com: > Exactly: > > * > * This is a value-based > * class; use of identity-sensitive operations (including reference equality > * ({@code ==}), identity hash code, or synchronization) on instances of > * {@code Optional} may have unpredictable results a

Re: RFR[9] 8160956: Runtime.Version.compareTo/compareToIgnoreOpt problem

> On 16 Mar 2017, at 14:33, mark.reinh...@oracle.com wrote: > > 2017/3/16 14:31:21 -0700, pavel.ra...@oracle.com: >> Exactly: >> >> * >> * This is a value-based >> * class; use of identity-sensitive operations (including reference equality >> * ({@code ==}), identity hash code, or synchronizatio

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

I got no response to this so I'm assuming everyone is happy now! :-) Bill Shannon wrote on 03/15/2017 03:20 PM: > Looks like I have a chance to tweak the comments for the JAF changes. > Any final comments before I apply these changes to all 4 copies of > this code? > > $ diff -u MailcapCommandMa