Coin "reloaded" for lambda ?
brian.goetz at oracle.com
Tue Jun 21 16:27:02 PDT 2011
The extent of the Coin contribution to Java SE 8 is not yet determined.
However, it is safe to assume that with big changes to the language
(lambdas, extension methods), platform (modularity), and libraries
(collections upgrades), that the Coin contribution will be smaller than
it was in 7. Likely candidates include collection literals and
repeating annotations -- both of which were things that were desired for
Coin I but missed the cut. I think it is safe to assume that Elvis and
Properties will not be coming in 8.
On 6/21/2011 7:17 PM, Artur Biesiadowski wrote:
> There was discussion some time ago about how short lambdas will be with
> java language in real world. Some examples were given where simple
> concepts were being lost because of extra verbosity needed to handle
> equality/null safety etc.
> Is there any chance that next incarnation of coin project (one going
> together with lambdas for java 8) could incorporate some changes which
> would actually allow writing shorted lambads in java?
> I'm talking about elvis operators in particular. While I understand that
> they were rejected for 'normal' java usage, I think they could be very
> useful in helping with shorter lambda expressions. If we could get a set
> of collection operations which would be null aware (and skipping nulls
> instead of trying to preserve them), we probably can treat null as poor
> man None Option from scala.
> ?: is the same as getOrElse from scala.
> ?. would allow some of the collect/foreach/filter operations to be
> considerably simpler
> It is still not solving many of the problems - following will not work
> list.filter(x -> x?.getPerson()?.getAge()> 35)
> list.filter(x -> x?.getState()?.isEnabled())
> Another missing part is safe equals method call ( x == y || (x!=null&&
> y!= null&& x.equals(y) ). Can be easily emulated with static import and
> eq(x,y), so probably it is not a killer.
> There might be some other possible improvements - my point is that maybe
> some previously rejected ideas could be reevaluated from the perspective
> of helping short lambdas.
> True property support would also help a lot, but this is for sure out of
> scope for now...
> With best regards,
> Artur Biesiadowski
More information about the lambda-dev