March 2021 - core-libs-dev

RFR: JDK-8064681 : Jaxp unit test need to be improved
by Mahendra Chhipa 30 Mar '21

30 Mar '21

https://bugs.openjdk.java.net/browse/JDK-8064681 ------------- Commit messages: - JDK-8064681 : Jaxp unit test need to be improved Changes: https://git.openjdk.java.net/jdk/pull/3115/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3115&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8064681 Stats: 541 lines in 6 files changed: 125 ins; 268 del; 148 mod Patch: https://git.openjdk.java.net/jdk/pull/3115.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3115/head:pull/3115 PR: https://git.openjdk.java.net/jdk/pull/3115

2 3

RFR: 8264277: java.xml.crypto module should be granted FilePermission and SocketPermission
by Weijun Wang 30 Mar '21

30 Mar '21

These permissions are needed so that the URIDereferencer is able to read data from a file system or a network. As the test shows, you still have to grant the same type of permission to your application. ------------- Depends on: https://git.openjdk.java.net/jdk/pull/3181 Commit messages: - 8264277: java.xml.crypto module should be granted FilePermission and SocketPermission Changes: https://git.openjdk.java.net/jdk/pull/3266/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3266&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264277 Stats: 139 lines in 2 files changed: 139 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3266/head:pull/3266 PR: https://git.openjdk.java.net/jdk/pull/3266

1 0

Proposal for Decimal64 and Decimal128 value-based classes
by Raffaello Giulietti 30 Mar '21

30 Mar '21

Hi, the intent of this proposal is to have numerical classes for *business and financial applications*, not to implement the IEEE 754-2019 spec for the sake of full coverage. The goal is to have numerical classes that are lighter-weight and more efficient in terms of storage space and computation time wrt BigDecimal *and* to adhere to a widespread standard whose model is familiar to many programmers. Perhaps some extended precision decimal format could be handy. On the other hand, I don't see why binary floating point numbers would be a useful option in this area. Greetings Raffaello > This would be interesting to have. > > It would be better if the full set of numbers b16-256 and d32-128 are > implemented so there is full coverage of all IEEE 754 numbers. > > > On Tue, 30 Mar 2021 at 01:45, Raffaello Giulietti < > raffaello.giulietti at gmail.com> wrote: > >> Hello, >> >> I'm experimenting with an implementation of Decimal64 and Decimal128, >> two standard IEEE 754-2019 formats supporting, well, decimal floating >> point numbers of up to 16 resp 34 decimal digits. >> >> While BigDecimal can simulate most finite number computations on these >> formats by passing MathContext.DECIMAL64 and MathContext.DECIMAL128, >> resp., to the arithmetic operations, this approach has some shortcomings >> wrt to the standard: >> * Like the binary formats (float and double in Java), the standard >> mandates signed zeroes, signed infinities and NaNs for the decimal >> formats as well, while BigDecimal has neither. >> * BigDecimal is not a final class, so is not (and can never be) >> value-based. >> * BigDecimal needs support from BigInteger (another non final, non >> value-based class). >> >> On the other hand, classes Decimal64 and Decimal128: >> * Are value-based and can be declared to be primitive in a future >> version of OpenJDK, once Valhalla is completed. >> * Require 12 and 20 bytes, resp, of storage in the Valhalla model of >> primitive objects and have no references to other identity or primitive >> objects. >> * Support the signed zeroes, the infinities and the NaNs. >> * Currently support the 4 fundamental operations (+ - * /) according to >> the standard and will support remainder, square root, comparisons, etc. >> and the conversions listed in the standard. >> * Could be extended to support the (rather cumbersome) exceptions >> handling of the standard. >> * There's no plan to support transcendental functions, as the aim is to >> have numerical classes for business applications, not scientific or >> engineering purposes. >> * Are faster than the (incomplete) simulation with BigDecimal, 1x-5x in >> the current incarnations. >> >> >> I would be glad to contribute the code to the OpenJDK provided there is >> a genuine interest from the community and a reviewer willing to sponsor >> my effort. (I guess the best candidate for this role would be Joe Darcy >> from what I can read in this mailing list.) >> >> >> Greetings >> Raffaello >>

1 0

RFR: 8263560: Remove needless wrapping with BufferedInputStream
by Сергей Цыпанов 30 Mar '21

30 Mar '21

In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within. Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required. ------------- Commit messages: - Use InputStream.readNBytes() - Drop unnecessary BufferedInputStream-wrapping where possible Changes: https://git.openjdk.java.net/jdk/pull/2992/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263560 Stats: 14 lines in 3 files changed: 2 ins; 7 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2992.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2992/head:pull/2992 PR: https://git.openjdk.java.net/jdk/pull/2992

5 21

Re: Comment on CSR 8251991: Hex formatting and parsing utility
by Raffaello Giulietti 29 Mar '21

29 Mar '21

Hello, I understand your points expressed in https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.h… On the other hand, it kind of hurts when the javadoc spec implies that the fromXXX() methods do not logically depend on the state and yet one has to invoke them on some instance anyway. As for HexFormat.of() to always return the same instance, you are of course right in observing that this is out of place for value-based classes. The intent was to describe a static-like idiom that would deter programmers to rewrite their own static version of these methods. Greetings Raffaello > Hi, > > The question about static vs instance methods was raised during the review. > At the time, my rationale for the current API is summarized in this email. > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.h… > > It comes down to choosing one kind of consistency vs another. > > I was/am looking for additional comments to weigh one or the other > alternative. > I did receive one offline comment in support of static methods on the > rationale of > convenience. > > Regards, Roger > > > On 3/15/21 12:06 PM, Raffaello Giulietti wrote: >> Hi, >> >> the javadoc of most of the methods listed in my previous post below >> reads: >> "The delimiter, prefix, suffix, and uppercase parameters are not >> used." >> >> As these eventually constitute the whole state of an instance of this >> final class and as the state is not involved, it is possible to >> declare the methods as static. >> >> >> If, for some reason, declaring the methods as static is not a choice, >> the next best thing is to clarify that >> * HexFormat.of() always returns the same instance and thus >> * absent any other instance, the recommended idiom for invoking any of >> the methods below is, for example, >> HexFormat.of().isHexDigit('F') >> (because there are almost no additional costs wrt static methods.) > Note that HexFormat is specified as a value based class and > any statement related to identity is out of place. > > Incidentally, its generally discouraged and can cause a warning when a > static method is invoked using a reference. > >> >> But I don't see a reason why they should be non-static. Just oversight? >> >> >> Greetings >> Raffaello >> >> >> On 2021-03-08 11:52, Raffaello Giulietti wrote: >>> Hello, >>> >>> it appears that all of the following API methods in [1] can be >>> declared *static*, which makes them more useful in contexts where >>> there's no instance of HexFormat available or none is desired. >>> >>> As 17 has not yet entered any formal phase, the change should be >>> harmless. >>> >>> public boolean isHexDigit(int); >>> public int fromHexDigit(int); >>> public int fromHexDigits(java.lang.CharSequence); >>> public int fromHexDigits(java.lang.CharSequence, int, int); >>> public long fromHexDigitsToLong(java.lang.CharSequence); >>> public long fromHexDigitsToLong(java.lang.CharSequence, int, int); >>> >>> Greetings >>> Raffaello >>> >>> ---- >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8251991

2 3

RFR: 8263754: HexFormat 'fromHex' methods should be static
by Roger Riggs 29 Mar '21

29 Mar '21

A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static. These APIs were added early in JDK 17 and are being updated before GA. This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files. public boolean isHexDigit(int); public int fromHexDigit(int); public int fromHexDigits(java.lang.CharSequence); public int fromHexDigits(java.lang.CharSequence, int, int); public long fromHexDigitsToLong(java.lang.CharSequence); public long fromHexDigitsToLong(java.lang.CharSequence, int, int); ------------- Commit messages: - 8263754: HexFormat 'fromHex' methods should be static Changes: https://git.openjdk.java.net/jdk/pull/3205/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3205&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263754 Stats: 47 lines in 5 files changed: 0 ins; 8 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/3205.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3205/head:pull/3205 PR: https://git.openjdk.java.net/jdk/pull/3205

4 8

RFR: 8248418: jpackage fails to extract main class and version from app module linked in external runtime
by Alexey Semenyuk 29 Mar '21

29 Mar '21

Remove the test for failing jpackage use case scenario that we don't intent to fix ------------- Commit messages: - 8248418: jpackage fails to extract main class and version from app module linked in external runtime Changes: https://git.openjdk.java.net/jdk/pull/3249/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3249&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248418 Stats: 23 lines in 2 files changed: 0 ins; 23 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3249.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3249/head:pull/3249 PR: https://git.openjdk.java.net/jdk/pull/3249

3 3

Integrated: 8264332: Use the blessed modifier order in jdk.charsets
by Alex Blewitt 29 Mar '21

29 Mar '21

On Sun, 28 Mar 2021 13:56:00 GMT, Alex Blewitt <github.com+76791+alblue(a)openjdk.org> wrote: > 8264332: Use the blessed modifier order in jdk.charsets This pull request has now been integrated. Changeset: 364cce14 Author: Alex Blewitt <alex.blewitt(a)gmail.com> Committer: Aleksey Shipilev <shade(a)openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/364cce14 Stats: 56 lines in 6 files changed: 0 ins; 0 del; 56 mod 8264332: Use the blessed modifier order in jdk.charsets Reviewed-by: alanb, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/3236

1 0

Re: RFR: 8264332: Use the blessed modifier order in jdk.charsets
by Aleksey Shipilev 29 Mar '21

29 Mar '21

On Sun, 28 Mar 2021 13:56:00 GMT, Alex Blewitt <github.com+76791+alblue(a)openjdk.org> wrote: > 8264332: Use the blessed modifier order in jdk.charsets Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3236

1 0

RFR: 8264029: Replace uses of StringBuffer with StringBuilder in java.base
by Andrey Turbanov 29 Mar '21

29 Mar '21

Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'` As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.base` Similar cleanup in the past - https://bugs.openjdk.java.net/browse/JDK-8041679 ------------- Commit messages: - [PATCH] Replaces usages of StringBuffer with StringBuilder where appropriate in java.base Changes: https://git.openjdk.java.net/jdk/pull/2922/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2922&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264029 Stats: 12 lines in 3 files changed: 0 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2922.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2922/head:pull/2922 PR: https://git.openjdk.java.net/jdk/pull/2922

3 6