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.EL division is doublebased (not integerbased), 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
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 doublebased (not integerbased), 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.
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.
Happiness is not a goal ... it's a byproduct of a life well lived  Eleanor Roosevelt. Tiny ad:
the new thread boost feature: great for the advertiser and smooth for the coderanch user
https://coderanch.com/t/674455/ThreadBoostfeature
