On 13/08/2012 19:22, Kin-man Chung wrote:The problem is this part of Java 8 is still under discussion, and changing. The lambda spec lead sent me some sources, but with the warning that "they are guarantied to look different a month later". :-)
Another feedback for the public review raised the issue of how EL 3.0I'm not familiar with Java 8 so apologies if this doesn't make any sense.
will work with Java SE 8.
SE 8 is not out yet, but will be next year. It also contains Lambda and
some collection operators, so it become important that EL 3.0 and SE 8
works together well. The syntax for Lambda is the same in EL and SE8,
so we are OK there. The area of collection operation support is more
problematic, because there is only a smaller set of operations in SE8
and their names and behaviors are not the same as those in EL.
What is important is the new methods added in SE 8 will be invoked
through reflections in EL (we'll need to get this to work in
BeanELResolver). To avoid invoking the unintended methods in EL, we'll
need a way to name our methods differently from Java names. Suggestions
1. Begins with a capitol, e.g.
2. Prepend with an el$, e.g.
3. Prepend with a $, e.g.
Personally, I think 1. is too easily confused with ones in lower case,
and 2. is too ugly, 3. is a good compromise.
If EL 3.0 is a superset of Java 8, why doesn't EL 3.0 uses the
names/behaviours as defined in Java 8 and add the extra EL 3.0 ones on
top of that? Granted, we'll still have the same issue if Java SE adds
extra methods so maybe we should have a separate naming convention but
it still seems to be that alignment with Java 8 would be a good place to
I agree 1 is too easy to get wrong.I'm OK with 2 also.
I actually prefer 2 over 3 since it is more explicit about what is going
on. It also allows other xxx$ prefixes - such as container specific
extensions - if required. (Not that I am planning any right now.)
[el-spec users] [jsr341-experts] Re: Changing the collection method names