Removed the Doubles. It didn't solve it.
Bit of a long shot in hindsight, as getting different results from Java
based on if I run the test via "mvn test", or via IntelliJ, is still the
red flag.
On Tuesday, 13 May 2025 at 10:12:56 am UTC+10 Craig Mitchell wrote:
> Thanks all. I'm not using DoubleSummaryStatistics or any JNI.
>
> One thing I noticed when I was logging my calcs, trying to compare the
> differences between Java and JavaScript, I would sometimes get -0.0 for a
> double.
>
> Turns out there is a difference between 0.0 and -0.0, but (I think) only
> when using Double, not double (which I have in a few places). Ie:
>
> *In Java:*
> Double a = 0.0;
> Double b = -0.0;
>
> if (a == b) System.out.println("yes");
> else System.out.println("no");
>
> Prints "no".
>
> *While in GWT:*
> Double a = 0.0;
> Double b = -0.0;
>
> if (a == b) GWT.log("yes");
> else GWT.log("no");
>
> Prints "yes".
>
> I'll now remove all "Double"s from my code and see if that fixes it.
> Fingers crossed!
>
> On Tuesday, 13 May 2025 at 5:13:31 am UTC+10 Colin Alworth wrote:
>
>> Any chance you're using any JNI libraries in your JVM implementation? I
>> recently became aware that gcc-compiled libraries with -ffast-math and
>> friends can result in subnormal values doing unexpected things, causing
>> inconsistent/incorrect results for some well defined operations.
>> Unfortunately that flag can cause gcc to emit x86 assembly that makes
>> global changes to how a process interacts with these numbers.
>>
>>
>> https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html
>>
>> It appears that Java 22+ has mitigation for this, by testing in at least
>> some cases if these features have been used and then attempting to restore
>> the expected state for Java:
>>
>> https://github.com/openjdk/jdk/commit/df599dbb9b0f0ee96d1ec767ac8821f164ab075d
>> https://bugs.openjdk.org/browse/JDK-8295159
>>
>> My read is that this is technically incomplete, since it only happens at
>> loadLibrary() time, and technically any call into JNI could re-set these
>> flags.
>> On Monday, May 12, 2025 at 10:50:08 AM UTC-5 Jens wrote:
>>
>>> It is really weird that your results do not match. Prior Java 17 the
>>> "strictfp" keyword could be used to force the JVM to not cheat a little.
>>> But since Java 17 it is the default and the keyword does nothing anymore (
>>> https://openjdk.org/jeps/306). So the results should be portable now.
>>>
>>> In case you are using DoubleSummaryStatistics in your code, GWT
>>> emulation uses Kahan summation to compensate for rounding errors but I
>>> think Java uses the same algorithm. However JavaDoc of
>>> DoubleSummaryStatistics.getSum() leaves room to have different
>>> implementations and error compensations. It explicitly says that the output
>>> may vary for the same input.
>>>
>>> -- J.
>>>
>>> Craig Mitchell schrieb am Montag, 12. Mai 2025 um 15:45:15 UTC+2:
>>>
>>>> The results from GWTTestCase match JavaScript!
>>>>
>>>> It's rather slow though. Running the same test in these envs:
>>>>
>>>> - Java: 184ms.
>>>> - JavaScript (Chrome): 3.5 seconds.
>>>> - GWTTestCase: 5.8 minutes.
>>>>
>>>>
>>>> On Wednesday, 30 April 2025 at 3:39:57 pm UTC+10 Craig Mitchell wrote:
>>>>
>>>>> > *I meant that IntelliJ run configuration for JUnit has an option
>>>>> forkmode and I am pretty sure the maven plugin also has an option for JVM
>>>>> forking. For example you can configure that every test method should run
>>>>> in
>>>>> a forked VM in IntelliJ. By default it doesn't do that. *
>>>>>
>>>>> Ah, cool, thanks. I see that option now.
>>>>>
>>>>> [image: download.png]
>>>>>
>>>>> With it on, I get different results again. Different to maven,
>>>>> different to no fork, and different to JavaScript.
>>>>>
>>>>> And if I run it through Maven with "mvn test -DforkCount=1
>>>>> -DreuseForks=false", I get results that are completely different
>>>>> again.
>>>>>
>>>>> They are still consistent though. Ie: Running it multiple times,
>>>>> always gets the same results.
>>>>>
>>>>> On Tuesday, 29 April 2025 at 8:34:25 pm UTC+10 Jens wrote:
>>>>>
>>>>>> *> Maybe the result slightly changes if JVM decides to optimize a hot
>>>>>> code path in case the JVM is reused. You might want to check how maven
>>>>>> and
>>>>>> your intellij run configuration are configured in terms of JVM forking.*
>>>>>>
>>>>>> IntelliJ seems to add the options:
>>>>>> -Dkotlinx.coroutines.debug.enable.creation.stack.trace=false
>>>>>> -Ddebugger.agent.enable.coroutines=true
>>>>>> -Dkotlinx.coroutines.debug.enable.flows.stack.trace=true
>>>>>> -Dkotlinx.coroutines.debug.enable.mutable.state.flows.stack.trace=true
>>>>>> -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8
>>>>>> -Dsun.stderr.encoding=UTF-8
>>>>>>
>>>>>> So I added those to MAVEN_OPTS, but it didn't seem to make any
>>>>>> difference. I also tried adding @NotThreadSafe to my test suite,
>>>>>> again no difference.
>>>>>>
>>>>>>
>>>>>> I meant that IntelliJ run configuration for JUnit has an option
>>>>>> forkmode and I am pretty sure the maven plugin also has an option for
>>>>>> JVM
>>>>>> forking. For example you can configure that every test method should run
>>>>>> in
>>>>>> a forked VM in IntelliJ. By default it doesn't do that.
>>>>>>
>>>>>> -- J.
>>>>>>
>>>>>
--
You received this message because you are subscribed to the Google Groups "GWT
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/google-web-toolkit/d10c9884-5b79-4b65-8d64-8a6fb5542d02n%40googlegroups.com.
