Bug 622500

Summary: Floats Not Handled By Scripting Engine Properly
Product: Red Hat Enterprise Linux 5 Reporter: harry.kantor
Component: java-1.6.0-openjdkAssignee: Jon VanAlten <jon.vanalten>
Status: CLOSED NOTABUG QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: medium Docs Contact:
Priority: low    
Version: 5.5CC: dbhole
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-13 19:59:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File demonstrating issue with floats being passed. none

Description harry.kantor 2010-08-09 14:36:20 UTC
Created attachment 437614 [details]
File demonstrating issue with floats being passed.

Description of problem:

Float values passed to the ScriptEngine are not handled correctly.  If values are passed as manifest constants they are interpreted correctly.  Double values are handled correctly.

Version-Release number of selected component (if applicable):

java-1.6.0-openjdk-1.6.0.0-1.8.b09

Related components:
jsr223-scripting-engines-js-1.0-0.20080819.1.jpp5
jsr223-scripting-engines-1.0-0.20080819.1.jpp5


Steps to Reproduce:
1. Compile the attached file
2. Update CLASSPATH to include directory of generated .class file
3. java ScriptTest
  
Actual results:

float result = false
double result = true

Expected results:

float result = true
double result = true

Additional info:

I have also tested this against Sun's Java 6 with the same results, so I don't believe it is an issue with the JSR 223 RPMs.

Comment 1 Deepak Bhole 2013-03-11 20:36:31 UTC
Is this still reproducible?

Comment 2 harry.kantor 2013-03-12 14:03:19 UTC
Yes.

Comment 3 Jon VanAlten 2013-03-13 19:59:21 UTC
The issue here is that in Java, float is 32-bit floating point, but in JavaScript, all numbers are 64-bit floating point.

Doubles don't show the same problem, because in Java they are 64-bit floating point.  The precision matches.

You probably know this, but to demonstrate the difference even just on Java side:

public class FloatDemo {
  public static void main(String[] args) {
    System.out.format("f1: %.20f%n", 7.81f);
    System.out.format("f2: %.20f%n", 7.81);
    if (7.81f == 7.81) {
      System.out.println("They are the same.");
    } else {
      System.out.println("They are not the same.");
    }
  }
}

So when adding the Float to script context in your example, it becomes the 64-bit representation of the (32-bit) 7.81f value, which is not the same as the 64-bit 7.81 value.

Strict equality comparisons between numbers that originate from different precision is rarely what you want to do.