null String are converted to "" on the bound bean properties

[glassfishrobot]

Change the spec like this:

• 1.23.1, If X is null and Y is not a primitive type, return null.
• 1.23.2, If A is null: return null

Justification:

JSF uses EL expressions to get and set bean properties. With the String behavior as defined in EL spec 3 null String will be converted to "" also without any user input. This is wrong behavior - null String should remain null also after an form edit roundtrip.

JSF has explicitly a parameter to define if empty String input should be handled as null. With EL 3 this null handling is rendered useless.

The problematic sections in the spec are:

• 1.2.1 the part: In the case of lvalues, the expected type is ignored and the provided value is coerced to the actual type of the property the expression points to, before that property is set.
• 1.23.1, If X is null and Y is not a primitive type and also not a String, return null.
• 1.23.2, If A is null: return ""

1.2.1 is problematic for JSF using mostly Object.class as expected type for ValueExpression - but according to 1.2.1 in VE.setValue(elContext, value) the expected type is ignored and therefore the String specific exceptional rules in 1.23.1 and 1.23.2 cause null to "" conversion in VE.setValue(elContext, value).

Looking at the rules 1.23.3 - 1.23.6 for all other non-primitive types null is always remaining null. Why not also for String - it's also a non-primitive.

[glassfishrobot]

Reported by dueni

[glassfishrobot]

kchung said:
I agree that it might be more useful if a null for a String is not converted to "", but remains a null. In EL 2.2, nulls for non primitive types, such as Integer, are converted to their default values (int value in case of Integer), per Java language rules. Due to complains from JSF users, we changed the behavior in EL 3.0 to not do the conversion, so a null remains a null.

The only reason we didn't do the same change for Strings was because there were several tests for String conversions in the CTS tests, and we couldn't make the change without breaking the CTS.

If this is important, we can make the change in the next EL release, release a new CTS tests, and install a backward compatibility option in the implementation for apps that require EL 3.0 behaviors.

[glassfishrobot]

mauromol said:
This problem is causing a real headache in JSF, especially when combined with Bean Validation API... That is, how to make simple things complicated

[glassfishrobot]

This issue was imported from java.net JIRA EL_SPEC-18