Re: RFR (backport CSR): 8239395: Accounting currency format support
In that case, I'll withdraw it, unless a maintenance review comes along. Thanks, Paul On 2/19/20, 9:01 AM, "Joe Darcy" wrote: As a practical matter, no. Since a Java SE specification is modified by this changeset, a maintenance review (MR) would be needed for Java SE 11 for this change to go into 11u. HTH, -Joe On 2/19/2020 8:09 AM, Hohensee, Paul wrote: > So, not backportable? > > Paul > > On 2/19/20, 5:23 AM, "naoto.s...@oracle.com" wrote: > > Hi Joe, Paul, > > Yes, I was thinking the same. It is a spec change in 14. > > Naoto > > On 2/18/20 9:45 PM, Joe Darcy wrote: > > Hi Paul, > > > > This looks like a spec change to a Java SE API so would be out of bounds > > for 11u without a maintenance update of Java SE 11. > > > > Naoto, do you agree with that analysis? > > > > Thanks, > > > > -Joe > > > > On 2/18/2020 5:44 PM, Hohensee, Paul wrote: > >> Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 > >> for a backport of JDK-8215181 to jdk11u. It’s identical to the > >> original CSR. > >> > >> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181 > >> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770 > >> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239394 > >> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395 > >> > >> Thanks, > >> Paul > >> > >
Re: RFR (backport CSR): 8239395: Accounting currency format support
On 19/02/2020 05:45, Joe Darcy wrote: > Hi Paul, > > This looks like a spec change to a Java SE API so would be out of bounds > for 11u without a maintenance update of Java SE 11. > > Naoto, do you agree with that analysis? > > Thanks, > > -Joe > > On 2/18/2020 5:44 PM, Hohensee, Paul wrote: >> Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 >> for a backport of JDK-8215181 to jdk11u. It’s identical to the >> original CSR. >> >> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181 >> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770 >> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239394 >> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395 >> >> Thanks, >> Paul >> > > This seems like it should be sent to jdk-updates-dev, not jdk8u-dev. I tend to agree with Joe Darcy that this would introduce new requirements on those implementing NumberFormat.getCurrencyFormat and is thus a spec change which alters the API requirements of Java 11. I presume current OpenJDK 11 would fail the tests in test/jdk/java/util/Locale/bcp47u/CurrencyFormatTests.java? -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
Re: RFR (backport CSR): 8239395: Accounting currency format support
As a practical matter, no. Since a Java SE specification is modified by this changeset, a maintenance review (MR) would be needed for Java SE 11 for this change to go into 11u. HTH, -Joe On 2/19/2020 8:09 AM, Hohensee, Paul wrote: So, not backportable? Paul On 2/19/20, 5:23 AM, "naoto.s...@oracle.com" wrote: Hi Joe, Paul, Yes, I was thinking the same. It is a spec change in 14. Naoto On 2/18/20 9:45 PM, Joe Darcy wrote: > Hi Paul, > > This looks like a spec change to a Java SE API so would be out of bounds > for 11u without a maintenance update of Java SE 11. > > Naoto, do you agree with that analysis? > > Thanks, > > -Joe > > On 2/18/2020 5:44 PM, Hohensee, Paul wrote: >> Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 >> for a backport of JDK-8215181 to jdk11u. It’s identical to the >> original CSR. >> >> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181 >> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770 >> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239394 >> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395 >> >> Thanks, >> Paul >>
Re: RFR (backport CSR): 8239395: Accounting currency format support
So, not backportable? Paul On 2/19/20, 5:23 AM, "naoto.s...@oracle.com" wrote: Hi Joe, Paul, Yes, I was thinking the same. It is a spec change in 14. Naoto On 2/18/20 9:45 PM, Joe Darcy wrote: > Hi Paul, > > This looks like a spec change to a Java SE API so would be out of bounds > for 11u without a maintenance update of Java SE 11. > > Naoto, do you agree with that analysis? > > Thanks, > > -Joe > > On 2/18/2020 5:44 PM, Hohensee, Paul wrote: >> Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 >> for a backport of JDK-8215181 to jdk11u. It’s identical to the >> original CSR. >> >> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181 >> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770 >> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239394 >> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395 >> >> Thanks, >> Paul >>
Re: 8238953: tools/jpackage tests do not work on Ubuntu Linux
Matthias,
There is
jdk.incubator.jpackage.internal.LinuxRpmBundler.TOOL_RPMBUILD_MIN_VERSION
constant that is currently set to "4.0". Feel free to file a CR and bump
it up to "4.10"
- Alexey
On 2/19/2020 3:05 AM, Baesken, Matthias wrote:
Thank's for the reviews.
Do you have a good central place in the existing coding to add a similar
rpmbuild version check (e.g. for 4.10 or 4.11 which seem to be reasonable ) ?
Best regards, Matthias
+1
- Alexey
On 2/18/2020 10:56 AM, Langer, Christoph wrote:
Hi Matthias,
Looks good to me now.
Cheers
Christoph
-Original Message-
From: Baesken, Matthias
Sent: Dienstag, 18. Februar 2020 16:55
To: Langer, Christoph ; core-libs-
d...@openjdk.java.net; Alexey Semenyuk
Subject: RE: 8238953: tools/jpackage tests do not work on Ubuntu Linux
Ok why not, new webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8238953.2/
Thanks, Matthias
Hi Matthias,
you could improve the patch a bit by starting TKit:: isUbuntu() with
if (!isLinux()) {
return false;
}
And then, in PackageType, you could simply do:
private final static Set DISABLED_PACKAGERS =
Optional.ofNullable(
TKit.tokenizeConfigProperty("disabledPackagers")).orElse(
TKit.isUbuntu() ? Set.of("rpm") : Collections.emptySet());
Best regards
Christoph
-Original Message-
From: core-libs-dev On
Behalf
Of Baesken, Matthias
Sent: Dienstag, 18. Februar 2020 09:14
To: core-libs-dev@openjdk.java.net; Alexey Semenyuk
Subject: [CAUTION] RE: 8238953: tools/jpackage tests do not work on
Ubuntu Linux
Ping ... are you fine with the latest version ?
Best Regards, Matthias
Hi Alexey , I like your idea to do the handling in
test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageType.java
.
New webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8238953.1/
Best regards, Matthias
Re: RFR (backport CSR): 8239395: Accounting currency format support
Hi Joe, Paul, Yes, I was thinking the same. It is a spec change in 14. Naoto On 2/18/20 9:45 PM, Joe Darcy wrote: Hi Paul, This looks like a spec change to a Java SE API so would be out of bounds for 11u without a maintenance update of Java SE 11. Naoto, do you agree with that analysis? Thanks, -Joe On 2/18/2020 5:44 PM, Hohensee, Paul wrote: Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 for a backport of JDK-8215181 to jdk11u. It’s identical to the original CSR. Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770 Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239394 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395 Thanks, Paul
Re: RFR: 8239351: Give more meaningful InternalError messages in Deflater.c
+1 Gruß, Thomas On Wed, Feb 19, 2020, 10:35 Baesken, Matthias wrote: > Hello Thomas / Lance / Martin, thanks for the reviews . > > I added a little helper function, new webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8239351.1/ > > > > Best regards, Matthias > > > > > > > > I like this too. +1 for factoring out throwing the error. > > > > ..Thomas > > > > On Tue, Feb 18, 2020 at 6:51 PM Martin Buchholz > wrote: > > Thanks for doing this. Looks good to me. > I would probably create a tiny helper function to encapsulate the error > throw. > > On Tue, Feb 18, 2020 at 7:03 AM Baesken, Matthias < > matthias.baes...@sap.com> > wrote: > > > Hello, please review this change to Deflater.c . > > > > When running the jtreg test java/util/zip/DeInflate.java , we currently > > have errors on SLES 15.1 s390x when using the system zlib (1.2.11), while > > the bundled zlib (of OpenJDK) seems to be okay. > > What's worse, the error messages are not very meaningful / helpful . > > > > We just get > > java.lang.InternalError > > at java.base/java.util.zip.Deflater.deflateBytesBytes(Native Method) > > at java.base/java.util.zip.Deflater.deflate(Deflater.java:595) > > at java.base/java.util.zip.Deflater.deflate(Deflater.java:474) > > ... > > without more any meaningful error text. > > > > I would suggest to improve a bit the error messages in Deflater.c ; this > > would lead in this case to : > > > > java.lang.InternalError: unknown error in checkDeflateStatus, setParams > > case > > at > > java.base/java.util.zip.Deflater.deflateBytesBytes(Native Method) > > at > > java.base/java.util.zip.Deflater.deflate(Deflater.java:586) > > at > > java.base/java.util.zip.Deflater.deflate(Deflater.java:465) > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8239351 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8239351.0/ > > > > > > Thanks, Matthias > > > >
RE: RFR: 8239351: Give more meaningful InternalError messages in Deflater.c
Hello Thomas / Lance / Martin, thanks for the reviews . I added a little helper function, new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8239351.1/ Best regards, Matthias I like this too. +1 for factoring out throwing the error. ..Thomas On Tue, Feb 18, 2020 at 6:51 PM Martin Buchholz mailto:marti...@google.com>> wrote: Thanks for doing this. Looks good to me. I would probably create a tiny helper function to encapsulate the error throw. On Tue, Feb 18, 2020 at 7:03 AM Baesken, Matthias mailto:matthias.baes...@sap.com>> wrote: > Hello, please review this change to Deflater.c . > > When running the jtreg test java/util/zip/DeInflate.java , we currently > have errors on SLES 15.1 s390x when using the system zlib (1.2.11), while > the bundled zlib (of OpenJDK) seems to be okay. > What's worse, the error messages are not very meaningful / helpful . > > We just get > java.lang.InternalError > at java.base/java.util.zip.Deflater.deflateBytesBytes(Native Method) > at java.base/java.util.zip.Deflater.deflate(Deflater.java:595) > at java.base/java.util.zip.Deflater.deflate(Deflater.java:474) > ... > without more any meaningful error text. > > I would suggest to improve a bit the error messages in Deflater.c ; this > would lead in this case to : > > java.lang.InternalError: unknown error in checkDeflateStatus, setParams > case > at > java.base/java.util.zip.Deflater.deflateBytesBytes(Native Method) > at > java.base/java.util.zip.Deflater.deflate(Deflater.java:586) > at > java.base/java.util.zip.Deflater.deflate(Deflater.java:465) > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8239351 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8239351.0/ > > > Thanks, Matthias >
RE: 8238953: tools/jpackage tests do not work on Ubuntu Linux
Thank's for the reviews.
Do you have a good central place in the existing coding to add a similar
rpmbuild version check (e.g. for 4.10 or 4.11 which seem to be reasonable ) ?
Best regards, Matthias
> +1
>
> - Alexey
>
> On 2/18/2020 10:56 AM, Langer, Christoph wrote:
> > Hi Matthias,
> >
> > Looks good to me now.
> >
> > Cheers
> > Christoph
> >
> >> -Original Message-
> >> From: Baesken, Matthias
> >> Sent: Dienstag, 18. Februar 2020 16:55
> >> To: Langer, Christoph ; core-libs-
> >> d...@openjdk.java.net; Alexey Semenyuk
>
> >> Subject: RE: 8238953: tools/jpackage tests do not work on Ubuntu Linux
> >>
> >> Ok why not, new webrev :
> >>
> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8238953.2/
> >>
> >> Thanks, Matthias
> >>
> >>
> >>
> >>> Hi Matthias,
> >>>
> >>> you could improve the patch a bit by starting TKit:: isUbuntu() with
> >>>
> >>> if (!isLinux()) {
> >>> return false;
> >>> }
> >>>
> >>> And then, in PackageType, you could simply do:
> >>>
> >>> private final static Set DISABLED_PACKAGERS =
> >> Optional.ofNullable(
> >>> TKit.tokenizeConfigProperty("disabledPackagers")).orElse(
> >>> TKit.isUbuntu() ? Set.of("rpm") :
> >>> Collections.emptySet());
> >>>
> >>> Best regards
> >>> Christoph
> >>>
> -Original Message-
> From: core-libs-dev On
> >> Behalf
> Of Baesken, Matthias
> Sent: Dienstag, 18. Februar 2020 09:14
> To: core-libs-dev@openjdk.java.net; Alexey Semenyuk
>
> Subject: [CAUTION] RE: 8238953: tools/jpackage tests do not work on
> Ubuntu Linux
>
> Ping ... are you fine with the latest version ?
>
> Best Regards, Matthias
>
> > Hi Alexey , I like your idea to do the handling in
> > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageType.java
> .
> >
> > New webrev :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8238953.1/
> >
> >
> >
> > Best regards, Matthias
> >
> >
