2013/7/14 <ma...@apache.org>:
> Author: markt
> Date: Sun Jul 14 17:57:06 2013
> New Revision: 1503006
>
> URL: http://svn.apache.org/r1503006
> Log:
> Special handling to handle the ambiguity of {} which could be an empty Set or
> an empty Map
>
> Modified:
> tomcat/trunk/java/org/apache/el/lang/ELSupport.java
>
> Modified: tomcat/trunk/java/org/apache/el/lang/ELSupport.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/el/lang/ELSupport.java?rev=1503006&r1=1503005&r2=1503006&view=diff
> ==============================================================================
> --- tomcat/trunk/java/org/apache/el/lang/ELSupport.java (original)
> +++ tomcat/trunk/java/org/apache/el/lang/ELSupport.java Sun Jul 14 17:57:06
> 2013
> @@ -21,6 +21,9 @@ import java.beans.PropertyEditor;
> import java.beans.PropertyEditorManager;
> import java.math.BigDecimal;
> import java.math.BigInteger;
> +import java.util.Collections;
> +import java.util.Map;
> +import java.util.Set;
>
> import javax.el.ELException;
>
> @@ -417,6 +420,14 @@ public class ELSupport {
> return editor.getValue();
> }
> }
> +
> + // Handle special case because the syntax for the empty set is the
> same
> + // for an empty map. The parser will always parse {} as an empty set.
> + if (obj instanceof Set && type == Map.class &&
> + ((Set<?>) obj).isEmpty()) {
> + return Collections.EMPTY_MAP;
> + }
> +
> throw new ELException(MessageFactory.
get("error.convert",
> obj, obj.getClass(), type));
> }
1. It is odd that I see no clarification in the spec regarding this
ambiguity. It the value is exposed as an Object, the difference might
be seen.
Well, many places accept both sets and maps.
E.g. "empty" operator in EL (${empty {}} is true), <c:forEach items="{}">.
But their toString() values differ.
an empty AbstractMap prints "{}"
an empty AbstractCollection prints "[]".
2. I am a bit puzzled why there is exact equality test in "type ==
Map.class" (whether type can be a subclass of Map).
Well, EL does not promise to provide any specific Map implementation,
so it is unlikely that anyone notices a difference.
3. It would be safer if instead of a generic "is set empty" check we
could check that this set was indeed created by our EL. E.g. use some
sentinel object.
4. Are sets and maps created by EL supposed to be immutable (e.g.
wrapped by Collections,unmodifiableSet())?
I just hope that such sequence of assignments is invalid:
<c:set var="foo" value="${{}}"/>
<c:set target="${foo}" property="key" value="value" />
<c:out value="${foo['key']}" />
Also, if I understand correctly, the same could be done using a semicolon:
${ foo={}; foo['key']='value'; fn:escapeXml(foo['key'])}
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
