Hi Aleksei,
Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.01/
This refactoring seems okay. I would suggest to change the run method
to return an int or boolean to indicate the test passed or failed. The
caller of the run method (i.e. runTest will add to the failedTests
Hi Brent,
On 7/21/20 2:56 PM, Brent Christian wrote:
Hi, Naoto
I have a few comments:
src/java.base/share/classes/java/lang/StringUTF16.java
379 private static int getSupplementaryCodePoint(byte[] ba, int cp,
int index, int start, int end)
I think it would be worth a small addition to
Hi, Naoto
I have a few comments:
src/java.base/share/classes/java/lang/StringUTF16.java
379 private static int getSupplementaryCodePoint(byte[] ba, int cp,
int index, int start, int end)
I think it would be worth a small addition to the comment to reflect
that non-surrogate chars are
Thank you, Joe. I got it now. Will try out and benchmark.
Naoto
On 7/21/20 10:05 AM, Joe Wang wrote:
On 7/20/2020 8:58 PM, naoto.s...@oracle.com wrote:
The short-cut worked well. There's maybe a further optimization we
could do to rid us of the performance concern (or the need to run
Thank you, Roger.
On 7/21/20 7:50 AM, Roger Riggs wrote:
Hi Naoto,
StringUTF16.java:
343, 348: The masking and comparisons seem awkward.
I'd suggest just negating the value and testing for < 0 to flag the less
usual case.
If you continue with the flag bit, define your own static final
Hi Aleksei,
Looks good!
- Alexey
On 7/21/2020 11:42 AM, Aleksei Voitylov wrote:
Hi,
This is the updated fix which checks if LD_LIBRARY_PATH has been changed
during jpackage executions:
http://cr.openjdk.java.net/~avoitylov/webrev.8248239.03/
The fix stores hash from LD_LIBRARY_PATH in
Hello,
Wouldn't that be too dangerous, in the sense that it makes us lose control
over how the String are actually constructed and aggregated together?
Aside from that, what kind of interpolation are you looking for, and how
the String.format utility does not meet your needs?
Regards,
D.J.
Hi,
gently reminiding about this simple test refactoring. The patch still
applies cleanly.
-Aleksei
On 24/06/2020 11:44, Aleksei Voitylov wrote:
> Hi,
>
> I'd like to refactor test/jdk/tools/launcher/Test7029048.java, make the
> logic easier to follow and remove some magic numbers from the
If you need something right now, you can try
https://commons.apache.org/proper/commons-text/javadocs/api-release/org/apache/commons/text/StringSubstitutor.html.
On 21/07/2020 09:29, Jessica wrote:
Hi,
I would like to strongly request Java have the ability to do string
interpolation.
It is
Hi Roger,
I will plan to push tomorrow morning pending any last minute reviews
Best
Lance
> On Jul 21, 2020, at 9:57 AM, Roger Riggs wrote:
>
> Hi Rafaello, Lance,
>
> That looks good to me.
>
> Thanks, Roger
>
> On 7/19/20 2:31 PM, Lance Andersen wrote:
>> Hi Raffaello,
>>
>> I think
Hi Andrew and all,
Since we are getting ready to propose Vector API target to JDK 16 [1]. I
have regenerated webrev of aarch64 backend parts from panama repo, which
has been rebased to jdk/jdk very recently, by:
$ hg update vector-unstable && hg diff -r default > all.patch
$ grep "diff -r"
One option is to have a fast path that uses char functions, up to the point
where you hit a high surrogate, then drop into the slower codepoint path.
That saves time for the high-runner cases.
On the other hand, if the times are good enough, you might not need the
complication.
Mark
On Fri,
Hi,
I would like to strongly request Java have the ability to do string
interpolation.
It is such a great convenience and allows for faster, more efficient coding
that is easier to read.
Is this feature on the roadmap in the foreseeable future?
Thank you!
Jessica Risavi
On 7/20/2020 8:58 PM, naoto.s...@oracle.com wrote:
The short-cut worked well. There's maybe a further optimization we
could do to rid us of the performance concern (or the need to run
additional performance tests). Consider the cases where strings in
comparison don't contain any sup
On 7/17/20 6:48 AM, Yasumasa Suenaga wrote:
Hi Koichi,
On 2020/07/17 20:26, Koichi Sakata wrote:
Hi Daniel,
> The changes to NetworkInterface.c look good to me.
Thank you.
> You'll need to find a reviewer that understands what that
> method is supposed to do in that case, that's not
Hi,
This is the updated fix which checks if LD_LIBRARY_PATH has been changed
during jpackage executions:
http://cr.openjdk.java.net/~avoitylov/webrev.8248239.03/
The fix stores hash from LD_LIBRARY_PATH in _JPACKAGE_LAUNCHER env
variable. Until C++14 becomes mandatory for OpenJDK, a custom hash
Hi Naoto,
StringUTF16.java:
343, 348: The masking and comparisons seem awkward.
I'd suggest just negating the value and testing for < 0 to flag the less
usual case.
If you continue with the flag bit, define your own static final constant
for that bit;
It looks odd to be using
Hi Rafaello, Lance,
That looks good to me.
Thanks, Roger
On 7/19/20 2:31 PM, Lance Andersen wrote:
Hi Raffaello,
I think the changes look reasonable.
I have created a webrev,
http://cr.openjdk.java.net/~lancea/8222187/webrev.00/, for others to
review as it is a bit easier than the patch.
18 matches
Mail list logo
