Qute: Unexpected primitive equality

[neon-dev]

Describe the bug

This Qute template is rendered as 0 is not 0:

{@long number=0L}
{number} is {#if number == 0}0{#else}not 0{/if}

The same happens when comparing a long returned from a method with an int in a template.
I didn't check for other types.

Expected behavior

Primitive numbers should be compared by their value, not their type.

Actual behavior

== and != fail with primitive numbers of different data types.

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

3.15.2

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @mkouba (qute)

[mkouba]

Hm, I believe that this is a duplicate of #40097.

It works if you change your template to:

{@long number=0L}
{number} is {#if number == 0l}0{#else}not 0{/if}

or even:

{@int number=0}
{number} is {#if number == 0}0{#else}not 0{/if}

[neon-dev]

It works if you change your template to

Sure, but should this be necessary?
In Java 0L == 0 is true, so I'd argue Qute should behave in the same way.
In the example code such an issue is easy to spot, but if we compare some long count returned from a Java method in a Qute template it is no longer so obvious.
For example, this would fail:

{#if stats:count != 0}

while this would work:

{#if stats:count > 0}

[mkouba]

It works if you change your template to

Sure, but should this be necessary?

No, it should not, but it's already covered by #40097. In other words, if we fix #40097 then your template should work too because we should apply the "Widening Primitive Conversion" everywhere. That's why I said it's a duplicate.

For example, this would fail:

{#if stats:count != 0}

while this would work:

{#if stats:count > 0}

Hm, you're right that {#if} is a bit special and we could actually fix the condition easily. For the > operator we convert the values to BigDecimal if the types are not the same. It's not very efficient but we could use the same strategy for == and java.lang.Numbers.

I will try to propose something later today.

[neon-dev]

That's why I said it's a duplicate.

Oh, then there must have been some misunderstanding here: #40097 (comment)