[EL_SPEC-27] Importing a (public, concrete) nested static class does not work Created: 22/Jul/16  Updated: 22/Jul/16

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

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


 Description   

Hello; I am not sure if this is a specification issue, or a reference implementation issue.

If I define a static nested class that is public and non-abstract, and then attempt to import it using ImportHandler#importClass(String), it does not get imported.



 Comments   
Comment by ljnelson [ 22/Jul/16 ]

Sorry, should have mentioned: this is using StandardELContext#getImportHandler().





[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-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-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-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-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}




[EL_SPEC-26] maven snapshot repo in bad state, not properly cleaned up Created: 04/Mar/16  Updated: 04/Mar/16

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

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


 Description   

See

https://maven.java.net/content/repositories/snapshots/org/glassfish/javax.el/

Maven builds are complaining about missing pom.xml files.






Generated at Tue Feb 21 19:07:00 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.