Hello!
It's quite possible that when we concatenate two strings, one of them
appears to be empty. We cannot simply return another string in this
case, as JLS 15.18.1 explicitly says (for unknown to me reason) about
the result of the string concatenation expression that 'The String
object is newly
testing revealed that LingeredAppTest.java required some love, incremental
webrev w/ the fixes for LingeredAppTest --
http://cr.openjdk.java.net/~iignatyev//8211977/webrev.0-1
-- Igor
> On Jun 12, 2020, at 8:38 PM, Igor Ignatyev wrote:
>
> adding build-dev
>
>> On Jun 12, 2020, at 8:36 PM, I
adding build-dev
> On Jun 12, 2020, at 8:36 PM, Igor Ignatyev wrote:
>
> http://cr.openjdk.java.net/~iignatyev//8211977/webrev.00/
>> 796 lines changed: 200 ins; 588 del; 8 mod;
>
> Hi all,
>
> could you please review this small patch which puts all tests for testlibrary
> classes into one lo
http://cr.openjdk.java.net/~iignatyev//8211977/webrev.00/
> 796 lines changed: 200 ins; 588 del; 8 mod;
Hi all,
could you please review this small patch which puts all tests for testlibrary
classes into one location under /test/lib-test?
besides moving tests from test/jdk/lib/testlibrary and
t
Hi Martin,
I see your point. Thank you for demostrating this for me.
Here's my updated patch:
# HG changeset patch
# User John Lin
# Date 1591923561 -28800
# Fri Jun 12 08:59:21 2020 +0800
# Node ID e01d9d020506a88d3d585bd3264594a26450c659
# Parent 49a68abdb0ba68351db0f140ddac793b1c391bd5
Roger,
I did think about confining the changes to ObjectInputStream. Maybe I
did not think hard enough about it.
Keeping a cache of the result of a first stack walk might work for the
recursive calls. One might still do a useless stack walk for each
top-level readObject call. No concurrent cla
Daniel,
Thanks for the suggestions to increase the timeout and lower the
concurrency. I did Bad Science(TM) and changed them both at the same
time. I am now running
$ jtreg-5.0-b01/bin/jtreg \
-verbose:summary -a -ea -esa -agentvm -conc:1 -ignore:quiet -timeout:4 \
-exclude:./test/j
Look good to me.
Bob.
> On Jun 12, 2020, at 11:01 AM, Baesken, Matthias
> wrote:
>
> Hello, please review the following change .
> We have a Linux machine where
> OperatingSystemMXBean mbean =
> (com.sun.management.OperatingSystemMXBean)
> ManagementFactory.getOperatingSystem
Hi Matthias,
The change looks good to me. Probably it also makes sense to remove method
getHostConfiguredCpuCount0() since it is no longer used.
Thanks,
Daniil
On 6/12/20, 8:25 AM, "Baesken, Matthias" wrote:
Hello, please review the following change .
We have a Linux machine
+1. The original poster was probably working on writing history (all
the way back to before 1000), I assume ;-) This enhancement would
certainly make his job a bit easier.
-Joe
On 6/12/2020 11:17 AM, Roger Riggs wrote:
Hi Naoto,
Yes, looks good.
Roger
On 6/12/20 1:06 PM, Lance Andersen
Hi Peter,
The hazard to avoid is the cross package coupling that makes both
ClassLoader and
ObjectInputStream more complex; both are more than sufficiently complex
already.
Optimizing the implementations make sense if it benefits enough uses
cases and
does not make the code harder to mainta
Hi Naoto,
Yes, looks good.
Roger
On 6/12/20 1:06 PM, Lance Andersen wrote:
Hi Naoto,
This looks fine and looks like you are set with reviewers on your CSR
Best
Lance
On Jun 12, 2020, at 12:31 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://
Hello!
A gentle ping: please review
https://bugs.openjdk.java.net/browse/JDK-8244288
http://cr.openjdk.java.net/~tvaleev/webrev/8244288/r1/
The details are listed below.
With best regards,
Tagir Valeev.
-- Forwarded message -
From: Tagir Valeev
Date: Sun, May 3, 2020 at 4:36 PM
If I rub that program, I get:
HashMap false
HashMap1 false
HashMap2 true
which suggests that HashMap2's implementation is wrong.
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8245448
The proposed changeset and its CSR are located at:
https://cr.openjdk.java.net/~naoto/8245448/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8246623
Naoto
Hi Naoto,
This looks fine and looks like you are set with reviewers on your CSR
Best
Lance
> On Jun 12, 2020, at 12:31 PM, naoto.s...@oracle.com wrote:
>
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8245448
>
> The proposed changeset
Hello, please review the following change .
We have a Linux machine where
OperatingSystemMXBean mbean =
(com.sun.management.OperatingSystemMXBean)
ManagementFactory.getOperatingSystemMXBean();
double load = mbean.getSystemCpuLoad();
returns -1 ;
Reason is that th
+1
> On Jun 12, 2020, at 1:00 PM, Daniel D. Daugherty
> wrote:
>
> Greetings,
>
> It's time to reduce the noise in the CI so I'm ProblemListing tests.
>
> Here's the bug for failure:
>
> JDK-8247407 tools/jlink/plugins/CompressorPluginTest.java test failing
> https://bugs.openjdk.jav
Thanks for the fast review!
Dan
On 6/12/20 12:02 PM, Jim Laskey wrote:
+1
On Jun 12, 2020, at 1:00 PM, Daniel D. Daugherty
wrote:
Greetings,
It's time to reduce the noise in the CI so I'm ProblemListing tests.
Here's the bug for failure:
JDK-8247407 tools/jlink/plugins/CompressorP
Hi Sean,
I think your changes look fine so all good FMPOV.
Best
Lance
> On Jun 12, 2020, at 6:21 AM, Seán Coffey wrote:
>
> Hi,
>
> I'd like to reboot this jarsigner enhancement request[1]. I've removed the
> problem references to zip file name extensions. Instead, there's a new JDK
> imple
Greetings,
It's time to reduce the noise in the CI so I'm ProblemListing tests.
Here's the bug for failure:
JDK-8247407 tools/jlink/plugins/CompressorPluginTest.java test failing
https://bugs.openjdk.java.net/browse/JDK-8247407
and here's the bug for the ProblemListing:
JDK-824749
Hi,
I'd like to reboot this jarsigner enhancement request[1]. I've removed
the problem references to zip file name extensions. Instead, there's a
new JDK implementation specific jarsigner option: -keepposixperms
https://bugs.openjdk.java.net/browse/JDK-8218021
https://cr.openjdk.java.net/~cof
Hi Alexey,
This is starting to look good.
Thank you for persisting!
I have a couple of comments - on the LDAP/JNDI side.
There are several places where your new code is supposed to
trigger the throwing of a NamingException:
LdapSasl.java: lines 76, 85, 140, 168
Please write a test to verify
Hi Martin,
May I ask what do you mean by pasting this pice of code? Sorry I didn't get it.
Best,
John Lin
Martin Buchholz 於 2020年6月12日 週五 下午2:42寫道：
>
> import java.util.HashMap;
> import java.util.Map;
> import java.util.function.BiFunction;
>
> @SuppressWarnings("serial")
> public class MapsCo
import java.util.HashMap;
import java.util.Map;
import java.util.function.BiFunction;
@SuppressWarnings("serial")
public class MapsComputeNull {
static class HashMap1 extends HashMap {
@Override public V compute(
K key,
BiFunction
remappingFunction) {
25 matches
Mail list logo
