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: https://issues.apache.org/bugzilla/attachment.cgi?id=21797 Comparing against primitive types is only meaningful in method isNumberType(Class) of ELArithmetic and several methods in ELSupport, where the Class argument is passed explicitly. What is the history of this code before rev. 389146 of 2006-03-27 when /tomcat/tc6.0.x/trunk was created? 2008/4/9 Mark Thomas <[EMAIL PROTECTED]>: > 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. That explains some of > the original code but not all of it. Any ideas? > > Mark > > > PS Better patch to follow shortly. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
