Different behaviour of JavaScript step on boolean variables depending on source

[gmitter-ef]

Apache Hop version?

2.3

Java version?

OpenJDK 11

Operating system

Windows 10

What happened?

Look at the attached pipeline.

Problem 1:

when a Boolean stream field is passed to "Modified JavaScript value" step, the comparison for "true" only seems to be done correctly using "== true", but not using the bool variable itself. See 1.a).
(1.b) is a result of 1.a) and can be ignored at first I think)

When the bool is a JavaScript variable from the beginning (created via "var"), the condition works in both variants. See also 3).

Problem 2:

The comparison of two Integer stream fields via "!=" directly does not work correctly.
When using Math.ceil on the Integers, however, the comparison works.
Furthermore, it does work correctly when the integers are JavaScript variables from the beginning.

See attached pipeline and notes for exact reproduction and comparison with regard to what would be expected vs. observed output.
test.zip

Issue Priority

Priority: 2

Issue Component

Component: Transforms

[bjackson-ep]

I also had an issue with booleans and comparison operators. Java booleans are not allowed to be null but must take a value, however Hop allows a field to be True, Null, or False, at least in the preview panel. I think what is happening in my case is a null comes in and the comparison fails. Maybe the Javascript step should get a helper function to allow the user to test what state the incoming field is in, especially for nulls.

[gmitter-ef]

Thanks for the comment! Actually, in my case I think I have verified that the stream fields are NOT null, and still the comparisons behave as described.

[gmitter-ef]

For problem2, found out that typeof(...) Javascript operator yields "object" for the integers coming from the stream, but "number" for the integers declared directly in JavaScript.

[gmitter-ef]

Using ".valueOf()" on the variables coming from the stream shows correct (expected) behaviour both the bool problem (1) and the integer comparison (problem 2).
Still the behaviour should not be the way it is without this function call, I believe at least.

[bjackson-ep]

In order to test your findings, we would first test for null, right? Then do the .valueOf() function upon that object, otherwise I think the step will fail with some address. (no functions exist on null). I will try this out. I appreciate having a sounding board.

[mattcasters]

So yes, Hop uses a Java Boolean value to represent these values. The Rhino JavaScript engine understands boolean so using field.valueOf() performs this conversion. I would suggest to add a section on Boolean values in the JavaScript transform documentation.