[Bug 60367] New: null arbitrarily coerced to empty string on EL method call

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60367

            Bug ID: 60367
           Summary: null arbitrarily coerced to empty string on EL method
                    call
           Product: Tomcat 9
           Version: 9.0.0.M13
          Hardware: PC
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: 6s4vpwuprk@snkmail.com
  Target Milestone: -----

If I have a method in a Java class
public String doSomething(Boolean bValue, String sValue)

and I call this method from a JSP using
${myobject.doSomething(null, null)}

then the method is called with bValue being null, sValue being "".

This surprising behavior is caused by line 523 in
http://svn.apache.org/repos/asf/tomcat/tc9.0.x/branches/gsoc-jaspic/java/org/apache/el/lang/ELSupport.java

The code there looks like this:
        if (!COERCE_TO_ZERO) {
            if (obj == null && !type.isPrimitive() &&
                    !String.class.isAssignableFrom(type)) {
                return null;
            }
        }

It isn't quite obvious to me why Strings are excluded from being returned as
null while all other types are allowed to pass as null.

For me currently this is more than an academic question or just a remarkable
oddity in Tomcat as I'm experiencing serious trouble implementing what I want
when I'm unable to give a String parameter as null. Some methods explicitly
expect to receive null in order to indicate something particular. It doesn't
feel like good design if I have to write an own wrapper around all these cases
with something like

public String doSomethingHack(Boolean bValue, String sValue)
{
   if (sValue!=null && sValue.isEmpty()) sValue=null;
   ref.doSomething(bValue, sValue);
}


There is no comment about why there is this hard-coded exclusion for one
arbitrary type in line 523.

Please kindly review this and consider a more consistent solution.
COERCE_TO_ZERO should either work for all types or none, but there shouldn't be
any specialties.
I necessary provide separate configuration for Strings COERCE_TO_EMPTY_STRING
although I would not consider this type of granularity good design.

Maybe the current behavior was chosen in order to avoid NPEs for some other use
cases, but these issues should be solved where values are read. The default
behavior in ELSupport.java should be that all values pass through as given as
long as types fit and unless configured otherwise.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 60367] null arbitrarily coerced to empty string on EL method call

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60367

Remy Maucherat <re...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED
                 OS|                            |All

--- Comment #1 from Remy Maucherat <re...@apache.org> ---
See https://java.net/jira/browse/EL_SPEC-18

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org