Skip to main content

[el-spec users] [jsr341-experts] Re: Changing the collection method names

  • From: Kin-man Chung <kinman.chung@...>
  • To: jsr341-experts@...
  • Subject: [el-spec users] [jsr341-experts] Re: Changing the collection method names
  • Date: Tue, 14 Aug 2012 15:18:02 -0700
  • List-id: <>

On 08/14/12 14:15, Mark Thomas wrote:
On 13/08/2012 19:22, Kin-man Chung wrote:
Another feedback for the public review raised the issue of how EL 3.0
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
so far:

     1. Begins with a capitol, e.g.
         products.Where(p->price>  10).Select(p->
     2. Prepend with an el$, e.g.
         products.el$where(p->price>  10).el$select(p->
     3. Prepend with a $, e.g.
         products.$where(p->price>  10).$select(p->

Personally, I think 1. is too easily confused with ones in lower case,
and 2. is too ugly, 3. is a good compromise.

I'm not familiar with Java 8 so apologies if this doesn't make any sense.

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

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". :-)

We can change our names to match theirs, but what if the behavior are not exactly the same? we cannot even change ours to match theirs now when the target is moving. Also, if we take some names from Java 8, and some form Linq, wouldn't it be more confusing?

The other difficulty is Java 8 is introducing a new interface java.util.Stream to encapsulate the idea of lazy evaluation in the collection operations, but EL operators work with java.util.Iterables. Since Stream does not exist in Java 7, we cannot really use it in our implementation.

Using a different naming convention will make it clear that ours are different from theirs.
I agree 1 is too easy to get wrong.

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.)

 I'm OK with 2 also.


[el-spec users] [jsr341-experts] Changing the collection method names

Kin-man Chung 08/13/2012

[el-spec users] [jsr341-experts] Re: Changing the collection method names

Mark Thomas 08/14/2012

[el-spec users] [jsr341-experts] Re: Changing the collection method names

Kin-man Chung 08/14/2012

[el-spec users] [jsr341-experts] Re: Changing the collection method names

Mark Thomas 08/14/2012
Please Confirm