Experts,
I am back from my vacation, but my mundane duty needed for the upcoming
release of Glassfish has prevented me from spending more time on the
JSR, at least for another week.
I've implemented some more LINQ operators, just to make sure that they
actually work, and to get a feel about what needs to be in the spec.
We'll need to document the "methods" in the collections that implement
the query operators. Since they are not really Java methods, we
probably cannot use Javadocs for them. The Lambda expressions that are
passed to these "methods" also needed to be documented. Again javadocs
cannot be used here. If any of you have good ideas how to do this,
please let me know.
Anyway, if you are interested, checkout the sources from the svn repository.
Last Monday, I reported on the current status of EL spec to the Javaee
architecture team and received some valuable feedback.
1. There is a concern that unrestricted access to static fields and
constructor calls, such as
T(com.wombat.Employee)()
can be a security risk. I did pointed out that they are public anyway,
but the team still feel that the ability to call any public constructors
is too much power for EL, at least it should not be the default behavior.
My first response is to only allow static members references and
constructor calls to those classes that have been imported (by calling
ELManager.importClass() ). This would include those in java.lang
packages, since they are pre imported. What do you think?
2. The syntax for Lambda and the collection literals should follow those
in JDK 8, to avoid confusion. I agreed in principle, and would look
into making it work for EL. It would be easy to change the syntax for
collection literals. It just a matter of using {} for arrays, [] for
lists, and {key: value} for maps; but I think might have problem with
using JDK 8's syntax for Lambdas. I'll need to investigate.
3. The current "methods" in the collections return a Iterable, so EL
needs to provide a conversion from Iterable to the target collection type.
Kin-man