EL relational operators and empty string ""

Hi,

Preparing for the OCWCD-exam I was figuring out the EL relational operators.
My question is about the EL's interpretation of an empty string ("").

EL-Specs2.1 (1.8.1) and JSP-specs2.0 (2.3.5.5) tell me: A {<,>,<=,>=,lt,gt,le,ge} B
If A or B is String, coerce both A and B to String, compare lexically

Wikipedia tells me: The empty string precedes any other string in the lexicographical order.

Using GlassFish Server Open Source Edition 3 (Java EE 6) and JSTL version 1.1.2,
testing "" with a gt-operator in a JSP-page shows: true

So, if -1 is coerced to whatever-but-not-an-empty-string, and an empty string is preceding any other string, why is ${myAttr gt -1 } producing true?

I know, I could use the empty-operator for recognizing an empty string, but I am just curious how things work.
And it could mean one more correct answer on my exam

Many thanks!

Ok, here is my interpretation on it.

You only quoted part of the EL spec.
Here is the full section 1.8.1 related to comparing two numbers:

1.8.1 A {<,>,<=,>=,lt,gt,le,ge} B
■ If A==B, if operator is <=, le, >=,or ge return true.
■ If A is null or B is null, return false
■ If A or B is BigDecimal, coerce both A and B to BigDecimal and use the return
value of A.compareTo(B).
■ If A or B is Float or Double coerce both A and B to Double apply operator
■ If A or B is BigInteger, coerce both A and B to BigInteger and use the return
value of A.compareTo(B).
■ If A or B is Byte, Short, Character, Integer,or Long coerce both A and B to
Long and apply operator
■ If A or B is String coerce both A and B to String, compare lexically
■ If A is Comparable, then:
■ If A.compareTo(B) throws exception, error.
■ Otherwise use result of A.compareTo(B)
■ If B is Comparable, then:
■ If B.compareTo(A) throws exception, error.
■ Otherwise use result of B.compareTo(A)
■ Otherwise, error

Evaluating this you are meant to start at the top, and find the first one that matches.
You are absolutely right that if it coerced them both to string, and compared lexically, you should get false.
ie "" gt "-1" should be false.

But it doesn't get that far.

"-1" evaluates to a number of some sort. Not exactly sure which, but probably a Long.
So that means the rule to apply is:
If A or B is Byte, Short, Character, Integer,or Long coerce both A and B to Long and apply operator

It then tries to convert empty string to a Number.

According to section 1.18.3 (coercing values to a number), If a value is null or "", it evaluates to 0.

So the expression is evaluated as ${0 gt -1} which is of course, true.

Hi Stefan,

Thanks for your response.

Indeed I quoted just part of the specs, presuming the EL-expression was evaluated left-to-right.
Because of all the "A OR B"-expressions in 1.8.1, there will be indeed a left-AND-right evaluation.

Still, I am confused

The truth, according to EL , is to be found in between -1 and 1, but not at 0.

Once again, Wikipedia to the rescue, I found:
"The empty string is a syntactically valid representation of zero in positional notation (in any base), which does not contain leading zeros."

So maybe there are different representations of zero after coercion to Long?
Now I feel Iike I am really starting to float….

Greetz
Bert

PS. it seems my link in preview-mode of this message doesn't find the page, please google on "wiki empty string"