Re: RFR: 8264109: Add vectorized implementation for VectorMask.andNot() [v2]

On Wed, 31 Mar 2021 16:42:09 GMT, Paul Sandoz wrote: > Would you mind updating the existing `AbstractMask.andNot` implementation? > rather than changing `VectorMask.andNot`. That fits in with the current > implementation pattern. Hi @PaulSandoz , thanks for looking at this PR. I'v updated the

Re: RFR: 8264109: Add vectorized implementation for VectorMask.andNot() [v2]

> Currently "VectorMask.andNot()" is not vectorized: > public VectorMask andNot(VectorMask m) { > // FIXME: Generate good code here. > return bOp(m, (i, a, b) -> a && !b); > } > This can be implemented with` "and(m.not())" `directly. Since > `"VectorMask.and()/not()" `have

Re: RFR: 8037397: Lost nested character class after intersection &

On Wed, 31 Mar 2021 20:38:33 GMT, Ian Graves wrote: > Bug fix with the intersection `&&` operator in regex patterns. In > JDK-8037397, some character classes on the right hand side of the operator > are dropped in cases where nested `[..]` classes are used with non "nested" > ones.

Re: Proposal for Decimal64 and Decimal128 value-based classes

> On Mar 31, 2021, at 3:27 PM, Maurizio Cimadamore > wrote: > > What I'd be curious though, is if the @ValueBased annotation could be > enhanced to say _which_ primitive class default you want (and then javac > could enforce extra checks if you pick the "val" default). If something like >

Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes

The IEEE decimal floating-point is usable for currency calculations, but it is not intended to be limited to such calculations. A type targeted at currency calculations would focus more on fixed-point rounding, rounding to a given digit position (scale in BigDecimal terminology), as opposed to

Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes

The issue is to simulate SQL DECIMAL arithmetic using IEEE Decimal Consider the division 20 / 3. Using Decimal64: 20 / 3 -> 6.7 Using DECIMAL(38, 6), or many other reasonable combinations: 20 / 3 -> 6.67 We could expose a richer API in Decimal,

Re: RFR: JDK-8264403: [macos]: App names containing '.' characters results in an error message when launching

On Wed, 31 Mar 2021 19:30:10 GMT, Andy Herrick wrote: > Deriving the cfg file name is broken on mac and linux when the application > name has a "." in it. Changes requested by asemenyuk (Reviewer). src/jdk.jpackage/share/native/common/FileUtils.h line 76: > 74: > 75: // extract the name

RFR: 8264514: HexFormat implementation tweaks

Please review these small tweaks. For background information see [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075822.html) Greetings Raffaello - Commit messages: - 8264514: HexFormat implementation tweaks Changes:

RFR: 8169629: Annotations with lambda expressions cause AnnotationFormatErrorr

The stricter checks added by 8035781: Improve equality for annotations in creating the proxy objects used to implement annotations has an unintended by-catch of rejecting annotation's whose type has, say, a field initialized with a lambda expression. While uncommon, it is legal code to have

Re: Proposal for Decimal64 and Decimal128 value-based classes

On 31/03/2021 21:43, Raffaello Giulietti wrote: Ciao Maurizio, admittedly, yours is a fairly convincing argument to wait for the completion of Valhalla, or at least JEP 401. Personally, I wouldn't mind having to denote the primitive class as Decimal128.val in some future (2022? 2023? who

Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes

My understanding is that IEEE decimal floating point is intended for currency. A large fraction of numeric values stored in databases are currency. It's not obvious to me why an e-commerce web site would not want to use Decimal128 to represent prices, extensions, taxes, discounts, totals, etc.

Re: Proposed: StringUTF16 bug fix with optimization - Part 1 of 2, StringUTF16 Patch

Hi Chris, Thank you for your contribution. I believe this can be divided into two parts, one is the bug in the current implementation, and the other is the enhancement to refactor the whole implementation for performance. I have created two JIRA issues for each:

Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes

Hi Douglas, yes, different vendors have different limits on the precision, the most extreme probably being PostgreSQL. But apart from that, the arithmetic is different. A better option is to implement some optimized fixed precision classes like SQLDecimal38 and SQLDecimal65 + a more general

Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes

Understood. The problem is that right now the only appropriate type for non-integer SQL numbers is BigDecimal. It's too big and too slow and lots of users avoid it. Decimal128 supports 34 significant digits. The max precision of SQL numeric types varies from vendor to vendor. In SQL Server it

RFR: 8037397: Lost nested character class after intersection &

Bug fix with the intersection `&&` operator in regex patterns. In JDK-8037397, some character classes on the right hand side of the operator are dropped in cases where nested `[..]` classes are used with non "nested" ones. - Commit messages: - Fixing a regex intersection bug that

Re: Proposal for Decimal64 and Decimal128 value-based classes

Ciao Maurizio, admittedly, yours is a fairly convincing argument to wait for the completion of Valhalla, or at least JEP 401. Personally, I wouldn't mind having to denote the primitive class as Decimal128.val in some future (2022? 2023? who knows?) if I could use Decimal128 tomorrow, but I

RFR: JDK-8264403: [macos]: App names containing '.' characters results in an error message when launching

Deriving the cfg file name is broken on mac and linux when the application name has a "." in it. - Commit messages: - Merge branch 'master' into JDK-8264403 - JDK-8264403: [macos]: App names containing '.' characters results in an error message when launching - 8264466:

Re: Proposal for Decimal64 and Decimal128 value-based classes

Hi, I think there's a misunderstanding about the nature of IEEE 754 Decimal (e.g., Decimal64), the subject of this thread, and the nature of SQL DECIMAL(p, s). SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an overall maximum precision p and a scale s, the number of digits

Re: RFR: 8264048: Fix caching in Jar URL connections when an entry is missing [v2]

On Wed, 31 Mar 2021 12:47:50 GMT, Aleksei Efimov wrote: >> Current fix tries to tackle an issue with URL connection referencing >> non-existing Jar file entries: >> If an entry that doesn't exist is specified in an URL connection the >> underlying Jar file is still cached even if an exception

Re: RFR: 8173970: jar tool should have a way to extract to a directory [v3]

On Mon, 29 Mar 2021 14:04:10 GMT, Jaikiran Pai wrote: >> Can I please get a review for this patch which proposes to implement the >> enhancement request noted in >> https://bugs.openjdk.java.net/browse/JDK-8173970? >> >> The commit in this PR introduces the `-o` and `--output-dir` option to

Re: Insufficiencies in JEP: 400: UTF-8 by Default

Hi Anthony, A draft of updates to the Process API is in the works and covers improving the ease of use and providing Readers and Writers.  Note that if process output is redirected to a file, it does not interpose on the byte streams and is not in a position to affect the character set used

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]

On Wed, 31 Mar 2021 15:42:14 GMT, Brian Burkhalter wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Review Alan > > Marked as reviewed by bpb (Reviewer). Thanks for reviewing! - PR:

Integrated: 8264489: Add more logging to LargeCopyWithMark.java

On Wed, 31 Mar 2021 06:56:23 GMT, Stefan Karlsson wrote: > Add more logging to the LargeCopyWithMark.java test, to gather more > information when this test fails with OOME. > > The intention is to gather more info for JDK-8239089. > > I consider this patch trivial, and expect to push it

Re: Proposal for Decimal64 and Decimal128 value-based classes

I'm sure this would be a huge disruption, but I'll throw it out anyway. I'd be perfectly happy if assigning null to a Decimal64/128 container was not allowed, whether it is a reference or a value. I haven't followed the progress of Valhalla closely. It would be reasonable to delay

Re: RFR: 8264109: Add vectorized implementation for VectorMask.andNot()

On Fri, 26 Mar 2021 01:50:33 GMT, Xiaohong Gong wrote: > Currently "VectorMask.andNot()" is not vectorized: > public VectorMask andNot(VectorMask m) { > // FIXME: Generate good code here. > return bOp(m, (i, a, b) -> a && !b); > } > This can be implemented with`

Re: RFR: 8173970: jar tool should have a way to extract to a directory [v3]

On Mon, 29 Mar 2021 14:04:10 GMT, Jaikiran Pai wrote: >> Can I please get a review for this patch which proposes to implement the >> enhancement request noted in >> https://bugs.openjdk.java.net/browse/JDK-8173970? >> >> The commit in this PR introduces the `-o` and `--output-dir` option to

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]

On Wed, 31 Mar 2021 11:15:43 GMT, Stefan Karlsson wrote: >> Add more logging to the LargeCopyWithMark.java test, to gather more >> information when this test fails with OOME. >> >> The intention is to gather more info for JDK-8239089. >> >> I consider this patch trivial, and expect to push

Re: Proposal for Decimal64 and Decimal128 value-based classes

On 31/03/2021 15:23, Douglas Surber wrote: Rather than waiting on Valhala I would prefer that this project be fast tracked and added to OpenJDK ASAP. There is a catch here. While in principle, we can add these as value-based classes, and migrate to Valhalla later, there is a biggie

Re: Proposal for Decimal64 and Decimal128 value-based classes

Agree this could be beneficial to JDBC users. To officially support this in JDBC would require an MR but as Douglas indicates the work required to the JDBC spec would be minimal Best Lance On Mar 31, 2021, at 10:23 AM, Douglas Surber mailto:douglas.sur...@oracle.com>> wrote: +1 JDBC would

Re: Proposal for Decimal64 and Decimal128 value-based classes

+1 JDBC would support this immediately. All it would take is the addition of a couple of lines in some appendices to require that conforming implementations of getObject(int, Class), setObject(int, Object, SQLType), etc support Decimal64 and Decimal128. No change to the API required. Driver

Re: Further review of java.util.HexFormat

Hi Raffaello, None of these are substantive but useful none the less. I would have rather seen them during the review and not be revisiting them. Issue created: 8264514 HexFormat implementation tweaks On 3/30/21 8:19 PM, Raffaello Giulietti

Re: RFR: 8173970: jar tool should have a way to extract to a directory

On Sat, 27 Mar 2021 16:02:55 GMT, Alan Bateman wrote: >> Can I please get a review for this patch which proposes to implement the >> enhancement request noted in >> https://bugs.openjdk.java.net/browse/JDK-8173970? >> >> The commit in this PR introduces the `-o` and `--output-dir` option to

Re: RFR: 8264048: Fix caching in Jar URL connections when an entry is missing [v2]

> Current fix tries to tackle an issue with URL connection referencing > non-existing Jar file entries: > If an entry that doesn't exist is specified in an URL connection the > underlying Jar file is still cached even if an exception is thrown after > that. Such behavior prevents the caller,

Re: RFR: 8264048: Fix caching in Jar URL connections when an entry is missing

On Wed, 31 Mar 2021 11:24:02 GMT, Daniel Fuchs wrote: >> Current fix tries to tackle an issue with URL connection referencing >> non-existing Jar file entries: >> If an entry that doesn't exist is specified in an URL connection the >> underlying Jar file is still cached even if an exception is

Re: RFR: 8264048: Fix caching in Jar URL connections when an entry is missing

On Tue, 30 Mar 2021 11:30:48 GMT, Aleksei Efimov wrote: > Current fix tries to tackle an issue with URL connection referencing > non-existing Jar file entries: > If an entry that doesn't exist is specified in an URL connection the > underlying Jar file is still cached even if an exception is

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]

On Wed, 31 Mar 2021 11:15:43 GMT, Stefan Karlsson wrote: >> Add more logging to the LargeCopyWithMark.java test, to gather more >> information when this test fails with OOME. >> >> The intention is to gather more info for JDK-8239089. >> >> I consider this patch trivial, and expect to push

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]

On Wed, 31 Mar 2021 09:29:43 GMT, Alan Bateman wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Review Alan > > test/jdk/java/io/BufferedInputStream/LargeCopyWithMark.java line 29: > >> 27: * @summary

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]

> Add more logging to the LargeCopyWithMark.java test, to gather more > information when this test fails with OOME. > > The intention is to gather more info for JDK-8239089. > > I consider this patch trivial, and expect to push it after I've gotten one > Review. Stefan Karlsson has updated

Withdrawn: 8264397: Use the blessed modifier order in jdk.incubator.foreign

On Mon, 29 Mar 2021 21:09:56 GMT, Alex Blewitt wrote: > 8264397: Use the blessed modifier order in jdk.incubator.foreign This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/3253

Re: RFR: 8264397: Use the blessed modifier order in jdk.incubator.foreign

On Tue, 30 Mar 2021 21:26:34 GMT, Alex Blewitt wrote: >> Hi @alblue, thanks for the contribution. We will make sure to integrate this >> at some point, but I don't think now is the right moment to do this kind of >> stylistic changes to the API/implementation. If you want to integrate the >>

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java

On Wed, 31 Mar 2021 06:56:23 GMT, Stefan Karlsson wrote: > Add more logging to the LargeCopyWithMark.java test, to gather more > information when this test fails with OOME. > > The intention is to gather more info for JDK-8239089. > > I consider this patch trivial, and expect to push it

Re: Proposal for Decimal64 and Decimal128 value-based classes

On Tue, 30 Mar 2021 at 22:02, Maurizio Cimadamore wrote: > There are also other interesting types to be explored in that domain, > such as Long128, LongDouble (extended precision float) and HalfFloats. Perhaps it would be beneficial to have a GitHub repo where designs for these could be fleshed

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java

On Wed, 31 Mar 2021 08:39:02 GMT, Kim Barrett wrote: >> Add more logging to the LargeCopyWithMark.java test, to gather more >> information when this test fails with OOME. >> >> The intention is to gather more info for JDK-8239089. >> >> I consider this patch trivial, and expect to push it

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java

On Wed, 31 Mar 2021 06:56:23 GMT, Stefan Karlsson wrote: > Add more logging to the LargeCopyWithMark.java test, to gather more > information when this test fails with OOME. > > The intention is to gather more info for JDK-8239089. > > I consider this patch trivial, and expect to push it

RFR: 8264489: Add more logging to LargeCopyWithMark.java

Add more logging to the LargeCopyWithMark.java test, to gather more information when this test fails with OOME. The intention is to gather more info for JDK-8239089. I consider this patch trivial, and expect to push it after I've gotten on Review. - Commit messages: - 8264489: