[EL_SPEC-8] Typo in Javadoc for ElProcessor.defineFunction Created: 05/Nov/12  Updated: 05/Nov/12  Resolved: 05/Nov/12

Status: Closed
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dougd Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes
Environment:

N/A



 Description   

Simple type to fix.

ClassNoFoundException - if the specified class does not exists. <--- Should be ClassNotFoundException just missing the "t"






[EL_SPEC-14] null string value is converted to "" Created: 04/Jul/13  Updated: 07/Oct/13  Resolved: 07/Oct/13

Status: Resolved
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Works as designed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 4.0, el 3.0


Tags: empty, jsf2_2, string

 Description   

null string from JSF is converted to empty string.
I traced to code com.sun.el.lang.ELSupport 350. Should this decision be left to EL client?



 Comments   
Comment by Kim Haase [ 07/Oct/13 ]

I believe this bug corresponds to https://java.net/jira/browse/JAVAEETUTORIAL-249. The zip file attached to that issue reproduces the problem on EE 7. I will attach another zip file to that issue to show that the problem is new in EL 3.0, because when the test example is run in an EE 6 environment, it runs correctly.

Comment by kchung [ 07/Oct/13 ]

EL 3.0 spec (1.23.2 Coerce A to String) clearly says

If A is null: return ""

So this is behaving according to the spec.





[EL_SPEC-1] ResourceBundleELResolver.getFeatureDescriptors return type is not generic Created: 29/Nov/11  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Resolved
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kchung Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

ResourceBundleELResolver.getFeatureDescriptors returns a Iterator, while ELResolver.getFeatureDescriptors returns a Iterator<java.beans.FeatureDescriptor>



 Comments   
Comment by kchung [ 19/Mar/13 ]

This has already been fixed.





[EL_SPEC-11] Clarify how single variable evaluates to method Created: 08/Jan/13  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Resolved
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: clarification, evaluation, methodexpression

 Description   

Section 1.2.1.2 in the EL specification mentions that a method expression can consist of a single variable:

 
A method expression shares the same syntax as an lvalue. 
That is, it can only consist of either a single variable
(e.g. ${name}) or a property resolution on some object, 
via the . or [] operator (e.g. ${employee.name}).

As it appears, it's not entirely clear how such single variable should be evaluated.

In the reference implementation for example, we see that in this case a MethodExpressionImpl will reference an AstIdentifier, which will use the context's variable mapper to obtain a ValueExpression. The value is then obtained from this value expression, and it's expected to be a MethodExpression, which is then invoked.

This can be seen at http://java.net/projects/el-spec/sources/source-code/content/trunk/impl/src/main/java/com/sun/el/parser/AstIdentifier.java?rev=198 where the method getMethodExpression at line 198 demonstrates the "value expression wrapping a method expression" assumption. invoke at line 183 then shows this obtained method expression is simply invoked.

Comments on line 198 and 209 explicitly mention 2 cases:

case A: ValueExpression exists, getValue which must
be a MethodExpression

[...]

case B: evaluate the identity against the ELResolver, again, must be
a MethodExpression to be able to invoke

These cases however are not outlined in the specification. As a result, alternative EL implementations (like JUEL) have taken a completely different approach. In the case of JUEL, it also expects a ValueExpression, but then guessed that this value expression should be wrapping a Method. This on its turn leads to unexpected behavior and bugs such as reported here: http://code.google.com/p/omnifaces/issues/detail?id=100

In order to ensure portability between EL implementations, I would like to request this specific case to be clarified in the specification.



 Comments   
Comment by beckchr [ 08/Jan/13 ]

See also this issue from 2006: http://java.net/jira/browse/JSP_SPEC_PUBLIC-164

Comment by kchung [ 19/Mar/13 ]

What about adding the following clarification to 1.2.1.2

When a MethodExpression created from an EL expression of the form $

{name}

is invoked,

1. The identifier "name" is first evaluated.
a. If "name" is an EL variable, the ValueExpression associated with the variable is evaluated.
b. Else obtain the value resolved in the ELResolvers.
2. If the identifier evaluates to a MethodExpression, it is invoked and its result is returned.
3. Else error.

Comment by kchung [ 19/Mar/13 ]

Added a new section 1.5.4. in EL 3.0 spec to clarify the issue.

Comment by arjan tijms [ 19/Mar/13 ]

What about adding the following clarification to 1.2.1.2 [...]

It sounds okay to me, thanks!





[EL_SPEC-3] Backwards Compatibility Issue with coercion of null to String Created: 11/May/12  Updated: 20/Feb/13  Resolved: 20/Feb/13

Status: Resolved
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dougd Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes
Environment:

N/A



 Description   

Previous versions of EL when coercing a null to a String would return an empty string. WE know return a null.

This issue is being opened to track backwards compatibility for the above mentioned.



 Comments   
Comment by kchung [ 20/Feb/13 ]

The latest spec does not have this issue any more. That is coercing a null to String is still "".





[EL_SPEC-5] Collections defaultIfEmpty operator does not exist Created: 02/Aug/12  Updated: 02/Aug/12  Resolved: 02/Aug/12

Status: Resolved
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dougd Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A



 Description   

There appears to be no code for defaultIfEmpty operator.

products.orderByDescending(p->p.unitPrice).elementAtOrDefault(3).defaultIfEmpty()
ERROR: Exception at:
ERROR: javax.el.MethodNotFoundException:



 Comments   
Comment by kchung [ 02/Aug/12 ]

Fixed





[EL_SPEC-4] Collections average operator does not return null Created: 02/Aug/12  Updated: 02/Aug/12  Resolved: 02/Aug/12

Status: Resolved
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dougd Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A



 Description   

The specification states the following for the average operator section 2.3.44.2

"The average operator returns null for an empty collection."

The below should return null and does not.

"[].average()"



 Comments   
Comment by kchung [ 02/Aug/12 ]

Fixed





[EL_SPEC-2] Backwards Compatibility Issue with Binary Operator "+" Created: 27/Apr/12  Updated: 14/Mar/13  Resolved: 14/Mar/13

Status: Resolved
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dougd Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A



 Description   

In section 1.7.1 Binary Operators of the Expression Language Specification Version 3.0, there has been an additional Rule added that causes a Backwards compatibility issue.

From version 3.0 of the specification its states the following:

1.7.1 Binary operators - A {+,-,*} B
■ If the operator is a +, and either A or B is a String, then + is a string concatenation <---- This is the newly added Rule.
operator.
■ If A and B are null, return (Long)0
■ If A or B is a BigDecimal, coerce both to BigDecimal and then:
■ If operator is +, return A.add(B)
■ If operator is -, return A.subtract(B)
■ If operator is *, return A.multiply(B)
■ If A or B is a Float, Double, or String containing ., e, or E: <---------- This Rule never gets reached now !!!!!
■ If A or B is BigInteger, coerce both A and B to BigDecimal and apply
operator.
■ Otherwise, coerce both A and B to Double and apply operator
■ If A or B is BigInteger, coerce both to BigInteger and then:
■ If operator is +, return A.add(B)
■ If operator is -, return A.subtract(B)
■ If operator is *, return A.multiply(B)
■ Otherwise coerce both A and B to Long and apply operator
■ If operator results in exception, error

The problem with the newly added rule at the top of the order is that they " If A or B is a Float, Double, or String containing ., e, or E:" Never gets a chance to be parsed. This breaks backwards compatibility.



 Comments   
Comment by dougd [ 27/Apr/12 ]

Maybe we can do something like this.

1.7.1 Binary operators - A {+,-,*} B
■ If the operator is a +, and either A or B is a String:
■ If A or B is a Float, Double, or String containing ., e, or E:
■ If A or B is BigInteger, coerce both A and B to BigDecimal and apply operator.
■ Otherwise, coerce both A and B to Double and apply operator
■ Otherwise + is a string concatenation operator.
■ If A and B are null, return (Long)0
■ If A or B is a BigDecimal, coerce both to BigDecimal and then:
■ If operator is +, return A.add(B)
■ If operator is -, return A.subtract(B)
■ If operator is *, return A.multiply(B)
■ If A or B is BigInteger, coerce both to BigInteger and then:
■ If operator is +, return A.add(B)
■ If operator is -, return A.subtract(B)
■ If operator is *, return A.multiply(B)
■ Otherwise coerce both A and B to Long and apply operator
■ If operator results in exception, error

Comment by kchung [ 14/Mar/13 ]

The symbol + is no longer used as a concatenation operator in PFD.





[EL_SPEC-6] Rewrite the spec for collection support Created: 31/Oct/12  Updated: 14/Mar/13  Resolved: 14/Mar/13

Status: Resolved
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: kchung Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: EE7_GF4

 Description   

The EL spec needs to align with Java Se8 regarding the support for collection operators. The part about LINQ operator needs to be removed, and replace with similar operations in SE 8.

The operators also need to be implemented.



 Comments   
Comment by kchung [ 14/Mar/13 ]

fixed.





[EL_SPEC-9] ELProcessor.defineFunction methods do not check for null args... Created: 05/Nov/12  Updated: 20/Feb/13  Resolved: 20/Feb/13

Status: Resolved
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dougd Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A



 Description   

API documentation states for both of the defineFunction methods that a NullPointerException should be thrown if any arg is null. Niether on of the methods looks to be testing for null args.

Example below.

public void defineFunction(String prefix, String function, Method method) {

if (prefix == null || function == null || method == null)

{ <-- need to add something like this. throw new NullPointerException(); }

if (function.equals(""))

{ function = method.getName(); }

elManager.mapFunction(prefix, function, method);
}



 Comments   
Comment by kchung [ 20/Feb/13 ]

Fixed.

Note the spec has also been modified to also throw a NoSuchMethodException if the method is not static. See the javadocs for detailed.





[EL_SPEC-7] Typo in Javadoc for ElProcessor.defineFunction Created: 05/Nov/12  Updated: 14/Mar/13  Resolved: 14/Mar/13

Status: Resolved
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dougd Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A



 Description   

Simple type to fix.

ClassNoFoundException - if the specified class does not exists. <--- Should be ClassNotFoundException just missing the "t"



 Comments   
Comment by kchung [ 14/Mar/13 ]

Fixed.





[EL_SPEC-10] API doc errors for javax.el.TypeConverter Created: 14/Nov/12  Updated: 20/Feb/13  Resolved: 20/Feb/13

Status: Resolved
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: dougd Assignee: kchung
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A



 Description   

Here is the Example that we have provided in the API docs.

ELProcessor elp = new ELProcessor();
elp.getELManager().addELResolver(new TypeConverter() {
Object convertToType(ELContext context, Object obj, Class type) {
if (obj instanceof String) && type == MyDate.class)

{ context.setPropertyResoved(obj, type); return (obj == null)? null: new MyDate(obj.toString()); }

return null;
}
};

Below I have put the various fixes in spelling and syntax.

ELProcessor elp = new ELProcessor();
elp.getELManager().addELResolver(new TypeConverter() {
Object convertToType(ELContext context, Object obj, Class type) {
if ((obj instanceof String) && type == MyDate.class)

{ <------ Added missing "(" context.setPropertyResolved(obj, type); <------ Fixed Spelling on Method call. return (obj == null)? null: new MyDate(obj.toString()); }

return null;
}
};



 Comments   
Comment by kchung [ 20/Feb/13 ]

Fixed.





[EL_SPEC-16] Static fields and methods are evaluated to null in Facelets Created: 01/Sep/13  Updated: 10/Jul/14

Status: Open
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: marfous Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GF4.0, JSF2.2



 Description   

When I use static field or method within Facelet, it's value is evaluated to null.

Example:
#

{Integer.MAX_VALUE}

#

{Integer.toHexString(16)}

Or this shows in the rendered page that result of the static call was null
#

{[0, 1, Integer.MAX_VALUE]}

 Comments   
Comment by mdzaebel [ 10/Jul/14 ]

As static fields (and enum) access cover a significant part of the Spec I wonder why this is not commented or assigned to anyone. Is this problem already fixed or has it a workaround or are we all wrong?

Environment: GF4.0, JSF2.2, EL 3.0, Win7





[EL_SPEC-17] MethodExpression.getMethodInfo() always returns null Created: 12/Dec/13  Updated: 12/Dec/13

Status: Open
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Harald Wellmann Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

javax.el-3.0.0.jar standalone, Oracle Java 1.7.0_45 on Linux 64-bit



 Description   

When invoking getMethodInfo() on a method expression, I always get null.

This seems to be caused by AstValue.getMethodInfo():

    public MethodInfo getMethodInfo(EvaluationContext ctx, Class[] paramTypes)
            throws ELException {
        Target t = getTarget(ctx);
        if (t.isMethodCall()) {
            return null;
        }
        Object property = t.suffixNode.getValue(ctx);
        Method m = ReflectionUtil.getMethod(t.base, property, paramTypes);
        return new MethodInfo(m.getName(), m.getReturnType(), m
                .getParameterTypes());
    }

Shouldn't this be

if ( ! t.isMethodCall()) {
    return null;
}





[EL_SPEC-15] javax.el.BeanELResolver.setValue inconsistent javadoc Created: 12/Jul/13  Updated: 12/Jul/13

Status: Open
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: violetagg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,

EL 3.0 javadoc javax.el.BeanELResolver.setValue describes:

...
If the property exists but does not have a setter, then a PropertyNotFoundException is thrown.
...
PropertyNotWritableException - if this resolver was constructed in read-only mode, or if there is no setter for the property.
...

Can you please clarify which exception should be thrown when the property does not have a setter method?

Thanks
Violeta






[EL_SPEC-13] TypeConverter API documentation does not match impl. Created: 06/Jun/13  Updated: 06/Jun/13

Status: Open
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dougd Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A



 Description   

According to the API documentation all the methods except for "convertToType" are and say exactly what the ELRosolver would do. But the Imp for any of these methods(listed below) do nothing or return null. the

getCommonPropertyType
getFeatureDescriptors
getType
getValue
isReadOnly
setValue

Example:

From the src for getValue

@Override
public Object getValue(ELContext context,
Object base,
Object property)

{ return null; }

This is what the Javadoc says

public Object getValue(ELContext context,
Object base,
Object property)
Description copied from class: ELResolver
Attempts to resolve the given property object on the given base object.
If this resolver handles the given (base, property) pair, the propertyResolved property of the ELContext object must be set to true by the resolver, before returning. If this property is not true after this method is called, the caller should ignore the return value.

Specified by:
getValue in class ELResolver
Parameters:
context - The context of this evaluation.
base - The base object whose property value is to be returned, or null to resolve a top-level variable.
property - The property or variable to be resolved.
Returns:
If the propertyResolved property of ELContext was set to true, then the result of the variable or property resolution; otherwise undefined.






[EL_SPEC-20] Reduce source/target from 1.7 to 1.6 Created: 06/Jun/14  Updated: 06/Jun/14

Status: Open
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: rotty Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently the el api and impl are set to source/target 1.7

However, there are no functional requirement or features of the 1.7 JRE used.

The only current barrier is with tests which fail when set to 1.6. However, when skipping tests, el compiles quite fine.

This has a transitive cost of imposing 1.7 on JSP also.



 Comments   
Comment by rotty [ 06/Jun/14 ]

See JSP-43

Comment by rotty [ 06/Jun/14 ]

After further discussion with colleagues we realized there is no need for this.

the issue can be resolved "won't fix"





[EL_SPEC-19] Javadoc for ExpressionFactory#getInitFunctionMap is incorrect Created: 20/May/14  Updated: 20/May/14

Status: Open
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kchung Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The javadoc for ExpressionFactory#getInitFunctionMap says:

    /**
     * Retrieve a function map containing a pre-configured function
     * mapping.  It must include the following functions.
     * <ul>
     * <li>linq:range</li>
     * <li>linq:repeat</li>
     * <li>linq:_empty</li>
     * </ul>
     * @return A initial map for functions, null if there is none.
     *
     * @since EL 3.0
     */

This is not correct, as EL 3.0 no longer has to support these functions.






[EL_SPEC-21] Property support for Optional<T> Created: 06/Dec/14  Updated: 11/Dec/14

Status: Open
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: pdudits Assignee: kchung
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Expression language in Java EE 8 should bring special treatment for java.util.Optional, similar like it does for maps and lists:

When a base expression evaluates to instance of java.util.Optional, and the property name is not equal present, the result of the evaluation shall be equivalent to calling method map or flatMap on the optional:

  • if the base {{Optional]} has value:
    1. evaluate the property against the value of the property,
    2. if the result of an evaluation is instance of an Optional
      • return the value; otherwise
      • return the value wrapped in an Optional
  • if base optional, doesn't have value, return Optional.empty()

The property present is evaluated by invoking the method isPresent() of the base object.

An example of implementation of this behaviour can be found in this ELResolver implementation.



 Comments   
Comment by kchung [ 11/Dec/14 ]

EL 3.0 was targeted for JDK 7, and as such knows nothing about Optional. However, Optional should be supported in the next release of EL, which is presumable targeted for JDK 8. It is also likely that the next release of EL, EL 3.1 will be a MR.





[EL_SPEC-22] Make it possible to use javax.el.LambdaExpression in place of java se 8 functional interfaces Created: 06/Dec/14  Updated: 11/Dec/14

Status: Open
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: pdudits Assignee: kchung
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Since EL Lambdas predate Java functional interfaces, custom EL resolvers must be used to as bridge between javax.el.LambdaExpression, and actual method with a accepting functional interface parameter.

Java EE 8 revision of EL should either

  1. bring sufficient support for all Java SE methods accepting functional interfaces, or
  2. offer implicit type conversion from LambdaExpression to appropriate types defined in java.util.function, or
  3. offer implicit conversion to any Functional interface conforming to §9.8 of JLS.

Example implementation of the first approach for java.util.Optional can be seen here



 Comments   
Comment by kchung [ 11/Dec/14 ]

Again, this is in the plan for EL 3.1.

It would be straight forward to support the conversions to all the known functions in java.util.functions, approach 2 above, but it will be difficult to support general functional interfaces, since it involves calling methods with Lambda expressions as arguments in reflection, which is hard to get right. So approach 3 is unlikely to be supported in EL 3.1.





[EL_SPEC-23] Stream operators anyMatch, allMatch, and nonMatch should return boolean Created: 15/Jan/15  Updated: 15/Jan/15

Status: Open
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kchung Assignee: kchung
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The stream operators anyMatch, allMatch, and noneMatch returns an Optional, while those operators in JDK 8 (java.util.stream#Stream) returns a boolean. This difference is confusing. EL spec should be changed to agree with JDK 8.

The difference happened because EL 3.0 spec was released before Java SE 8. Now that SE 8 was release, EL should be brought up to date.






[EL_SPEC-18] null String are converted to "" on the bound bean properties Created: 14/May/14  Updated: 03/Dec/14

Status: Open
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

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.



 Comments   
Comment by kchung [ 19/May/14 ]

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.

Comment by mauromol [ 03/Dec/14 ]

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





[EL_SPEC-24] Define behaviour for MethodExpression.invoke() with incorrect parameters Created: 27/Apr/15  Updated: 27/Apr/15

Status: Open
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: markt_asf Assignee: kchung
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

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

If a MethodExpression has been created (wihtout parameters), what is the expected behaviour if invoke() is called with null for the parameters or the wrong number of parameters? IAE, IAE wrapped in an ELException? Something else?






[EL_SPEC-25] Access public fields Created: 25/Jun/15  Updated: 25/Jun/15

Status: Open
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: calen Assignee: kchung
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any



 Description   

There is an increasingly recommended practice of disallowing entities in the presentation layer, and instead just passing DTOs. Since DTOs don't have any behavior, nor are they persistent, and because their very purpose is to simply hold and serve data, there is no reason to encapsulate their fields. So there is no reason what DTO fields shouldn't be public, since getters & setters don't add any value to them.

It would therefore be great if EL could access public fields, to save developers the bother of having to add needless getters & setters:

public class PersonDTO

{ public String name; }

$

{person.name}




Generated at Wed Aug 05 04:50:18 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.