That's fine then.
Thank you for looking into this.
Thanks,
Amy
On 3/25/20 4:37 AM, naoto.s...@oracle.com wrote:
Hi Amy,
I ended up the fix pretty much as of ver 06, as those data file
formats are different. It'd require some amount of refactoring to
those other two tests, and
On 25/03/2020 3:49 am, Florian Weimer wrote:
* Magnus Ihse Bursie:
On 2020-03-24 09:59, Andrew Dinn wrote:
On 23/03/2020 18:38, Erik Joelsson wrote:
Looks good.
Thanks for the review, Erik.
I'm assuming that also implies it is trivial (because, copyright update
a side, it really is a
Hi Tagir,
Looks good to me.
I can't find anything actually wrong, so here are some nitpicks you can
ignore:
---
676 V newValue;
677 int mc = modCount;
678 newValue = mappingFunction.apply(key);
I would never use a C style declaration when an initializing declaration
* Thomas Stüfe:
> Hi Tagir,
>
> nice work. Only a partwise review for TreeMap.java, did not yet look at the
> tests.
>
> remapValue:
>
> 711 } else {
> 712 // replace old mapping
> 713 t.value = newValue;
> 714 return newValue;
> 715 }
>
>
Hi Amy,
I ended up the fix pretty much as of ver 06, as those data file formats
are different. It'd require some amount of refactoring to those other
two tests, and CoderTest.java is a dependence to ConverterTest.java, so
I left them as-is.
One minor change from 06 is to add @modules
* Magnus Ihse Bursie:
> On 2020-03-24 09:59, Andrew Dinn wrote:
>> On 23/03/2020 18:38, Erik Joelsson wrote:
>>> Looks good.
>> Thanks for the review, Erik.
>>
>> I'm assuming that also implies it is trivial (because, copyright update
>> a side, it really is a 1-liner :-).
>
> For code in the
> On Mar 24, 2020, at 10:40 AM, Aleksey Shipilev wrote:
>
> On 3/24/20 6:38 PM, Paul Sandoz wrote:
>> I’ll bite :-) +1
>
> Thanks. Would you also, per chance, consider it trivial?
Very much so.
It’s maybe something that could be gated by jcheck (or whatever the equivalent
is for Skara).
On 3/24/20 6:40 PM, Severin Gehwolf wrote:
> On Tue, 2020-03-24 at 12:03 +0100, Aleksey Shipilev wrote:
>> On 3/23/20 9:35 PM, Alan Bateman wrote:
>>> On 23/03/2020 19:22, Aleksey Shipilev wrote:
+import java.io.InputStream;
import java.io.IOException;
import
On 3/24/20 6:38 PM, Paul Sandoz wrote:
> I’ll bite :-) +1
Thanks. Would you also, per chance, consider it trivial?
--
-Aleksey
On Tue, 2020-03-24 at 12:03 +0100, Aleksey Shipilev wrote:
> On 3/23/20 9:35 PM, Alan Bateman wrote:
> > On 23/03/2020 19:22, Aleksey Shipilev wrote:
> > > +import java.io.InputStream;
> > > import java.io.IOException;
> > > import java.lang.ProcessBuilder.Redirect;
> > > @@ -314,5 +315,8 @@
>
I’ll bite :-) +1
Paul.
> On Mar 24, 2020, at 10:10 AM, Aleksey Shipilev wrote:
>
> On 3/23/20 3:02 PM, Aleksey Shipilev wrote:
>> This change in JDK-8240629 was not correct and slipped the review?
>> https://hg.openjdk.java.net/jdk/jdk/rev/79371dab85c2#l2.5
>>
>> Also, other file has not
Hi Tagir,
nice work. Only a partwise review for TreeMap.java, did not yet look at the
tests.
remapValue:
711 } else {
712 // replace old mapping
713 t.value = newValue;
714 return newValue;
715 }
Should we increase the modification count
On 3/23/20 3:02 PM, Aleksey Shipilev wrote:
> This change in JDK-8240629 was not correct and slipped the review?
> https://hg.openjdk.java.net/jdk/jdk/rev/79371dab85c2#l2.5
>
> Also, other file has not updated the copyright line.
>
> Fix:
>
> diff -r 35ff74547c64
On 3/24/20 9:24 AM, Ichiroh Takiguchi wrote:
Hello Naoto.
I tested webrev.06 code.
It's fine, thanks.
I'm interested in about @module for these testcases.
I think webrev.04 code worked via jtreg.
I could not see any warning.
At this case, @module is required ?
Yes. The tag lets jtreg not run
Thanks again. I will look into it and come up with better migration of
those tests.
Naoto
On 3/23/20 9:45 PM, Amy Lu wrote:
Thank you Naoto for the quick update.
Just more findings ...(sorry for not sending earlier)
CoderTest.java
Looks like this test has already been migrated (with
Hello Naoto.
I tested webrev.06 code.
It's fine, thanks.
I'm interested in about @module for these testcases.
I think webrev.04 code worked via jtreg.
I could not see any warning.
At this case, @module is required ?
Thanks,
Ichiroh Takiguchi
On 2020-03-24 10:06, naoto.s...@oracle.com wrote:
Hi, Naoto.
> https://cr.openjdk.java.net/~naoto/8241311/webrev.06/
Looks good!
Thanks,
Iris
Thanks for the explanation of the process.
Paul
On 3/23/20, 11:28 PM, "Langer, Christoph" wrote:
Hi Paul,
as Martin said, the original bug could not be opened by Oracle. I, however
changed the bug created by Martin to a Backport item. Doing it that way would
allow a
On 2020-03-23 23:15, naoto.s...@oracle.com wrote:
Hi Magnus,
I looked at i18n related changes:
make/CopyInterimTZDB.gmk
make/ToolsJdk.gmk
make/gendata/Gendata-java.base.gmk
make/gendata/GendataBreakIterator.gmk
make/gendata/GendataTZDB.gmk
make/gensrc/GensrcCharacterData.gmk
On 3/23/20 9:35 PM, Alan Bateman wrote:
> On 23/03/2020 19:22, Aleksey Shipilev wrote:
>> +import java.io.InputStream;
>> import java.io.IOException;
>> import java.lang.ProcessBuilder.Redirect;
>> @@ -314,5 +315,8 @@
>> String relativeDbgFileName = relativeFileName + "." +
> > By spec part you mean the "@throws SecurityException" sections? Do you
> think those should not have been part of the 11u/13u change? Should these
> be even rolled back?
> >
> The spec changes to NetPermission and the protected Socket constructor
> should not be in the update releases. If a
Thanks a lot for looking into this, Alan, Chris and Christoph!
We had also looked at
"8217997: Better socket support":
https://hg.openjdk.java.net/jdk/jdk/rev/94710bb2a5bb
which was backported as
"8218573: Better socket support":
On 24/03/2020 08:19, Langer, Christoph wrote:
Ah, I see... JDK-8218573 is JDK11u/JDK13u specific. Looks like it was derived
from JDK-8217997 in jdk/jdk but pushed as a different bug. jdk/jdk was the only
place where I was looking for JDK-8218573, so I couldn't find it.
I don't have time to
On 24/03/2020 09:10, Magnus Ihse Bursie wrote:
> On 2020-03-24 09:59, Andrew Dinn wrote:
>> I'm assuming that also implies it is trivial (because, copyright update
>> a side, it really is a 1-liner :-).
>
> For code in the build system, we do not have the Hotspot rules of
> multiple reviewers,
On 2020-03-24 09:59, Andrew Dinn wrote:
On 23/03/2020 18:38, Erik Joelsson wrote:
Looks good.
Thanks for the review, Erik.
I'm assuming that also implies it is trivial (because, copyright update
a side, it really is a 1-liner :-).
For code in the build system, we do not have the Hotspot
On 23/03/2020 18:38, Erik Joelsson wrote:
> Looks good.
Thanks for the review, Erik.
I'm assuming that also implies it is trivial (because, copyright update
a side, it really is a 1-liner :-).
I will push to the dev tree and request a backport to jdk14u.
regards,
Andrew Dinn
---
> >> One other thing on this. It looks like the spec changes that were part
> >> of JDK-8218573 have been backported to jdk-updates/jdk11u-dev by
> >> mistake. Is that part of the issue that you are trying to fix?
> > I can't find/access JDK-8218573 and I also struggle to find a changelist
> >
On 24/03/2020 07:33, Alan Bateman wrote:
The spec update for Java SE 13+ that was part of that change have
found their way into the jdk11u-dev repo,
Sorry, I mean Java SE 14. It seems the spec change was accidentally
pushed to 13.0.1 too.
-Alan
On 24/03/2020 06:42, Langer, Christoph wrote:
Hi Alan,
On 23/03/2020 18:07, Doerr, Martin wrote:
Hi,
I'd like to backport JDK-8223326 from jdk/jdk.
One other thing on this. It looks like the spec changes that were part
of JDK-8218573 have been backported to jdk-updates/jdk11u-dev by
Hi Alan,
> On 23/03/2020 18:07, Doerr, Martin wrote:
> > Hi,
> >
> > I'd like to backport JDK-8223326 from jdk/jdk.
> >
> One other thing on this. It looks like the spec changes that were part
> of JDK-8218573 have been backported to jdk-updates/jdk11u-dev by
> mistake. Is that part of the issue
Hi Alan,
> -Original Message-
> From: jdk-updates-dev On
> Behalf Of Alan Bateman
> Sent: Montag, 23. März 2020 20:19
> To: Doerr, Martin ; core-libs-
> d...@openjdk.java.net; jdk-updates-...@openjdk.java.net
> Subject: Re: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
>
Hi Paul,
as Martin said, the original bug could not be opened by Oracle. I, however
changed the bug created by Martin to a Backport item. Doing it that way would
allow a "standard" backport of such type of issues while the original item that
was pushed to head can remain invisible. We
32 matches
Mail list logo
