On 2020-09-01 11:46, Kim Barrett wrote:
On Sep 1, 2020, at 4:01 AM, Eric Liu wrote:
Hi all,
Please review this simple change to fix some compile warnings.
The newer gcc (gcc-8 or higher) would warn for calls to bounded string
manipulation functions such as 'strncpy' that may either truncate t
>
> On macOS you need to set the variables differently, but I think it can still
> work. The variables known to your shell are not the same as those known to
> LaunchServices. For those use the launchctl command to set them.
>
I’m not that familiar with launchctl. Is this something the app
> On Sep 1, 2020, at 5:22 PM, Michael Hall wrote:
>
>
>>
>>
>>> Is there a way to pass values from environment variables when using
>>> --java-options?
>>>
>>> It would be nice to be able to write something like this:
>>> --java-options "-DmyAppData=$HOME/.myData"
>>>
>>> (Instead of usin
Hi Joe
Looks fine to me
--
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
> On Sep 1, 2020, at 5:12 PM, Joe Wang wrote:
>
> Please review a fix to report CCE when keys or values ar
Hi Joe,
Looks good to me. The test can declare @Test(expected = CCE.class) to
eliminate storeToXML(), but I am ok with either way.
Naoto
On 9/1/20 2:12 PM, Joe Wang wrote:
Please review a fix to report CCE when keys or values are not Strings as
specified.
JBS: https://bugs.openjdk.java.net
Great to see this - thank you for all the great work you’re putting into it!
The changes are in line with what I’m expecting given that I’ve looked at them
before, so looks good to me! That said, I’ve looked at this so many times now -
and after all even authored some of the original changes -
>
>> Is there a way to pass values from environment variables when using
>> --java-options?
>>
>> It would be nice to be able to write something like this:
>> --java-options "-DmyAppData=$HOME/.myData"
>>
>> (Instead of using the $ sign, another notation may be more appropriate, in
>> order to n
Please review a fix to report CCE when keys or values are not Strings as
specified.
JBS: https://bugs.openjdk.java.net/browse/JDK-8252354
webrev: http://cr.openjdk.java.net/~joehw/jdk16/8252354/webrev/
Thanks,
Joe
On 9/1/2020 11:54 AM, Michael Hall wrote:
On Sep 1, 2020, at 10:30 AM, Andy Herrick wrote:
I have been following this discussion , and feel it is worth pursuing.
Currently , the values of --arguments and --java-options are pre-processed at
launch time by expanding the values of $APPDIR, $
If memory serves me correctly we added these methods for completeness when
doing VarHandles, but we deferred any intrinsic work (do it when really needed).
This looks good to me. Minor tweak. I would recommend using an @implNote to be
clear this not permanent behavior and could change e.g.:
* @
Hi Vipin,
Looks fine.
Though I would also correct the indentation and join source lines in a
few cases.
MasrshalledObject.java. Continuation lines should be indented. Lines
110 and 164, 166.
Naming.java: Join line 110, 137, 162, 191: "appropriately... formatted URL"
Thanks, Roger
Hi,
All,
Per an earlier discussion submitted with a patch but without a JBS entry (my
fault!).
This is an RFR to update the docs in Unsafe for some of the fence methods to
better reflect the current state of affairs in the file. Updating the verbiage
to make it less opinionated per some previous c
Wouldn't you require the sun.arch.data.model == "64" jtreg config in
these tests also ?
regards,
Sean.
On 28/08/2020 19:13, Fernando Guallini wrote:
Hi,
May I please get reviews and a sponsor for this trivial change:
webrev: http://cr.openjdk.java.net/~fguallini/8249694/webrev.00/
Tes
Hi,
Please review and sponsor the fix for replacing @exception with @throws in
java.rmi package.
Issue: https://bugs.openjdk.java.net/browse/JDK-8252538
Webrev: https://cr.openjdk.java.net/~vsharma/8252538/webrev.01/
Regards,
Vipin
> On Sep 1, 2020, at 10:30 AM, Andy Herrick wrote:
>
> I have been following this discussion , and feel it is worth pursuing.
>
> Currently , the values of --arguments and --java-options are pre-processed at
> launch time by expanding the values of $APPDIR, $ROOTDIR, and $BINDIR to
> values
I have been following this discussion , and feel it is worth pursuing.
Currently , the values of --arguments and --java-options are
pre-processed at launch time by expanding the values of $APPDIR,
$ROOTDIR, and $BINDIR to values determined by the native launchers.
If we can do so without brea
> On Sep 1, 2020, at 9:23 AM, Michael Hall wrote:
>
>
>
>> On Sep 1, 2020, at 2:07 AM, Serban Iordache
>> wrote:
>>
>> Not sure if it was clear from my previous messages, but what I am asking for
>> is that the environment variables are expanded with the values they have on
>> the user'
On 01/09/2020 11:53, Yangfei (Felix) wrote:
> Sure, I am happy if the original author of the assembly code or someone else
> from Linaro could help here.
> I wasn't aware there was such an requirement here given that assembly code is
> licensed under GPL.
There sure is. All code must be contri
> On Sep 1, 2020, at 2:07 AM, Serban Iordache wrote:
>
> Not sure if it was clear from my previous messages, but what I am asking for
> is that the environment variables are expanded with the values they have on
> the user's machine (not on the machine where jpackage has been executed).
I
Hi Daniel, Kim,
Thanks for your review.
> Kim Barrett on Tue Sep 1 09:46:26 UTC 2020
>
> Changes look good, subject to that caveat. I think these changes conform
> better to the documented description of the warning than did the recent
> NetworkInterface.c change mentioned above, so I’m hopeful
Hi Evan,
Looks fine.
Thanks, Roger
On 9/1/20 9:14 AM, Evan Whelan wrote:
Hi all,
This RFR is for a small change to fix a grammatical error in Thread#interrupt()
docs.
JBS Link: https://bugs.openjdk.java.net/browse/JDK-8248772
Patch seen below.
--- old/open/src/java.base/sh
On 2020-09-01 13:41, Aleksei Voitylov wrote:
Hi,
JEP 386 is now Candidate [1] and as we resolved all outstanding issues
within the Portola project I'd like to ask for comments from HotSpot,
Core Libs (changes in libjli/java_md.c), and Build groups before moving
the JEP to Proposed to Target:
ht
Hi all,
This RFR is for a small change to fix a grammatical error in Thread#interrupt()
docs.
JBS Link: https://bugs.openjdk.java.net/browse/JDK-8248772
Patch seen below.
--- old/open/src/java.base/share/classes/java/lang/Thread.java 2020-09-01
13:00:37.91378 +
+++ new
Build changes look ok.
/Erik
On 2020-09-01 04:41, Aleksei Voitylov wrote:
Hi,
JEP 386 is now Candidate [1] and as we resolved all outstanding issues
within the Portola project I'd like to ask for comments from HotSpot,
Core Libs (changes in libjli/java_md.c), and Build groups before moving
the
Hi Eric, Kim,
On 01/09/2020 10:46, Kim Barrett wrote:
he changes being made to getIndex and
getFlags (NetworkInterface.c) are modifying lines that were changed very
recently to deal with such warnings from gcc10. I'm worried that these new
changes will re-trigger warnings from gcc10 (though thi
Hi,
JEP 386 is now Candidate [1] and as we resolved all outstanding issues
within the Portola project I'd like to ask for comments from HotSpot,
Core Libs (changes in libjli/java_md.c), and Build groups before moving
the JEP to Proposed to Target:
http://cr.openjdk.java.net/~avoitylov/webrev.8247
Hi,
> -Original Message-
> From: Andrew Haley [mailto:a...@redhat.com]
> Sent: Tuesday, September 1, 2020 3:52 PM
> To: Yangfei (Felix) ; hotspot-compiler-
> d...@openjdk.java.net; core-libs-dev@openjdk.java.net
> Cc: aarch64-port-...@openjdk.java.net; Stuart Monteith
>
> Subject: Re: [aa
> On Sep 1, 2020, at 5:46 AM, Kim Barrett wrote:
>
>> On Sep 1, 2020, at 4:01 AM, Eric Liu wrote:
>>
>> Hi all,
>>
>> Please review this simple change to fix some compile warnings.
>>
>> The newer gcc (gcc-8 or higher) would warn for calls to bounded string
>> manipulation functions such as '
> On Sep 1, 2020, at 4:01 AM, Eric Liu wrote:
>
> Hi all,
>
> Please review this simple change to fix some compile warnings.
>
> The newer gcc (gcc-8 or higher) would warn for calls to bounded string
> manipulation functions such as 'strncpy' that may either truncate the
> copied string or leav
Hi Eric,
The changes to NetworkInterface.c look good to me.
best regards,
-- daniel
On 01/09/2020 09:01, Eric Liu wrote:
Hi all,
Please review this simple change to fix some compile warnings.
The newer gcc (gcc-8 or higher) would warn for calls to bounded string
manipulation functions such
Hi all,
Please review this simple change to fix some compile warnings.
The newer gcc (gcc-8 or higher) would warn for calls to bounded string
manipulation functions such as 'strncpy' that may either truncate the
copied string or leave the destination unchanged.
This patch fixed stringop-truncati
On 31/08/2020 10:46, Yangfei (Felix) wrote:
>
>> -Original Message-
>> From: Andrew Haley [mailto:a...@redhat.com]
>> Sent: Monday, August 31, 2020 4:41 PM
>> On 31/08/2020 07:50, Yangfei (Felix) wrote:
>>>
>>
>> This looks like a direct copy of the sha3-cecore.S file.You'll need Linaro to
32 matches
Mail list logo
