[el-spec issues] Re: Return Optional for allMatch, anyMatch, noneMatch
- From: Paul Cowan <cowan@...>
- To: issues@...
- Subject: [el-spec issues] Re: Return Optional for allMatch, anyMatch, noneMatch
- Date: Wed, 22 Jan 2014 10:38:48 -0500
Thank you for the response Kin-man. We'll file a TCK challenge.
I found anther issue with the TCK, no so much the spec, but will start a
different thread for that in hopes of getting your option also.
On Jan 21, 2014, at 6:57 PM, Kin-man Chung <kinman.chung@...> wrote:
> Mark is right in that we need to follow what's in the spec. The RI and TCK
> is not spec conformant and need to be fixed. I'll file an issue on the RI
> and you'll need to send a challenge to the TCK.
> A further complication is that the same methods in the Stream API in JDK 8
> actually retruns a boolean instead of an Optional. Why is EL different from
> JDK 8? Well, at one time, those JDK methods actually return an Optional.
> Later, the JDK Lambda EGs had a change of hearts, and decided that these
> methods should return booleans instead. The argument was: if the collection
> is empty, then these methods cannot be true, and must therefore be false.
> Can we do anything to make EL behave the same as JDK? Unfortunately no.
> Once the spec is released, it cannot be changed, and future version cannot
> be incompatible with the current one. At least that is the current rule and
> I see no easy way to get around it. We may have to live with the
> differences (with JDK 8).
> On 1/20/14, 11:37 PM, Mark Thomas wrote:
>> On 21/01/2014 01:23, cowan@... wrote:
>>> Hi - I'm working to implement EL 3.0 for a JEE licensee.
>>> During TCK testing I have found that the final release spec differs
>>> from the reference implementation and the TCK expected results for the
>>> methods allMatch, anyMatch, and noneMatch.
>>> The spec indicates these should return Optional<Boolean>, however the
>>> TCK expects boolean and the reference impl also return boolean.
>>> Should I obey the spec or the TCK? Any clarification from the experts
>> (non-binding opinion)
>> I'd say the specification is correct. An Optional needs to be returned
>> here as the Stream may be empty.
>> To get an official response (and you'll need to do this any way if I am
>> correct) I'd recommend challenging the relevant TCK test(s).
Paul Cowan, Software Engineer