Konstantin Kolinko wrote:
I've created a patch to clean them:
https://issues.apache.org/bugzilla/attachment.cgi?id=21797
Many thanks.
What is the history of this code before rev. 389146 of 2006-03-27 when
/tomcat/tc6.0.x/trunk was created?
As I recall, the whole EL implementation was provid
Surely, there are irregularities.
There are many places where java.lang.Class instance is not a
parameter to the method, but obtained in place by calling
obj.getClass(). In such cases comparing object's class against
primitive type classes is meaningless.
I've created a patch to clean them:
http
Konstantin Kolinko wrote:
Well, obviously the new code is not equivalent to the old one, because
Long.TYPE and other TYPE constants are the classes for the primitive
types (long, int etc.), and those are not an instance of
java.lang.Number.
Yep my bad. I mis-read what my IDE was telling me. Tha
Well, obviously the new code is not equivalent to the old one, because
Long.TYPE and other TYPE constants are the classes for the primitive
types (long, int etc.), and those are not an instance of
java.lang.Number.
>From the sources:
o.a.el.lang.ELArithmetic.isNumberType()
is used in
o.a.el.la
Author: markt
Date: Tue Apr 8 14:25:04 2008
New Revision: 646076
URL: http://svn.apache.org/viewvc?rev=646076&view=rev
Log:
This fixes 44766 but I can't see why the code was written as originally coded.
Any light much appreciated. I'll give it a couple of days and then, assuming
there are no ob
