Re: RFR: 8234964: failure_handler: gather more environment information on Windows, Solaris and Linux

Hi Julia, Changes looks OK to me although i have one question, in case of Solaris you use explicit path to ifconfig(ifconfig.app=/sbin/ifconfig). Does Solaris by default doesn't set the /sbin folder to user's 'PATH' environment variable ?. Thanks, Vyom On Fri, Nov 29, 2019 at 12:18 AM Igor

Re: RFR: 8234964: failure_handler: gather more environment information on Windows, Solaris and Linux

Hi Julia, looks good to me. to make it more consistent w/ other tools, I'd move all ifconfig (incl. one on macOS) to 'net' category, i.e. rename them to net.ifconfig, this will require also moving all netstat.* on macOS and solaris to 'net' as well. I don't insist on it, though. -- Igor >

Re: RFR: JEP 359: Records (Preview) (full code)

Hi Vicente, generally looks good - few comments below; I tried to focus on areas where the compiler code seemed to diverge from the spec, as well on pieces of code which look a leftover from previous spec rounds. * canonical constructors *can* have return statements - compact constructors

RFR: 8234964: failure_handler: gather more environment information on Windows, Solaris and Linux

Hi, In the case of test failure, the environment information of 'ifconfig -a' is already gathered on macOS systems. The following enhancement allows the same information to be gathered on Linux, Solaris and Windows systems (in the latter case 'ipconfig /all'). Bug:

Re: New candidate JEP: 370: Foreign-Memory Access API

Second, what about an API to allocate memory from the stack?  This is really useful in GraalVM (granted they have a sort-of-Panama-ish way of calling C functions already, and they're really quite "loose" when it comes to safety in some regards) and could simplify some things already,

Re: RFR: JEP 359: Records (Preview) (full code)

Hi again, Sorry but I realized that I forgot to remove some code on the compiler side. The code removed is small, before we were issuing an error if some serialization methods were declared as record members. That section was removed from the spec. I have prepared another iteration with this

Re: RFR: 8234821: remove unused functions from libjli

On 28/11/2019 12:02, Baesken, Matthias wrote: Thanks for the review . I'll adjust the COPYRIGHT . Will push this as XS in case of no objections. I think this look okay. I assume you'll send a job through jdk-submit in case there are any residual launcher or installer code that also need to

RE: RFR: 8234821: remove unused functions from libjli

Thanks for the review . I'll adjust the COPYRIGHT . Will push this as XS in case of no objections. Best regards, Matthias > -Original Message- > From: Langer, Christoph > Sent: Donnerstag, 28. November 2019 11:35 > To: Baesken, Matthias ; core-libs- > d...@openjdk.java.net > Subject:

RE: RFR: 8234821: remove unused functions from libjli

Hi Matthias, overall this looks good to me. The only change to src/java.base/share/native/libjli/jli_util.c is the copyrights, so I guess this should be omitted... Cheers Christoph > -Original Message- > From: core-libs-dev On Behalf > Of Baesken, Matthias > Sent: Mittwoch, 27.

Re: JDK 14 RFR of JDK-8234917: "Explicitly discuss java.lang.Enum in Class.isEnum spec"

Looks good Joe. -Chris. > On 27 Nov 2019, at 15:44, Joe Darcy wrote: > > Hello, > > Please review the small doc RFE to address > > JDK-8234917: "Explicitly discuss java.lang.Enum in Class.isEnum spec" > > Patch below; thanks, > > -Joe > > ---