Hi Patrick,
You patch looks alright.
But I wonder whether a cleaner solution would not be to add a parentPathv
pointer to the ChildStuff structure and pass it down to JDK_execvpe that
way, like we do for all other input arguments of that function. If it is an
input argument, seems strange to
Looks good
-Sundar
On 05/02/20 3:18 am, Mandy Chung wrote:
ProxyGenerator_v49 was the old proxy generator that has been replaced
with ASM in JDK 14 [1]. This patch removes this old version.
Webrev:
http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8230047/webrev.00/
thanks
Mandy
[1]
Thank you for the quick feedback.
I have updated the Webrev
http://cr.openjdk.java.net/~alvdavi/webrevs/8235699/webrev.8u.jdk.06/
Regards,
Clive Verghese
On 2/4/20, 4:42 PM, "core-libs-dev on behalf of Roger Riggs"
wrote:
Hi Clive,
To clarify about the Oracle copyright, it
Hi Clive,
To clarify about the Oracle copyright, it should be included only if the
file was
derived from Oracle copyright source. The previous copyright is fine.
Sorry for any confusion.
Regards, Roger
On 2/4/20 5:20 PM, Roger Riggs wrote:
Hi Clive,
The update looks good to me.
Thanks,
Thanks for the quick review, Roger.
Mandy
On 2/4/20 2:01 PM, Roger Riggs wrote:
Looks fine
On 2/4/20 4:48 PM, Mandy Chung wrote:
ProxyGenerator_v49 was the old proxy generator that has been replaced
with ASM in JDK 14 [1]. This patch removes this old version.
Webrev:
Hi Clive,
The update looks good to me.
Thanks, Roger
On 2/4/20 5:17 PM, Verghese, Clive wrote:
Hi Roger,
Thank you for the feedback. I have addressed your comments and updated the
Webrev.
http://cr.openjdk.java.net/~alvdavi/webrevs/8235699/
Regards,
Clive Verghese
On 2/4/20, 12:34 PM,
Hi Roger,
Thank you for the feedback. I have addressed your comments and updated the
Webrev.
http://cr.openjdk.java.net/~alvdavi/webrevs/8235699/
Regards,
Clive Verghese
On 2/4/20, 12:34 PM, "core-libs-dev on behalf of Roger Riggs"
wrote:
Hi Clive,
A few comments:
Looks fine
On 2/4/20 4:48 PM, Mandy Chung wrote:
ProxyGenerator_v49 was the old proxy generator that has been replaced
with ASM in JDK 14 [1]. This patch removes this old version.
Webrev:
http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8230047/webrev.00/
thanks
Mandy
[1]
ProxyGenerator_v49 was the old proxy generator that has been replaced
with ASM in JDK 14 [1]. This patch removes this old version.
Webrev:
http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8230047/webrev.00/
thanks
Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-8207814
On 04/02/2020 17:45, Erik Joelsson wrote:
Does anyone have an opinion on this?
I think this looks okay, would be good if Henry could look at it too as
we've been bitten by changes in this area, I think with Eclipse Tools
that are locating in unusual ways (we think Info.plist). I was happy to
sorry, I meant: "the fix attempts to clarify" instead of: "pretends to
clarify"
Vicente
On 2/4/20 3:38 PM, Vicente Romero wrote:
Please review the fix for [1] at [2] along with the corresponding CSR
at [3]. The fix pretends to clarify the specification for
java.lang.Record. Please see the
Please review the fix for [1] at [2] along with the corresponding CSR at
[3]. The fix pretends to clarify the specification for java.lang.Record.
Please see the CSR for more detail,
Thanks,
Vicente
PS, thanks to John Rose for proposing this fix
[1]
Hi Clive,
A few comments:
The copyrights for the new files need to follow the template in
make/template/gpl-header.
In particular, it needs to include Oracle as a copyright holder.
bug235699.java:
The @summary should be more informative; "it works" tells nothing about
the case being
Hi,
A Reminder for review.
Regards,
Clive Verghese
On 1/2/20, 1:18 PM, "Verghese, Clive" wrote:
Hi Alan,
Thanks for the feedback,
I have removed the @Author tag and updated the tests as per your
recommendation.
Updated Webrev
Does anyone have an opinion on this?
/Erik
On 2020-01-31 07:31, Erik Joelsson wrote:
In JDK-8235687 the MacOS bundle distribution of the JDK was changed to
conform to Apple requirements by changing Contents/MacOS/libjli.dylib
from a symlink into ../Home/lib/libjli.dylib to a copy of that
Hello.
This is reminder, again.
Could you review CSR JDK-8233385 [1] ?
[1] https://bugs.openjdk.java.net/browse/JDK-8233385
Thanks,
Ichiroh Takiguchi
On 2020-01-22 02:47, naoto.s...@oracle.com wrote:
Looks good to me.
Naoto
On 1/20/20 4:30 AM, Ichiroh Takiguchi wrote:
Hello.
This is just
Looks good. Thanks for the update.
Naoto
On 2/3/20 6:29 PM, li.ji...@oracle.com wrote:
Hi Naoto,
Seems the tool parsed the version and encoding attributes, and wrote
back with the values. Actually I don't know how they works, but since
this is a minor issue from t9n tool side, I had added a
Hi
I split the original patch into parts for corresponding function review, here
is the very simple change to java.base/unix/native/libjava/childproc.c and .h.
Could core-libs-dev group help review and sponsor this? thanks in advance.
JBS: https://bugs.openjdk.java.net/browse/JDK-8238380 (a
Hi Chris,
as you mention, supporting such a use case safely is a non starter. That
of native interop tools that will come along once we start addressing
the foreign function problem, there will be a tool to create an
'unchecked' segment from a given address you might know by some other
means.
- Mail original -
> De: "Сергей Цыпанов"
> À: "jonathan gibbons" , "core-libs-dev"
>
> Envoyé: Mardi 4 Février 2020 08:53:31
> Objet: Re: [PATCH] Enhancement proposal for java.util.StringJoiner
> Hello,
Hi Sergey,
>
> I'd probably agree about a new class in java.lang, but what is
20 matches
Mail list logo
