On Tue, 30 Mar 2021 16:56:57 GMT, Mahendra Chhipa
wrote:
> JDK-8264454 : Jaxp unit test from open jdk needs to be improved
test/jaxp/javax/xml/jaxp/unittest/common/Bug6350682.java line 47:
> 45: @Test
> 46: public void testSAXParserFactory() {
> 47: runWithAllPerm(() ->
> Thre
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` "and(m.not
They'll find a natural home in JDBC, since SQL has a native decimal type.
On 3/30/2021 7:05 PM, Raffaello Giulietti wrote:
As far as I can tell, scientific computation will make use of binary
floating point numbers for a long time. Decimal floating point numbers
are still limited to biz and f
Hello Roger,
these are the changes I'm proposing after reviewing the code of
j.u.HexFormat. The modified code available here
https://github.com/rgiulietti/jdk/commit/6759a25eb952ab19a045a83349d41b82cc1b07cb
In addition to other smaller, hopefully self-explanatory enhancements,
here are the r
This is a patch for test class "CompareIC", providing 100% unit test
coverage of the fixed "java.lang.StringUTF16" methods "compareToCI" and
"regionMatchesCI" in part 1 of this proposed contribution.
The tests also provide 100% coverage of the current implementations of
those methods, and, if run
Historically, the methods currently known as "compareToCI" and
"regionMatchesCI", and located in "java.lang.StringUTF16", have lacked
support for Supplementary Multilingual Plane code-points. (I've seen no
associated bug.)
On July 23, 2020 the first fix for the bug was committed. However, it
inclu
> On Mar 30, 2021, at 4:05 PM, Raffaello Giulietti
> wrote:
>
> Hi Paul,
>
>
> On 2021-03-30 22:54, Paul Sandoz wrote:
>>> On Mar 30, 2021, at 1:03 PM, Brian Goetz wrote:
>>>
>>> Overall, I'd be happy to see Decimal types that are aimed at "reasonable
>>> precision" in addition to the inf
Ciao Maurizio,
thanks for your interest.
On 2021-03-30 23:01, Maurizio Cimadamore wrote:
Add me to the list of interested folks.
Will do.
Such types are useful when interacting with System ABIs, and the Foreign
Linker API needs "well-known" carrier which model these types in Java.
There
Hi Paul,
On 2021-03-30 22:54, Paul Sandoz wrote:
On Mar 30, 2021, at 1:03 PM, Brian Goetz wrote:
Overall, I'd be happy to see Decimal types that are aimed at "reasonable
precision" in addition to the infinite precision that BD offers. (After Valhalla,
of course.)
Yes, me too.
Raffae
There's no strict need for Valhalla, as they are more compact and faster
than BigDecimal even today.
On 2021-03-30 22:03, Brian Goetz wrote:
Overall, I'd be happy to see Decimal types that are aimed at "reasonable
precision" in addition to the infinite precision that BD offers. (After
Valhal
Hi Joe,
On 2021-03-30 21:56, Joe Darcy wrote:
Hi Raffaello,
On 3/29/2021 1:14 PM, Raffaello Giulietti wrote:
Hello,
Assuming you have DecimalN <-> BigDecimal conversions, the BigDecimal
type should be usable for testing at least. For in-range values not near
the exponent range, the scale
On Tue, 30 Mar 2021 11:48:36 GMT, Maurizio Cimadamore
wrote:
>> Happy to submit a fix elsewhere if that's the right thing to do?
>
> 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
> styl
Add me to the list of interested folks.
Such types are useful when interacting with System ABIs, and the Foreign
Linker API needs "well-known" carrier which model these types in Java.
There are also other interesting types to be explored in that domain,
such as Long128, LongDouble (extended pr
> On Mar 30, 2021, at 1:03 PM, Brian Goetz wrote:
>
> Overall, I'd be happy to see Decimal types that are aimed at "reasonable
> precision" in addition to the infinite precision that BD offers. (After
> Valhalla, of course.)
>
Yes, me too.
Raffaello, as an experiment you could develop suc
Overall, I'd be happy to see Decimal types that are aimed at "reasonable
precision" in addition to the infinite precision that BD offers. (After
Valhalla, of course.)
On 3/29/2021 4:14 PM, Raffaello Giulietti wrote:
Hello,
I'm experimenting with an implementation of Decimal64 and Decimal12
On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote:
> 8264148: Update spec for exceptions retrofitted for exception chaining
This pull request has now been integrated.
Changeset: 815248ab
Author:Joe Darcy
URL: https://git.openjdk.java.net/jdk/commit/815248ab
Stats: 84 lines in 22
On 3/29/2021 6:13 PM, Suminda Sirinath Salpitikorala Dharmasena wrote:
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.
FYI, if one is need of such code in C today, you can lo
Hi Raffaello,
On 3/29/2021 1:14 PM, Raffaello Giulietti 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.
Fun project!
While BigDecima
On Sat, 27 Mar 2021 15:19:37 GMT, Attila Szegedi wrote:
> I noticed that `javax.script.ScriptEngineManager` `getEngineByXxx` methods
> had a lot of code duplication among themselves, and even within each method.
> I refactored them into a modern unified implementation. While there I also
> too
On Tue, 30 Mar 2021 12:43:18 GMT, Athijegannathan Sundararajan
wrote:
>> Attila Szegedi has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contai
On Sun, 28 Feb 2021 16:46:31 GMT, Attila Szegedi wrote:
> 8262503: Support records in Dynalink
This pull request has now been integrated.
Changeset: b08d6383
Author:Attila Szegedi
URL: https://git.openjdk.java.net/jdk/commit/b08d6383
Stats: 165 lines in 8 files changed: 153 ins;
On Tue, 30 Mar 2021 12:38:41 GMT, Athijegannathan Sundararajan
wrote:
>> 8262503: Support records in Dynalink
>
> Looks good
Thank you for the review, @sundararajana!
-
PR: https://git.openjdk.java.net/jdk/pull/2767
On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote:
> 8264148: Update spec for exceptions retrofitted for exception chaining
Marked as reviewed by smarks (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3182
JDK-8264454 : Jaxp unit test from open jdk needs to be improved
-
Commit messages:
- JDK-8264454 : Jaxp unit test from open jdk needs to be improved
- JDK-8064681 : Jaxp unit test need to be improved
Changes: https://git.openjdk.java.net/jdk/pull/3274/files
Webrev: https://webrevs
Hi Alan
As Marco mentioned, another use case is sub-process stdin/stdout/stderr. In my
particular instance, I'm starting a Process which has its output redirected to
a file. It uses the platform's default encoding for writing to stdout. So when
I want to read its output from the file at some la
On 3/30/2021 6:29 AM, Roger Riggs wrote:
On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote:
8264148: Update spec for exceptions retrofitted for exception chaining
I agree that the public field in WriteAbortedException could be remediated.
But it is also mostly harmless.
src/jdk.hotspot.age
On 3/30/2021 6:43 AM, jmehrens wrote:
On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote:
8264148: Update spec for exceptions retrofitted for exception chaining
src/java.base/share/classes/java/io/WriteAbortedException.java line 86:
84: @Override
85: public Throwable getCause() {
8
On Mon, 22 Mar 2021 10:35:03 GMT, Mahendra Chhipa
wrote:
> https://bugs.openjdk.java.net/browse/JDK-8064681
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jdk/pull/3115
On Wed, 24 Mar 2021 14:47:56 GMT, Mark Sheppard wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8064681
>
> the tests set a system property and then clear that system property at the
> end of the test. Is it always the case that the property being set in the
> test does not have a value pri
On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote:
> 8264148: Update spec for exceptions retrofitted for exception chaining
src/java.base/share/classes/java/io/WriteAbortedException.java line 86:
> 84: @Override
> 85: public Throwable getCause() {
> 86: return detail;
Use Suppr
On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote:
> 8264148: Update spec for exceptions retrofitted for exception chaining
I agree that the public field in WriteAbortedException could be remediated.
But it is also mostly harmless.
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMO
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:
- 82
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> javadoc can be found at
> http://cr.openjdk.java.net/~jlaskey/prng/doc/a
On Sun, 28 Mar 2021 13:38:51 GMT, Attila Szegedi wrote:
>> I noticed that `javax.script.ScriptEngineManager` `getEngineByXxx` methods
>> had a lot of code duplication among themselves, and even within each method.
>> I refactored them into a modern unified implementation. While there I also
>>
On Sun, 28 Feb 2021 16:46:31 GMT, Attila Szegedi wrote:
> 8262503: Support records in Dynalink
Looks good
-
Marked as reviewed by sundar (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2767
On Tue, 30 Mar 2021 08:14:58 GMT, Alex Blewitt
wrote:
>> This one should probably be fixed in the upstream repo over at
>> https://github.com/openjdk/panama-foreign (I believe). /ping @JornVernee
>> @mcimadamore
>
> Happy to submit a fix elsewhere if that's the right thing to do?
Hi @alblue,
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, for instance,
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> javadoc can be found at
> http://cr.openjdk.java.net/~jlaskey/prng/doc/a
On Thu, 18 Mar 2021 12:57:16 GMT, Jim Laskey wrote:
>> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line
>> 62:
>>
>>> 60: @Retention(RetentionPolicy.RUNTIME)
>>> 61: @Target(ElementType.TYPE)
>>> 62: public @interface RandomGeneratorProperties {
>>
>> Sh
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 comput
On Mon, 29 Mar 2021 23:54:19 GMT, Claes Redestad wrote:
>> 8264397: Use the blessed modifier order in jdk.incubator.foreign
>
> This one should probably be fixed in the upstream repo over at
> https://github.com/openjdk/panama-foreign (I believe). /ping @JornVernee
> @mcimadamore
Happy to subm
41 matches
Mail list logo
