# EL operations are 'double' based

Niranjan Deshpande

Ranch Hand

Posts: 1277

posted 10 years ago

Of the five JSP page source extracts below, there are two pairs. Each member of the pair gives rise to identical output. Which is the odd one out? (Choose one.)

A.

<% int i, j, k;

i = 1; j = 2; k = 3; %>

<%= i + j / k %>

B.

<jsp:scriptlet>int i, j, k;

i = 1; j = 2; k = 3;</jsp:scriptlet>

<jsp:expression>(i + j) / k</jsp:expression>

C.

<% int i, j, k;

i = 1; j = 2; k = 3; %>

<%= (i + j) / k + ".0" %>

D.

<% pageContext.setAttribute("i", new Integer(1));

pageContext.setAttribute("j", new Integer(2));

pageContext.setAttribute("k", new Integer(3));

%>${pageScope.i + pageScope.j / pageScope.k}

E.

<% pageContext.setAttribute("i", new Integer(1));

pageContext.setAttribute("j", new Integer(2));

pageContext.setAttribute("k", new Integer(3));

%>${(pageScope.i + pageScope.j) / pageScope.k}

when i read this question, D and E boglled me , as i couldnt understand g\how can EL divide to 'Integers' ( unboxing is a feature of jdk1.5 )

but thei read this explanation. Concentrate on the bold parts -

D is the correct answer. This is not an easy question! The output is 1.6666666666666665 from this piece of code, and none of the other JSP fragments give that result. Owing to precedence rules, the division in the expression (2/3) is done first.

A, B, C, and E are incorrect answers, for all pair up: A and B produce identical output, and so do C and E. A and B both output 1, for different reasons. In A, precedence dictates that the division is done fi rst. This is Java language division, so the result of 2/3 is 0. Adding this to

1 therefore gives 1. The parentheses force a different calculation in B: (1 + 2)/3. The result of this is also 1. C and E both output 1.0. C does the same calculation �(1 + 2)/3. This is then concatenated with �.0� to give an end result of 1.0.

In E the EL expression performs effectively the same calculation, derived from the Integer page attributes: (1 + 2)/3. However,

still my concern is how does EL manage to divide tow 'Integers' without unwrapping them ? also why the hell HFSJ doest tell that

However,

please reply

A.

<% int i, j, k;

i = 1; j = 2; k = 3; %>

<%= i + j / k %>

B.

<jsp:scriptlet>int i, j, k;

i = 1; j = 2; k = 3;</jsp:scriptlet>

<jsp:expression>(i + j) / k</jsp:expression>

C.

<% int i, j, k;

i = 1; j = 2; k = 3; %>

<%= (i + j) / k + ".0" %>

D.

<% pageContext.setAttribute("i", new Integer(1));

pageContext.setAttribute("j", new Integer(2));

pageContext.setAttribute("k", new Integer(3));

%>${pageScope.i + pageScope.j / pageScope.k}

E.

<% pageContext.setAttribute("i", new Integer(1));

pageContext.setAttribute("j", new Integer(2));

pageContext.setAttribute("k", new Integer(3));

%>${(pageScope.i + pageScope.j) / pageScope.k}

when i read this question, D and E boglled me , as i couldnt understand g\how can EL divide to 'Integers' ( unboxing is a feature of jdk1.5 )

but thei read this explanation. Concentrate on the bold parts -

D is the correct answer. This is not an easy question! The output is 1.6666666666666665 from this piece of code, and none of the other JSP fragments give that result. Owing to precedence rules, the division in the expression (2/3) is done first.

**EL division is double-based**(not integer-based), hence the imprecise double answer. This is added to 1, to give the answershown.A, B, C, and E are incorrect answers, for all pair up: A and B produce identical output, and so do C and E. A and B both output 1, for different reasons. In A, precedence dictates that the division is done fi rst. This is Java language division, so the result of 2/3 is 0. Adding this to

1 therefore gives 1. The parentheses force a different calculation in B: (1 + 2)/3. The result of this is also 1. C and E both output 1.0. C does the same calculation �(1 + 2)/3. This is then concatenated with �.0� to give an end result of 1.0.

In E the EL expression performs effectively the same calculation, derived from the Integer page attributes: (1 + 2)/3. However,

**for division,EL arithmetic coerces the operands to Doubles.**The result is a Double literal (in Java terms),expressed with a .0 on the end even though this isn�t required.still my concern is how does EL manage to divide tow 'Integers' without unwrapping them ? also why the hell HFSJ doest tell that

However,

**for division,EL arithmetic coerces the operands to Doubles.**please reply

SCJP 1.4 - 95% [ My Story ] - SCWCD 1.4 - 91% [ My Story ]
*Performance is a compulsion, not a option, if my existence is to be justified.*

Niranjan Deshpande

Ranch Hand

Posts: 1277

posted 10 years ago

i guess, hfsj doest tell this -

1.EL operations are double based.

2.you cannot nest one EL expression inside another.

1.EL operations are double based.

2.you cannot nest one EL expression inside another.

*Performance is a compulsion, not a option, if my existence is to be justified.*