Discussion about Java Floating Point?

[A Z]

To core-libs-dev@openjdk.java.net,

In terms of floating point, it seems there are thus
three (3) phenomena that are relevant.

1) Arithmetic on float and double, via operators.
2) Elementary function calls, namely
   those made from java.lang.StrictMath, as it is,
   on double values.
3) Comparison operators.  ==, !=, >, <, >=,<=.

Java floating point successfully has 3) the way required,
even though other languages, particularly C++ , do not
compare their floats and doubles through those comparison
operators.  The point at issue is Java although, so Java is
satisfactory at point 3).

My point of contention is that Java does not have 1) and 2)
operating as they should, even though C++ and other
languages do, in those two areas, namely C++:

Martin has submitted the following:
?The following statement is not entirely true when using finite floating
point precision:

> (?snip?) It is a mathematical fact that, for
> consistent, necessary and even fast term, 10% of 10% must
> always precisely be 1%, and by no means anything else."
/*
#include 

using namespace std;

int main()
{
cout << "Program has started..." << endl;
double a = 0.1D;
double b = 0.1D;
double c = a*b;
cout << endl << c << endl << endl;
float d = 0.1F;
float e = 0.1F;
float f = d*e;
cout << f << endl << endl;
cout << "Program has Finished.";
return 0;
}
*/
/*
Program has started...

0.01

0.01

Program has Finished.
*/

This is actually not fully or finally true, including SSE, SSE algorithm logic 
and further.
The included C++ example of mine above here disproves this.  Even though I do
contextually admit these answers can only work within the range of the
involved types, it is still actually the case that 10% of 10% can and always
precisely be 1%, within the range of the type used, and by no means
anything else.  Because of the laws of decimal arithmetic.

See https://en.wikipedia.org/wiki/Floating-point_arithmetic
and the starting sentence:

'In computing, floating-point arithmetic (FP) is arithmetic using formulaic
representation of real numbers as an approximation to support a
trade-off betwee range and precision.'

However, it simply isn't the case that reduced precision has to exist inside
the range, certainly not any more.  Rationally, one would have to think,
with the present SSE support in ubiquity, and the preimplementation
that is possible and already around elsewhere, that this kind of tradeoff
in floating point isn't any kind of use or advantage any more.

This is part of the issue with Java and the OpenJDK at this time, and I am 
trying
to contend that this should be changed, either at default or in
some mutual compatibility mode.  The other part is java.lang.StrictMath,
since it generates denormal and pronormal values on its own, also.

Raffaello has stated:
To summarize, Java uses IEEE 754 binary arithmetic as by specification,
as do most other languages, including C/C++. It is however fundamentally
wrong to use binary floating-point arithmetic to emulate decimal
behavior. Also, pay attention to the output routines that convert float
and double values to a decimal representation. Usually, C and C++ will
have information loss by default, as in your case.
What we and others are beginning to need to happen, in detailed Java 2D
and 3D (JMonkeyEngine 3.5) projects, and more widely again, is that Java
floating point arithmetic and function behaviour, on float and double,
within their ranges, do need to perfectly match decimal behaviour.

C++ arithmetic, at least, has had no problem using floating point arithmetic,
at least, to emulate decimal behaviour.  I am trying to prove the opposite to
Raffaello's statements, that floating point can and indeed must represent 
decimal behaviour.
Output functions in any language that alter the appearance of the float or 
double
value become irrelevant, because the only relevant factor is the operator 
behaviour
and the innate, representation viewpoint of those float or double values.

In contrast to Raffaelo, we assert that Java SE and OpenJDK floating point must 
be changed
so that it upholds base ten (10) arithmetic, algebra,and elementary functions 
on real value
arguments within the ranges of double and/or float.  Alongside a calculator 
class that upholds
the same.  These are in keeping with the Wikipedia view on floating point 
arithmetic that I
quoted earlier, but more than that, they are in keeping with the 
standards/specifications of
Mathematics, and not just an idea that grew in computer science.

I wish to still request that this matter be pursued, despite Java's stance on 
this matter,
in terms of the JRE for a very long time now.

While it is the case that JDK-8190991 does exist, and should continue, 
JDK-8190947
has been too blithely swept away. See: 
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190947
The explanation 'Closing this enhancement as will not fix' does nothing to 
explain why the advantages
of floating point repair 

Re: RFR: 8282162: [vector] Optimize vector negation API

[Xiaohong Gong]

On Tue, 15 Mar 2022 02:39:42 GMT, Joe Darcy  wrote:

> Note that in terms of Java semantics, negation of floating point values needs 
> to be implemented as subtraction from negative zero rather than positive zero:
> 
> double negate(double arg) {return -0.0 - arg; }
> 
> This is to handle signed zeros correctly.

Hi @jddarcy ,thanks for looking at this PR and thanks for the notes on the 
floating point negation! Yeah, this really makes sense to me. Kindly note that 
this patch didn't touch the negation of the floating point values. For Vector 
API, the vector floating point negation has been intrinsified to `NegVF/D` node 
by compiler that we directly generate the negation instructions for them. 
Thanks!

-

PR: https://git.openjdk.java.net/jdk/pull/7782

Re: RFR: 8282162: [vector] Optimize vector negation API

[Joe Darcy]

On Fri, 11 Mar 2022 06:29:22 GMT, Xiaohong Gong  wrote:

> The current vector `"NEG"` is implemented with substraction a vector by zero 
> in case the architecture does not support the negation instruction. And to 
> fit the predicate feature for architectures that support it, the masked 
> vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both 
> can be optimized to a single negation instruction for ARM SVE.
> And so does the non-masked "NEG" for NEON. Besides, implementing the masked 
> "NEG" with substraction for architectures that support neither negation 
> instruction nor predicate feature can also save several instructions than the 
> current pattern.
> 
> To optimize the VectorAPI negation, this patch moves the implementation from 
> Java side to hotspot. The compiler will generate different nodes according to 
> the architecture:
>   - Generate the (predicated) negation node if architecture supports it, 
> otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does 
> not have predicate feature, otherwise generate the original pattern 
> `"v.xor(-1, m).add(1, m)"`.
> 
> So with this patch, the following transformations are applied:
> 
> For non-masked negation with NEON:
> 
>   moviv16.4s, #0x0
>   sub v17.4s, v16.4s, v17.4s   ==> neg v17.4s, v17.4s
> 
> and with SVE:
> 
>   mov z16.s, #0
>   sub z18.s, z16.s, z17.s  ==> neg z16.s, p7/m, z16.s
> 
> For masked negation with NEON:
> 
>   moviv17.4s, #0x1
>   mvn v19.16b, v18.16b
>   mov v20.16b, v16.16b ==>  neg v18.4s, v17.4s
>   bsl v20.16b, v19.16b, v18.16b bsl v19.16b, v18.16b, v17.16b
>   add v19.4s, v20.4s, v17.4s
>   mov v18.16b, v16.16b
>   bsl v18.16b, v19.16b, v20.16b
> 
> and with SVE:
> 
>   mov z16.s, #-1
>   mov z17.s, #1==> neg z16.s, p0/m, z16.s
>   eor z18.s, p0/m, z18.s, z16.s
>   add z18.s, p0/m, z18.s, z17.s
> 
> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 
> machines(note that the non-masked negation benchmarks do not have any 
> improvement on X86 since no instructions are changed):
> 
> NEON:
> BenchmarkGain
> Byte128Vector.NEG1.029
> Byte128Vector.NEGMasked  1.757
> Short128Vector.NEG   1.041
> Short128Vector.NEGMasked 1.659
> Int128Vector.NEG 1.005
> Int128Vector.NEGMasked   1.513
> Long128Vector.NEG1.003
> Long128Vector.NEGMasked  1.878
> 
> SVE with 512-bits:
> BenchmarkGain
> ByteMaxVector.NEG1.10
> ByteMaxVector.NEGMasked  1.165
> ShortMaxVector.NEG   1.056
> ShortMaxVector.NEGMasked 1.195
> IntMaxVector.NEG 1.002
> IntMaxVector.NEGMasked   1.239
> LongMaxVector.NEG1.031
> LongMaxVector.NEGMasked  1.191
> 
> X86 (non AVX-512):
> BenchmarkGain
> ByteMaxVector.NEGMasked  1.254
> ShortMaxVector.NEGMasked 1.359
> IntMaxVector.NEGMasked   1.431
> LongMaxVector.NEGMasked  1.989
> 
> [1] 
> https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
> [2] 
> https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896

Note that in terms of Java semantics, negation of floating point values needs 
to be implemented as subtraction from negative zero rather than positive zero:

double negate(double arg) {return -0.0 - arg; }

This is to handle signed zeros correctly.

-

PR: https://git.openjdk.java.net/jdk/pull/7782

Re: RFR: JDK-8283143: Use minimal-length literals to initialize PI and E constants

[Stuart Marks]

On Tue, 15 Mar 2022 01:36:14 GMT, Joe Darcy  wrote:

> Depending on the range of the number line, a double value has between 15 and 
> 17 digits of decimal precision. The literals used to initialize Math.PI and 
> Math.E have several digits more precision than that maximum.
> 
> That is potentially confusing to readers of the code and the minimum length 
> strings to exactly represent the value in question should be used instead.

I've verified that the shorter literals result in the same double bit pattern.

-

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7814

Re: RFR: JDK-8283124: Add constant for tau to Math and StrictMath [v2]

[Iris Clark]

On Mon, 14 Mar 2022 23:21:26 GMT, Joe Darcy  wrote:

>> Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very 
>> common value in mathematical formulas, it is helpful to give it a distinct 
>> constant.
>> 
>> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136
>
> Joe Darcy has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Set value with 2.0 * PI.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7813

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]

[Valerie Peng]

On Mon, 14 Mar 2022 21:08:30 GMT, Weijun Wang  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Update again and undo DSA changes
>
> src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java 
> line 121:
> 
>> 119: v = max;
>> 120: }
>> 121: } catch (NullPointerException | NoSuchAlgorithmException 
>> ne) {
> 
> There is no need to mention NPE.

Sure.

-

PR: https://git.openjdk.java.net/jdk/pull/7652

RFR: JDK-8283143: Use minimal-length literals to initialize PI and E constants

[Joe Darcy]

Depending on the range of the number line, a double value has between 15 and 17 
digits of decimal precision. The literals used to initialize Math.PI and Math.E 
have several digits more precision than that maximum.

That is potentially confusing to readers of the code and the minimum length 
strings to exactly represent the value in question should be used instead.

-

Commit messages:
 - JDK-8283143: Use minimal-length literals to initialize PI and E constants

Changes: https://git.openjdk.java.net/jdk/pull/7814/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7814=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283143
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7814.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7814/head:pull/7814

PR: https://git.openjdk.java.net/jdk/pull/7814

Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v17]

[Stuart Marks]

On Sat, 12 Mar 2022 01:26:24 GMT, Yasser Bazzi  wrote:

>> Hi, could i get a review on this implementation proposed by Stuart Marks, i 
>> decided to use the 
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html
>>  interface to create the default method `asRandom()` that wraps around the 
>> newer algorithms to be used on classes that do not accept the new interface.
>> 
>> Some things to note as proposed by the bug report, the protected method 
>> next(int bits) is not overrided and setSeed() method if left blank up to 
>> discussion on what to do with it.
>> 
>> Small test done on 
>> https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4
>
> Yasser Bazzi has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   make changes proposed

Thanks for the updates. I've updated the CSR and it should go through the 
review process now. I've also pulled the latest changes and will run them 
through our internal build/test system.

-

PR: https://git.openjdk.java.net/jdk/pull/7001

Re: RFR: 8282162: [vector] Optimize vector negation API

[Xiaohong Gong]

On Fri, 11 Mar 2022 06:29:22 GMT, Xiaohong Gong  wrote:

> The current vector `"NEG"` is implemented with substraction a vector by zero 
> in case the architecture does not support the negation instruction. And to 
> fit the predicate feature for architectures that support it, the masked 
> vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both 
> can be optimized to a single negation instruction for ARM SVE.
> And so does the non-masked "NEG" for NEON. Besides, implementing the masked 
> "NEG" with substraction for architectures that support neither negation 
> instruction nor predicate feature can also save several instructions than the 
> current pattern.
> 
> To optimize the VectorAPI negation, this patch moves the implementation from 
> Java side to hotspot. The compiler will generate different nodes according to 
> the architecture:
>   - Generate the (predicated) negation node if architecture supports it, 
> otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does 
> not have predicate feature, otherwise generate the original pattern 
> `"v.xor(-1, m).add(1, m)"`.
> 
> So with this patch, the following transformations are applied:
> 
> For non-masked negation with NEON:
> 
>   moviv16.4s, #0x0
>   sub v17.4s, v16.4s, v17.4s   ==> neg v17.4s, v17.4s
> 
> and with SVE:
> 
>   mov z16.s, #0
>   sub z18.s, z16.s, z17.s  ==> neg z16.s, p7/m, z16.s
> 
> For masked negation with NEON:
> 
>   moviv17.4s, #0x1
>   mvn v19.16b, v18.16b
>   mov v20.16b, v16.16b ==>  neg v18.4s, v17.4s
>   bsl v20.16b, v19.16b, v18.16b bsl v19.16b, v18.16b, v17.16b
>   add v19.4s, v20.4s, v17.4s
>   mov v18.16b, v16.16b
>   bsl v18.16b, v19.16b, v20.16b
> 
> and with SVE:
> 
>   mov z16.s, #-1
>   mov z17.s, #1==> neg z16.s, p0/m, z16.s
>   eor z18.s, p0/m, z18.s, z16.s
>   add z18.s, p0/m, z18.s, z17.s
> 
> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 
> machines(note that the non-masked negation benchmarks do not have any 
> improvement on X86 since no instructions are changed):
> 
> NEON:
> BenchmarkGain
> Byte128Vector.NEG1.029
> Byte128Vector.NEGMasked  1.757
> Short128Vector.NEG   1.041
> Short128Vector.NEGMasked 1.659
> Int128Vector.NEG 1.005
> Int128Vector.NEGMasked   1.513
> Long128Vector.NEG1.003
> Long128Vector.NEGMasked  1.878
> 
> SVE with 512-bits:
> BenchmarkGain
> ByteMaxVector.NEG1.10
> ByteMaxVector.NEGMasked  1.165
> ShortMaxVector.NEG   1.056
> ShortMaxVector.NEGMasked 1.195
> IntMaxVector.NEG 1.002
> IntMaxVector.NEGMasked   1.239
> LongMaxVector.NEG1.031
> LongMaxVector.NEGMasked  1.191
> 
> X86 (non AVX-512):
> BenchmarkGain
> ByteMaxVector.NEGMasked  1.254
> ShortMaxVector.NEGMasked 1.359
> IntMaxVector.NEGMasked   1.431
> LongMaxVector.NEGMasked  1.989
> 
> [1] 
> https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
> [2] 
> https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896

Hi, could anyone please take a look at this PR? Thanks so much!

-

PR: https://git.openjdk.java.net/jdk/pull/7782

Re: RFR: JDK-8236128: Allow jpackage create installers for services

[Alexander Matveev]

On Fri, 11 Mar 2022 23:37:06 GMT, Alexey Semenyuk  wrote:

> Implementation of [JDK-8275062: "Allow jpackage create installers for 
> services"](https://bugs.openjdk.java.net/browse/JDK-8275062)
>  CSR

Marked as reviewed by almatvee (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7793

Re: RFR: JDK-8283124: Add constant for tau to Math and StrictMath

[Joseph D. Darcy]

Hi Raffaello,

With changing TAU to be set to 2.0 * PI, I'll file a follow-up bug to 
use the least-precision decimal values that will get rounded to PI and 
E, respectively, in Math and StrictMath. (Per the general base 
conversion properties for the double format, there will be between 15 
and 17 decimal digits rather than 21.)


Thanks,

-Joe

On 3/14/2022 2:32 PM, Raffaello Giulietti wrote:

Hello,

I find it a bit disturbing that PI is specified with 21 digits whereas 
TAU has 16.

I think that specifying PI as
    public static final double PI = 3.141592653589793;
doesn't harm anybody and makes it visually more consistent with TAU-


Greetings
Raffaello



On 3/14/22 22:13, Brian Burkhalter wrote:

On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy  wrote:

Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is 
a very common value in mathematical formulas, it is helpful to give 
it a distinct constant.


Please also review the CSR 
https://bugs.openjdk.java.net/browse/JDK-8283136


Marked as reviewed by bpb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7813

Re: RFR: JDK-8283124: Add constant for tau to Math and StrictMath [v2]

[Joe Darcy]

> Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very 
> common value in mathematical formulas, it is helpful to give it a distinct 
> constant.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136

Joe Darcy has updated the pull request incrementally with one additional commit 
since the last revision:

  Set value with 2.0 * PI.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7813/files
  - new: https://git.openjdk.java.net/jdk/pull/7813/files/c5931750..0fae656a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7813=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7813=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7813.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7813/head:pull/7813

PR: https://git.openjdk.java.net/jdk/pull/7813

Re: RFR: JDK-8283124: Add constant for tau to Math and StrictMath

[Joe Darcy]

On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy  wrote:

> Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very 
> common value in mathematical formulas, it is helpful to give it a distinct 
> constant.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136

> _Mailing list message from [Hans Boehm](mailto:hbo...@google.com) on 
> [core-libs-dev](mailto:core-libs-...@mail.openjdk.java.net):_
> 
> Couldn't the apiNote just say TAU == 2 * PI instead? I think the fact that 
> this is actually a guaranteed floating point equality aids clarity.
> 
> On Mon, Mar 14, 2022 at 2:33 PM Raffaello Giulietti < raffaello.giulietti at 
> gmail.com> wrote:
> 
> > Hello,
> > I find it a bit disturbing that PI is specified with 21 digits whereas
> > TAU has 16.
> > I think that specifying PI as
> > public static final double PI = 3.141592653589793;
> > doesn't harm anybody and makes it visually more consistent with TAU-
> > Greetings
> > Raffaello
> > On 3/14/22 22:13, Brian Burkhalter wrote:
> > > On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy  wrote:
> > > > Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a
> > > > very common value in mathematical formulas, it is helpful to give it a
> > > > distinct constant.
> > > > Please also review the CSR
> > > > https://bugs.openjdk.java.net/browse/JDK-8283136

Yes; after further thought, I agree having tau = 2.0*pi is preferable.

Just to go through the logic, 2.0 is exactly representable in binary 
floating-point and an in-range multiple by two is just an exponent adjustment.

Floating-point exponent transitions occur at 2.0 = 0x1 * 2^1, 4.0 = 0x1 * 2^2, 
and 8.0 = 0x1 * 2^3. The value of pi is between 2.0 and 4.0 and has an exponent 
of 1 while the value of tau ~= 6.28 is between 4.0 and 8.0 and has an exponent 
of 2.

So whatever the closest floating-point value to exact pi is, 2.0 * Math.pi will 
be the closest floating-point value to tau.

-

PR: https://git.openjdk.java.net/jdk/pull/7813

Re: RFR: 8253495: CDS generates non-deterministic output [v6]

[Calvin Cheung]

On Fri, 11 Mar 2022 06:55:23 GMT, Ioi Lam  wrote:

>> This patch makes the result of "java -Xshare:dump" deterministic:
>> - Disabled new Java threads from launching. This is harmless. See comments 
>> in jvm.cpp
>> - Fixed a problem in hashtable ordering in heapShared.cpp
>> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random 
>> bits. Added code to zero it.
>> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in 
>> make/scripts/compare.sh
>> 
>> Note:  $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. 
>> This will be fixed in 
>> [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828).
>> 
>> Testing under way:
>> - tier1~tier5
>> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, 
>> windows-x86-cmp-baseline,  etc).
>
> Ioi Lam has updated the pull request incrementally with one additional commit 
> since the last revision:
> 
>   Added helper function CollectedHeap::zap_filler_array_with

CDS changes look good. One minor comment on a test.

test/hotspot/jtreg/runtime/cds/appcds/javaldr/LockDuringDumpAgent.java line 65:

> 63: if (elapsed >= timeout) {
> 64: System.out.println("This JVM may decide to not 
> launch any Java threads during -Xshare:dump.");
> 65: System.out.println("This is OK because no string 
> objects be in a locked state during heap dump.");

Should `no string objects be` be `no string objects could be`?

-

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7748

Re: RFR: JDK-8283124: Add constant for tau to Math and StrictMath

[Raffaello Giulietti]

Right, and PI with 16 digits (or 17).


On 3/14/22 22:51, Hans Boehm wrote:
Couldn't the apiNote just say TAU == 2 * PI instead? I think the fact 
that this is actually a guaranteed floating point equality aids clarity.




On Mon, Mar 14, 2022 at 2:33 PM Raffaello Giulietti 
mailto:raffaello.giulie...@gmail.com>> 
wrote:


Hello,

I find it a bit disturbing that PI is specified with 21 digits whereas
TAU has 16.
I think that specifying PI as
      public static final double PI = 3.141592653589793;
doesn't harm anybody and makes it visually more consistent with TAU-


Greetings
Raffaello



On 3/14/22 22:13, Brian Burkhalter wrote:
 > On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy mailto:da...@openjdk.org>> wrote:
 >
 >> Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi
is a very common value in mathematical formulas, it is helpful to
give it a distinct constant.
 >>
 >> Please also review the CSR
https://bugs.openjdk.java.net/browse/JDK-8283136

 >
 > Marked as reviewed by bpb (Reviewer).
 >
 > -
 >
 > PR: https://git.openjdk.java.net/jdk/pull/7813

Re: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2]

[Vicente Romero]

On Mon, 14 Mar 2022 21:27:29 GMT, Joe Darcy  wrote:

>> Improving the exception messages for out-of-supported-range array types.
>> 
>> I'll update copyrights before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Respond to review feedback.

lgtm

-

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7812

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v3]

[Naoto Sato]

On Mon, 14 Mar 2022 20:39:46 GMT, Alisen Chung  wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   removed repeated lines from ROOT bundle in CurrencyNames

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct_ja.properties 
line 1:

> 1: #

The change to this file (moving ct.properties to ct_ja.properties) does look 
suspicious. Looks like this is not a translation file, but some kind of a 
configuration for `javac`. If so, it should not be translated (and translation 
configuration in the closed repository should exclude this file)

-

PR: https://git.openjdk.java.net/jdk/pull/7765

Re: RFR: JDK-8283124: Add constant for tau to Math and StrictMath

[Raffaello Giulietti]

Hello,

I find it a bit disturbing that PI is specified with 21 digits whereas 
TAU has 16.

I think that specifying PI as
public static final double PI = 3.141592653589793;
doesn't harm anybody and makes it visually more consistent with TAU-


Greetings
Raffaello



On 3/14/22 22:13, Brian Burkhalter wrote:

On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy  wrote:


Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very 
common value in mathematical formulas, it is helpful to give it a distinct 
constant.

Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136


Marked as reviewed by bpb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7813

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]

[Weijun Wang]

On Mon, 14 Mar 2022 20:08:31 GMT, Valerie Peng  wrote:

>> It's been several years since we increased the default key sizes. Before 
>> shifting to PQC, NSA replaced its Suite B cryptography recommendations with 
>> the Commercial National Security Algorithm Suite which suggests:
>> 
>> - SHA-384 for secure hashing
>> - AES-256 for symmetric encryption
>> - RSA with 3072 bit keys for digital signatures and for key exchange
>> - Diffie Hellman (DH) with 3072 bit keys for key exchange
>> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures 
>> (ECDSA)
>> 
>> So, this proposed changes made the suggested key size and algorithm changes. 
>> The changes are mostly in keytool, jarsigner and their regression tests, so 
>> @wangweij Could you please take a look?
>> 
>> Thanks!
>
> Valerie Peng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Update again and undo DSA changes

Some small comments. Otherwise looks fine.

src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java 
line 121:

> 119: v = max;
> 120: }
> 121: } catch (NullPointerException | NoSuchAlgorithmException ne) 
> {

There is no need to mention NPE.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java
 line 101:

> 99: // set default key sizes and apply our own algorithm-specific 
> limits
> 100: // override lower limit to disallow unsecure keys being generated
> 101: // override upper limit to deter DOS attack

No a P11 expert, but I assume `algorithm` here is already guaranteed to be in 
uppercase?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java
 line 122:

> 120: default -> {
> 121: throw new ProviderException
> 122: ("Unrecognized algorithm for checking key size");

If it's an unknown key algorithm, is it possible we just ignore it and keep 
using `minKeyLen` and `maxKeyLen`?

-

PR: https://git.openjdk.java.net/jdk/pull/7652

Re: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2]

[Joe Darcy]

> Improving the exception messages for out-of-supported-range array types.
> 
> I'll update copyrights before pushing.

Joe Darcy has updated the pull request incrementally with one additional commit 
since the last revision:

  Respond to review feedback.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7812/files
  - new: https://git.openjdk.java.net/jdk/pull/7812/files/51388988..1723d710

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7812=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7812=00-01

  Stats: 14 lines in 1 file changed: 9 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7812.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7812/head:pull/7812

PR: https://git.openjdk.java.net/jdk/pull/7812

Re: RFR: JDK-8283124: Add constant for tau to Math and StrictMath

[Brian Burkhalter]

On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy  wrote:

> Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very 
> common value in mathematical formulas, it is helpful to give it a distinct 
> constant.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136

Marked as reviewed by bpb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7813

RFR: JDK-8283124: Add constant for tau to Math and StrictMath

[Joe Darcy]

Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very 
common value in mathematical formulas, it is helpful to give it a distinct 
constant.

Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136

-

Commit messages:
 - JDK-8283124: Add constant for tau to Math and StrictMath

Changes: https://git.openjdk.java.net/jdk/pull/7813/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7813=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283124
  Stats: 29 lines in 2 files changed: 26 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7813.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7813/head:pull/7813

PR: https://git.openjdk.java.net/jdk/pull/7813

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v3]

[Alisen Chung]

> msg drop for jdk19, Mar 9, 2022

Alisen Chung has updated the pull request incrementally with one additional 
commit since the last revision:

  removed repeated lines from ROOT bundle in CurrencyNames

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7765/files
  - new: https://git.openjdk.java.net/jdk/pull/7765/files/4735722d..d5c9b884

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7765=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7765=01-02

  Stats: 675 lines in 3 files changed: 0 ins; 675 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

PR: https://git.openjdk.java.net/jdk/pull/7765

Re: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v15]

[Roger Riggs]

On Wed, 9 Mar 2022 23:59:32 GMT, Claes Redestad  wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace 
>> `StringCoding.hasNegatives` with `countPositives`. The new method does a 
>> very similar pass, but alters the intrinsic to return the number of leading 
>> bytes in the `byte[]` range which only has positive bytes. This allows for 
>> dealing much more efficiently with those `byte[]`s that has a ASCII prefix, 
>> with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: 
>> https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations 
>> of `countPositives` can be implemented with similar efficiency on all 
>> platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) 
>> before moving ahead. This pretty much means holding up this until it's 
>> implemented on all platforms, which can either contributed to this PR or as 
>> dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow 
>> the implementation of `StringCoding.hasNegatives` and `countPositives` to be 
>> implemented so that the non-intrinsified method calls into the intrinsified. 
>> This requires structuring the implementations differently based on which 
>> intrinsic - if any - is actually implemented. One way to do this could be to 
>> mimic how `java.nio` handles unaligned accesses and expose which intrinsic 
>> is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on 
>> `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, 
>> for example `encode-/decodeShortMixed` even see a minor improvement, which 
>> makes me consider those corner case regressions with little real world 
>> implications (if you have latin1 Strings, you're likely to also have 
>> ASCII-only strings in your mix).
>
> Claes Redestad has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix copyright year in new test

core libs String.java changes look fine.

-

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7231

Re: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255

[Vicente Romero]

On Mon, 14 Mar 2022 19:56:17 GMT, Joe Darcy  wrote:

> Improving the exception messages for out-of-supported-range array types.
> 
> I'll update copyrights before pushing.

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 186:

> 184: if (rank <= 0 || netRank > 
> ConstantUtils.MAX_ARRAY_TYPE_DESC_DIMENSIONS)
> 185: throw new IllegalArgumentException("rank: " + netRank +
> 186:" exceeds maximum 
> supported dimension of " +

if the `rank < 0` it won't be exceeding the maximum supported dimensions so 
this message only applies to the second condition

-

PR: https://git.openjdk.java.net/jdk/pull/7812

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]

[Valerie Peng]

> It's been several years since we increased the default key sizes. Before 
> shifting to PQC, NSA replaced its Suite B cryptography recommendations with 
> the Commercial National Security Algorithm Suite which suggests:
> 
> - SHA-384 for secure hashing
> - AES-256 for symmetric encryption
> - RSA with 3072 bit keys for digital signatures and for key exchange
> - Diffie Hellman (DH) with 3072 bit keys for key exchange
> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures 
> (ECDSA)
> 
> So, this proposed changes made the suggested key size and algorithm changes. 
> The changes are mostly in keytool, jarsigner and their regression tests, so 
> @wangweij Could you please take a look?
> 
> Thanks!

Valerie Peng has updated the pull request incrementally with one additional 
commit since the last revision:

  Update again and undo DSA changes

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7652/files
  - new: https://git.openjdk.java.net/jdk/pull/7652/files/f728aa7d..48f562ab

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=03-04

  Stats: 45 lines in 9 files changed: 8 ins; 2 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7652.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652

PR: https://git.openjdk.java.net/jdk/pull/7652

RFR: JDK-8283075: Bad `IllegalArgumentException` message when calling `ClassDesc.arrayType(int)` which results in a rank > 255

[Joe Darcy]

Improving the exception messages for out-of-supported-range array types.

I'll update copyrights before pushing.

-

Commit messages:
 - Appease jcheck
 - Update @bug line of test
 - JDK-8283075: Bad `IllegalArgumentException` message when calling 
`ClassDesc.arrayType(int)` which results in a rank > 255

Changes: https://git.openjdk.java.net/jdk/pull/7812/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7812=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283075
  Stats: 29 lines in 2 files changed: 24 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7812.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7812/head:pull/7812

PR: https://git.openjdk.java.net/jdk/pull/7812

Re: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v15]

[Claes Redestad]

On Wed, 9 Mar 2022 23:59:32 GMT, Claes Redestad  wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace 
>> `StringCoding.hasNegatives` with `countPositives`. The new method does a 
>> very similar pass, but alters the intrinsic to return the number of leading 
>> bytes in the `byte[]` range which only has positive bytes. This allows for 
>> dealing much more efficiently with those `byte[]`s that has a ASCII prefix, 
>> with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: 
>> https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations 
>> of `countPositives` can be implemented with similar efficiency on all 
>> platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) 
>> before moving ahead. This pretty much means holding up this until it's 
>> implemented on all platforms, which can either contributed to this PR or as 
>> dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow 
>> the implementation of `StringCoding.hasNegatives` and `countPositives` to be 
>> implemented so that the non-intrinsified method calls into the intrinsified. 
>> This requires structuring the implementations differently based on which 
>> intrinsic - if any - is actually implemented. One way to do this could be to 
>> mimic how `java.nio` handles unaligned accesses and expose which intrinsic 
>> is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on 
>> `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, 
>> for example `encode-/decodeShortMixed` even see a minor improvement, which 
>> makes me consider those corner case regressions with little real world 
>> implications (if you have latin1 Strings, you're likely to also have 
>> ASCII-only strings in your mix).
>
> Claes Redestad has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix copyright year in new test

Gentle reminder that I need a review of the aarch64 changes.

-

PR: https://git.openjdk.java.net/jdk/pull/7231

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v12]

[iaroslavski]

> Sorting:
> 
> - adopt radix sort for sequential and parallel sorts on int/long/float/double 
> arrays (almost random and length > 6K)
> - fix tryMergeRuns() to better handle case when the last run is a single 
> element
> - minor javadoc and comment changes
> 
> Testing:
> - add new data inputs in tests for sorting
> - add min/max/infinity values to float/double testing
> - add tests for radix sort

iaroslavski has updated the pull request incrementally with one additional 
commit since the last revision:

  JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
  
  * Improved mixed insertion sort
  * Optimized insertion sort
  * Improved merging sort
  * Optimized soring tests

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3938/files
  - new: https://git.openjdk.java.net/jdk/pull/3938/files/95f15386..8a373741

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3938=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3938=10-11

  Stats: 2935 lines in 3 files changed: 1092 ins; 1401 del; 442 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3938/head:pull/3938

PR: https://git.openjdk.java.net/jdk/pull/3938

Integrated: 8283049: Fix non-singleton LoggerFinder error message: s/on/one

[Carter Kozak]

On Thu, 10 Mar 2022 22:28:14 GMT, Carter Kozak  wrote:

> 8283049: Fix non-singleton LoggerFinder error message: s/on/one

This pull request has now been integrated.

Changeset: 70bd57ed
Author:Carter Kozak 
Committer: Daniel Fuchs 
URL:   
https://git.openjdk.java.net/jdk/commit/70bd57ed3544cdb41029d425507ba4b9b35c8cdb
Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8283049: Fix non-singleton LoggerFinder error message: s/on/one

Reviewed-by: dfuchs

-

PR: https://git.openjdk.java.net/jdk/pull/7780

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]

[Alexander Zuev]

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung  wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

Marked as reviewed by kizune (Reviewer).

Clientlibs related stuff looks correct.

-

PR: https://git.openjdk.java.net/jdk/pull/7765

Re: RFR: 8283049: Fix non-singleton LoggerFinder error message: s/on/one [v2]

[Daniel Fuchs]

On Fri, 11 Mar 2022 19:18:55 GMT, Carter Kozak  wrote:

>> 8283049: Fix non-singleton LoggerFinder error message: s/on/one
>
> Carter Kozak has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Add 8283049 to LoggerFinderLoaderTest @bug docs

Marked as reviewed by dfuchs (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7780

Re: Behavior change in the jar tool JDK11 vs JDK8.

[Alan Bateman]

On 14/03/2022 11:48, Pasam Soujanya1 wrote:

There is a significant difference in the way the JAR tool (starting JDK11) 
seems to be responding to target files that are not present , when compared to 
JDK8. With JDK 8, the jar tool just reports about target files that are absent, 
and creates the jar file with whatever targets are available.

With JDK8, If I try to create a jar file with one existing file and another 
invalid file name I can see achieve getting created with the file that exists. 
Only the warning seems to be printed for the target that doesn't exists:
Can you check the exit code (echo $?)? There was a bug in JDK 8/older 
releases with it leaving the temporary file behind when exiting with an 
error, I suspect this is what you are seeing. This changed in JDK 9 to 
cleanup when exiting with an error.


-Alan.

Re: Behavior change in the jar tool JDK11 vs JDK8.

[Remi Forax]

- Original Message -
> From: "Pasam Soujanya1" 
> To: "core-libs-dev" 
> Sent: Monday, March 14, 2022 12:48:42 PM
> Subject: Behavior change in the jar tool JDK11 vs JDK8.

> There is a significant difference in the way the JAR tool (starting JDK11) 
> seems
> to be responding to target files that are not present , when compared to JDK8.
> With JDK 8, the jar tool just reports about target files that are absent, and
> creates the jar file with whatever targets are available.
> 
> With JDK8, If I try to create a jar file with one existing file and another
> invalid file name I can see achieve getting created with the file that exists.
> Only the warning seems to be printed for the target that doesn't exists:
> 
> $ jar -cvf sample.jar exists.txt does_not_exist.txt
> does_not_exist.txt : no such file or directory
> added manifest
> adding: exists.txt(in = 0) (out= 0)(stored 0%)
> 
> From JDK11 onward upto the latest, though I can see the same verbose output 
> the
> jar file(sample.jar) is not created.
> 
> Looking at the code, the targets that do exist are written to a temporary JAR
> file, but the following "validation" code, which runs once the tool has
> finished writing the temporary JAR file, only moves/renames the temporary file
> to the specified JAR location if "ok" is true. If "ok" is false the temporary
> file is simply deleted:
> https://github.com/openjdk/jdk11u/blob/22186cb1fe22b4b30fc72c67ce9946cd4f03199d/src/jdk.jartool/share/classes/sun/tools/jar/Main.java#L451
> 
> Is this behavior change intentional? I couldn't find anything documented in
> release notes of JDK 9,10,11. If not intentional, can someone help me create
> bug report on OpenJDK jira? Thank you.

I believe it's a bugfix, since the creation of the command "jar", jar follows 
the semantics of "tar", so the behavior you are seeing now is the correct one.
But i was not able to pinpoint the bug corresponding to that issue.

> 
> Regards,
> Pasam Soujanya.

regards,
Rémi

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]

[Alisen Chung]

On Thu, 10 Mar 2022 18:56:41 GMT, Chris Plummer  wrote:

>> Alisen Chung has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   moved CurrencyNames changes to jdk.localedata
>
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java
>  line 305:
> 
>> 303: {"Thread not suspended", 
>> "\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u3066\u3044\u307E\u305B\u3093"},
>> 304: {"thread group number description name", "{0,number,integer}. 
>> {1} {2}"},
>> 305: {"Threadgroup name not specified.", 
>> "\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u540D\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u307E\u305B\u3093\u3002"},
> 
> I'm not sure what happened here. This resource was just removed yesterday as 
> part of #7687. It had been around for a long time before that (probably from 
> the beginning of this file), so I'm not sure what triggered getting it 
> re-added.

The translation was started before the updates to this file. This update can be 
done in the next msg drop.

-

PR: https://git.openjdk.java.net/jdk/pull/7765

Re: RFR: 8282407: Missing ')' in MacResources.properties

[Naoto Sato]

On Sat, 12 Mar 2022 03:12:30 GMT, Alexander Matveev  
wrote:

> - Fixed by adding missing ']'.
>  - I changed '()' to '[]', since other error messages use '[]' and not '()'.

It is OK as it stands, but usually localized files are provided by the l10n 
process, so engineers only need to modify the base resource bundle.

-

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7797

Integrated: 8282929: Localized monetary symbols are not reflected in `toLocalizedPattern` return value

[Naoto Sato]

On Fri, 11 Mar 2022 19:53:20 GMT, Naoto Sato  wrote:

> `DecimalFormat.toLocalizedPattern()` was not honoring the monetary 
> decimal/grouping separator symbols. Fix is straightforward to use the correct 
> symbols depending on the formatter type.

This pull request has now been integrated.

Changeset: c96085ea
Author:Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/c96085eaab1f6b21e084b94fcc619d090f0afc97
Stats: 68 lines in 2 files changed: 63 ins; 0 del; 5 mod

8282929: Localized monetary symbols are not reflected in `toLocalizedPattern` 
return value

Reviewed-by: joehw, lancea

-

PR: https://git.openjdk.java.net/jdk/pull/7790

Behavior change in the jar tool JDK11 vs JDK8.

[Pasam Soujanya1]

There is a significant difference in the way the JAR tool (starting JDK11) 
seems to be responding to target files that are not present , when compared to 
JDK8. With JDK 8, the jar tool just reports about target files that are absent, 
and creates the jar file with whatever targets are available.

With JDK8, If I try to create a jar file with one existing file and another 
invalid file name I can see achieve getting created with the file that exists. 
Only the warning seems to be printed for the target that doesn't exists:

$ jar -cvf sample.jar exists.txt does_not_exist.txt   
does_not_exist.txt : no such file or directory
added manifest
adding: exists.txt(in = 0) (out= 0)(stored 0%)

>From JDK11 onward upto the latest, though I can see the same verbose output 
>the jar file(sample.jar) is not created.

Looking at the code, the targets that do exist are written to a temporary JAR 
file, but the following "validation" code, which runs once the tool has 
finished writing the temporary JAR file, only moves/renames the temporary file 
to the specified JAR location if "ok" is true. If "ok" is false the temporary 
file is simply deleted:
https://github.com/openjdk/jdk11u/blob/22186cb1fe22b4b30fc72c67ce9946cd4f03199d/src/jdk.jartool/share/classes/sun/tools/jar/Main.java#L451

Is this behavior change intentional? I couldn't find anything documented in 
release notes of JDK 9,10,11. If not intentional, can someone help me create 
bug report on OpenJDK jira? Thank you.

Regards,
Pasam Soujanya.

Re: RFR: 8283067: Incorrect comment in java.base/share/classes/java/util/ArrayList.java

[Stuart Marks]

On Sat, 12 Mar 2022 09:48:14 GMT, xpbob  wrote:

> * Constructs an empty list with an initial capacity of ten
> 
> =>
> 
> * Constructs an empty list with default sized empty instances.
> 
> 
>   private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {};
> 
> DEFAULTCAPACITY_EMPTY_ELEMENTDATA is empty and the length is 0

Closed as duplicate of 
[JDK-8143020](https://bugs.openjdk.java.net/browse/JDK-8143020).

-

PR: https://git.openjdk.java.net/jdk/pull/7799

Integrated: 8058924: FileReader(String) documentation is insufficient

[Brian Burkhalter]

On Thu, 10 Mar 2022 02:30:35 GMT, Brian Burkhalter  wrote:

> Add a statement to the `java.io` package documentation clarifying how a 
> `String` representing a _pathname string_ is interpreted in the package.

This pull request has now been integrated.

Changeset: 13cebffe
Author:Brian Burkhalter 
URL:   
https://git.openjdk.java.net/jdk/commit/13cebffe618255ae29310c95fd1b91576e576751
Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8058924: FileReader(String) documentation is insufficient

Reviewed-by: naoto, lancea

-

PR: https://git.openjdk.java.net/jdk/pull/7767

Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v6]

[Raffaello Giulietti]

On Tue, 8 Feb 2022 22:11:34 GMT, Raffaello Giulietti  
wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 
>> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was 
>> a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about 
>> multi-line (block) comments. Nothing in the code proper has changed, except 
>> for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request with a new target base due 
> to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>
>Adapted hashes in ElementStructureTest.java
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>
>Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>
>Enhanced intervals in MathUtils.
>Updated references to Schubfach v4.
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>
>Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>
>Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) 
> comments.
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>
>Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>
>Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>
>Refactored test classes to better match OpenJDK conventions.
>Added tests recommended by Guy Steele and Paul Zimmermann.
>  - Changed MAX_CHARS to static
>  - ... and 2 more: 
> https://git.openjdk.java.net/jdk/compare/92f4f40d...c29dff76

Hi Suminda,

before merging, an OpenJDK PR needs to be properly reviewed by 
officially nominated reviewers other than the author of a PR.

In addition, this PR also needs a CSR approval because the proposed spec 
has changed.

As you can see on the top of the PR, neither of these two prerequisites 
for merging are checked as of today.


Greetings
Raffaello

On 3/10/22 07:37, Suminda Sirinath Salpitikorala Dharmasena wrote:
>
> Why is this still not merged?
>
> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> Triage notifications on the go with GitHub Mobile for iOS 
> 
>  
> or Android 
> .
>  
>
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

-

PR: https://git.openjdk.java.net/jdk/pull/3402

Re: RFR: 8279508: Auto-vectorize Math.round API [v15]

[Jatin Bhateja]

On Mon, 14 Mar 2022 09:29:28 GMT, Andrew Haley  wrote:

>> Good suggestion, but as of now we are not using vector calling conventions 
>> for stubs.
>
> I don't understand this comment. If the stub is only to be used by you, then 
> you can determine your own calling convention.

We are passing mixture of scalar, vector and opmask register to special 
handling function, only way we can pass them reliably to callee stub without 
having an elaborate mixed calling convention will be by bounding the machine 
operands.

-

PR: https://git.openjdk.java.net/jdk/pull/7094

Re: RFR: 8279508: Auto-vectorize Math.round API [v17]

[Tobias Hartmann]

On Sun, 13 Mar 2022 06:36:15 GMT, Jatin Bhateja  wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar 
>> IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain 
>> ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 
>> 510.36 | 548.39 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 
>> 293.48 | 274.01 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 
>> 751.83 | 2274.13 | 3.02
>> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 
>> 388.52 | 1334.18 | 3.43
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   8279508: Windows build failure fix.

`compiler/c2/cr6340864/TestFloatVect.java` and `TestDoubleVect.java` fail on 
Windows:


# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x01971b940123, pid=56524, 
tid=57368
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 
19-internal-2022-03-14-0834080.tobias.hartmann.jdk2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 
19-internal-2022-03-14-0834080.tobias.hartmann.jdk2, mixed mode, sharing, 
tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# J 205 c2 compiler.c2.cr6340864.TestFloatVect.test_round([I[F)V (24 bytes) @ 
0x01971b940123 [0x01971b93ffe0+0x0143]

-

PR: https://git.openjdk.java.net/jdk/pull/7094

Re: Questions about enhancement and Correction to Java OpenJDK Floating Point?

[Raffaello Giulietti]

Hi Terry,

as pointed out by Martin, the real issue is using *binary* 
floating-point arithmetic, like float or double, to emulate *decimal* 
arithmetic.


When you write 0.1D in Java, C or C++, what happens is that this decimal 
number is rounded to the double closest to the mathematical value 1/10. 
There's no double that is exactly 1/10, so you start with a value that 
is already rounded and inexact. Multiplication rounds as well, so you 
end up with a value that was subject to 3 roundings: twice for the 
conversion of the two openads from 0.1D to the closest doubles and once 
for the multiplication. The result is slightly different than the 
naively "expected" 0.01D, which is subject to one rounding only during 
conversion to the closest double. In other words, 0.1D*0.1D != 0.01D, 
even in C/C++ and most programming languages/environments.


In Java, however, when you convert a double to a decimal string by means 
of System.out.print[ln](), the library outputs just as many digits as 
necessary, and no less, for an input routine to be able to recover the 
original double. C and C++ do *not* ensure this. In Java, 0.01D (1 
rounding) is correctly converted to "0.01" while 0.1D*0.1D (3 roundings) 
is correctly converted to "0.010002".


In C/C++, try to output both 0.1D*0.1D and 0.01D with 20 digits, say, 
instead of the default 6 and you'll see a difference.


As observed by Rémi, Java offers formatting similar to C/C++ if that is 
what you want.


To summarize, Java uses IEEE 754 binary arithmetic as by specification, 
as do most other languages, including C/C++. It is however fundamentally 
wrong to use binary floating-point arithmetic to emulate decimal 
behavior. Also, pay attention to the output routines that convert float 
and double values to a decimal representation. Usually, C and C++ will 
have information loss by default, as in your case.



HTH
Raffaello


On 3/14/22 07:49, A Z wrote:

To whom it may concern,

Having noticed

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190947
https://bugs.openjdk.java.net/browse/JDK-8190991

and similar, at 
https://community.oracle.com/tech/developers/discussion/4126262/big-issue-with-float-double-java-floating-point

I have been referred on to the core-libs-dev area.

The software development company I represent wishes to keep its name 
confidential,
and no-mentioned, at this time.

A number of us at our end have found that floating point and StrictMath 
arithmetic
on both float and double does not result in range accuracy, but produces 
denormal
and pronormal values.

We are aware of the Java Language Specification, and IEEE 754 specifications,
to these issues, but are still finding that they are not the most relevant or 
great issue.

While we are aware of the BigDecimal and BigInteger workarounds, and
furthermore, the calculator class including big-math  
https://github.com/eobermuhlner,
we are finding in the development, debugging, and editing of our Java programs,
that using other classes to operate and exchange for the lack of range accuracy 
from float,
double and java.lang.StrictMath, that we are getting bogged down with what 
turns into
more inferior software.  The known and available workaround approaches are 
becoming
stop-gap measures, perforcedly put in place, while introducing other problems
into OpenJDK or Java software that don't have any particular, immediate, 
solutions.

Substituting float and double data in and out of BigDecimal and BigInteger 
produces
source code which is much messier, complicated, error prone, difficult to 
understand
and to change, is definitely slower, and is an inferior substitute when float
and double are more than enough in the overwhelming majority of corresponding 
cases.
This is particularly showing up in 2D and 3D Graphics software, by the default
OpenJDK Libraries, but also through JMonkeyEngine 3.5.

Possessing the option to immediately deal with the precondition, postcondition
and field types of float and double is far superior and more than ideal.
All this is before the massive advantage of being able to use operators,
but the change case becomes overwhelming when along a range accurate,
double (or maybe float, also) supporting Scientific Calculator class.

If I want to discuss (at least OpenJDK) change in this area, I have
been pointed to the core-libs area, by one of the respondents
of the article:

https://community.oracle.com/tech/developers/discussion/4126262/big-issue-with-float-double-java-floating-point.

Is there anyone here, at core-libs-dev, who can point
me in a better Oracle or OpenJDK direction, to discuss further
and see about Java float and double and StrictMath floating point
arithmetic denormal and pronormal values being repaired away
and being made range accurate for all evaluation operations
with them?

Certainly since other languages already have, that are open source
and open resource file ones.  It is a mathematical fact that, for
consistent, necessary and 

Re: RFR: 8279508: Auto-vectorize Math.round API [v15]

[Andrew Haley]

On Sun, 13 Mar 2022 04:27:25 GMT, Jatin Bhateja  wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4024:
>> 
>>> 4022:  * the result is equal to the value of Integer.MAX_VALUE.
>>> 4023:  */
>>> 4024: void 
>>> C2_MacroAssembler::vector_cast_float_special_cases_avx(XMMRegister dst, 
>>> XMMRegister src, XMMRegister xtmp1,
>> 
>> This special handling is really large, could we use a stub routine for it?
>
> Good suggestion, but as of now we are not using vector calling conventions 
> for stubs.

I don't understand this comment. If the stub is only to be used by you, then 
you can determine your own calling convention.

-

PR: https://git.openjdk.java.net/jdk/pull/7094

Re: Questions about enhancement and Correction to Java OpenJDK Floating Point?

[Martin Desruisseaux]

Hello A.Z

As far as I know, the difference in output that you observed between 
Java and C/C++ is not caused by a difference in floating-point 
computation, but in a difference in the way numbers are rounded by the 
"printf" command. Java has a policy of showing all significant digits, 
while C "printf" has a policy of rounding before printing. In my 
opinion, this is more dangerous because it hides what really happen in 
floating-point computation.


The following statement is not entirely true when using finite floating 
point precision:



(…snip…) It is a mathematical fact that, for
consistent, necessary and even fast term, 10% of 10% must
always precisely be 1%, and by no means anything else.


Above statement can be true only when using base 10 or some other bases. 
We could also said "It is a mathematical fact that 1/3 of 1/3 must 
always precisely be 1/9 and nothing else", but it can not be represented 
fully accurately with base 10. It can be represented fully accurately 
with base 3 however. There will always be examples that work in one base 
and not in another, and natural laws has no preference for base 10. I 
understand that base 10 is special for financial applications, but for 
many other applications (scientific, engineering, rendering…) base 2 is 
as good as any other base. I would even argue that base 10 can be 
dangerous because it gives a false sense of accuracy: it gives the 
illusion that rounding errors do not happen when testing with a few 
sample values in base 10 (like 10% of 10%), while in reality rounding 
errors continue to exist in the general case.


    Martin

Re: Questions about enhancement and Correction to Java OpenJDK Floating Point?

[Remi Forax]

- Original Message -
> From: "A Z" 
> To: "core-libs-dev" 
> Sent: Monday, March 14, 2022 7:49:04 AM
> Subject: Questions about enhancement and Correction to Java OpenJDK Floating 
> Point?

Hi Terry,
if you want to have the same output as C, instead of println() use printf().

In your example, using
  out.printf("%f\n", c);

prints
  0.01

  0.01

regards,
Rémi

> To whom it may concern,
> 
> Having noticed
> 
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190947
> https://bugs.openjdk.java.net/browse/JDK-8190991
> 
> and similar, at
> https://community.oracle.com/tech/developers/discussion/4126262/big-issue-with-float-double-java-floating-point
> 
> I have been referred on to the core-libs-dev area.
> 
> The software development company I represent wishes to keep its name
> confidential,
> and no-mentioned, at this time.
> 
> A number of us at our end have found that floating point and StrictMath
> arithmetic
> on both float and double does not result in range accuracy, but produces
> denormal
> and pronormal values.
> 
> We are aware of the Java Language Specification, and IEEE 754 specifications,
> to these issues, but are still finding that they are not the most relevant or
> great issue.
> 
> While we are aware of the BigDecimal and BigInteger workarounds, and
> furthermore, the calculator class including big-math
> https://github.com/eobermuhlner,
> we are finding in the development, debugging, and editing of our Java 
> programs,
> that using other classes to operate and exchange for the lack of range 
> accuracy
> from float,
> double and java.lang.StrictMath, that we are getting bogged down with what 
> turns
> into
> more inferior software.  The known and available workaround approaches are
> becoming
> stop-gap measures, perforcedly put in place, while introducing other problems
> into OpenJDK or Java software that don't have any particular, immediate,
> solutions.
> 
> Substituting float and double data in and out of BigDecimal and BigInteger
> produces
> source code which is much messier, complicated, error prone, difficult to
> understand
> and to change, is definitely slower, and is an inferior substitute when float
> and double are more than enough in the overwhelming majority of corresponding
> cases.
> This is particularly showing up in 2D and 3D Graphics software, by the default
> OpenJDK Libraries, but also through JMonkeyEngine 3.5.
> 
> Possessing the option to immediately deal with the precondition, postcondition
> and field types of float and double is far superior and more than ideal.
> All this is before the massive advantage of being able to use operators,
> but the change case becomes overwhelming when along a range accurate,
> double (or maybe float, also) supporting Scientific Calculator class.
> 
> If I want to discuss (at least OpenJDK) change in this area, I have
> been pointed to the core-libs area, by one of the respondents
> of the article:
> 
> https://community.oracle.com/tech/developers/discussion/4126262/big-issue-with-float-double-java-floating-point.
> 
> Is there anyone here, at core-libs-dev, who can point
> me in a better Oracle or OpenJDK direction, to discuss further
> and see about Java float and double and StrictMath floating point
> arithmetic denormal and pronormal values being repaired away
> and being made range accurate for all evaluation operations
> with them?
> 
> Certainly since other languages already have, that are open source
> and open resource file ones.  It is a mathematical fact that, for
> consistent, necessary and even fast term, 10% of 10% must
> always precisely be 1%, and by no means anything else.
> 
> Consider these three different language API evaluations,
> using their equivalents of float and double to perform
> the floating point equivalent of that precise evaluation:
> 
> //--
> //The C Language.
> #include 
> 
> int main()
> {
>printf("Program has started...");
>printf("\n");
>printf("\n");
>double a = 0.1D;
>double b = 0.1D;
>double c = a*b;
>printf("%lf",c);
>printf("\n");
>printf("\n");
>float d = 0.1F;
>float e = 0.1F;
>float f = d*e;
>printf("%lf",f);
>printf("\n");
>printf("\n");
>printf("Program has Finished.");
>return 0;
> }
> 
> /*
> Program has started...
> 
> 0.01
> 
> 0.01
> 
> Program has Finished.
> */
> //--
> //The C++ Language.
> 
> #include 
> 
> using namespace std;
> 
> int main()
> {
>cout << "Program has started..." << endl;
>double a = 0.1D;
>double b = 0.1D;
>double c = a*b;
>cout << endl << c << endl << endl;
>float d = 0.1F;
>float e = 0.1F;
>float f = d*e;
>cout << f << endl << endl;
>cout << "Program has Finished.";
>return 0;
> }
> 
> /*
> Program has started...
> 
> 0.01
> 
> 0.01
> 
> Program has Finished.
> */
> 
> 

Questions about enhancement and Correction to Java OpenJDK Floating Point?

[A Z]

To whom it may concern,

Having noticed

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190947
https://bugs.openjdk.java.net/browse/JDK-8190991

and similar, at 
https://community.oracle.com/tech/developers/discussion/4126262/big-issue-with-float-double-java-floating-point

I have been referred on to the core-libs-dev area.

The software development company I represent wishes to keep its name 
confidential,
and no-mentioned, at this time.

A number of us at our end have found that floating point and StrictMath 
arithmetic
on both float and double does not result in range accuracy, but produces 
denormal
and pronormal values.

We are aware of the Java Language Specification, and IEEE 754 specifications,
to these issues, but are still finding that they are not the most relevant or 
great issue.

While we are aware of the BigDecimal and BigInteger workarounds, and
furthermore, the calculator class including big-math  
https://github.com/eobermuhlner,
we are finding in the development, debugging, and editing of our Java programs,
that using other classes to operate and exchange for the lack of range accuracy 
from float,
double and java.lang.StrictMath, that we are getting bogged down with what 
turns into
more inferior software.  The known and available workaround approaches are 
becoming
stop-gap measures, perforcedly put in place, while introducing other problems
into OpenJDK or Java software that don't have any particular, immediate, 
solutions.

Substituting float and double data in and out of BigDecimal and BigInteger 
produces
source code which is much messier, complicated, error prone, difficult to 
understand
and to change, is definitely slower, and is an inferior substitute when float
and double are more than enough in the overwhelming majority of corresponding 
cases.
This is particularly showing up in 2D and 3D Graphics software, by the default
OpenJDK Libraries, but also through JMonkeyEngine 3.5.

Possessing the option to immediately deal with the precondition, postcondition
and field types of float and double is far superior and more than ideal.
All this is before the massive advantage of being able to use operators,
but the change case becomes overwhelming when along a range accurate,
double (or maybe float, also) supporting Scientific Calculator class.

If I want to discuss (at least OpenJDK) change in this area, I have
been pointed to the core-libs area, by one of the respondents
of the article:

https://community.oracle.com/tech/developers/discussion/4126262/big-issue-with-float-double-java-floating-point.

Is there anyone here, at core-libs-dev, who can point
me in a better Oracle or OpenJDK direction, to discuss further
and see about Java float and double and StrictMath floating point
arithmetic denormal and pronormal values being repaired away
and being made range accurate for all evaluation operations
with them?

Certainly since other languages already have, that are open source
and open resource file ones.  It is a mathematical fact that, for
consistent, necessary and even fast term, 10% of 10% must
always precisely be 1%, and by no means anything else.

Consider these three different language API evaluations,
using their equivalents of float and double to perform
the floating point equivalent of that precise evaluation:

//--
//The C Language.
#include 

int main()
{
printf("Program has started...");
printf("\n");
printf("\n");
double a = 0.1D;
double b = 0.1D;
double c = a*b;
printf("%lf",c);
printf("\n");
printf("\n");
float d = 0.1F;
float e = 0.1F;
float f = d*e;
printf("%lf",f);
printf("\n");
printf("\n");
printf("Program has Finished.");
return 0;
}

/*
Program has started...

0.01

0.01

Program has Finished.
*/
//--
//The C++ Language.

#include 

using namespace std;

int main()
{
cout << "Program has started..." << endl;
double a = 0.1D;
double b = 0.1D;
double c = a*b;
cout << endl << c << endl << endl;
float d = 0.1F;
float e = 0.1F;
float f = d*e;
cout << f << endl << endl;
cout << "Program has Finished.";
return 0;
}

/*
Program has started...

0.01

0.01

Program has Finished.
*/

//--
//The Java Language.

import static java.lang.System.*;
public class Start
{
public static void main(String ... args)
{
out.println("Program has started...");
double a = 0.1D;
double b = 0.1D;
double c = a*b;
out.println();
out.println(c);
float d = 0.1F;
float e = 0.1F;
float f = d*e;
out.println();
out.println(f);   out.println();
out.println("Program has Finished.");
}}

/*
Program has started...

0.010002

0.01001

Program has Finished..
*/
//--

In order for java