howard.lovatt at gmail.com
Mon Mar 29 18:51:24 PDT 2010
I think the strongest argument that anyone has made against using 'new' is
your "economy of expression" argument, it then comes down to trading off
conciseness against consistency and clarity. I go with consistency and
clarity and you go with conciseness. I guess Alex or someone at Sun will
With regard to caching lambdas I think the specification should make this
optional, provided that it doesn't change program behavior. I.e. just like
other optimizations in Java, e.g. in-lining a method until a new class is
loaded that makes that in-lining invalid.
On 30 March 2010 02:00, Joshua Bloch <jjb at google.com> wrote:
> On Mon, Mar 29, 2010 at 3:39 AM, Howard Lovatt <howard.lovatt at gmail.com>
> This group has also commented on the undesirability of Integer interning
> some values and not others.
> I don't think that's the problem so much as the fact that the spec mandates
> which values must be interned. This causes people to write unreadable and
> unmaintainable programs that take advantage of those guarantees. I with the
> JLS had merely suggested that implementations might want to cache and reuse
> common values as a quality-of-service issue. So I see this as a case of
> overspecification, rather that an inherently bad idea. As I said a while
> back, I believe the same behavior is appropriate for lambdas: the
> specification should not mandate the creation of an object each time a
> lambda expression is evaluate, and should note (using non-normative text),
> that implementers should avoid creating such objects when it results in
> improved performance.
> Regarding the desirability of using the "new" keyword for lambdas (a
> purely syntactic decision): Even if each evaluation of a lambda expression
> did result in the creation of a new object, a primary raison d'etre for
> lambdas in Java is economy of expression. The "new" keyword (preceded and
> followed by a space) is detrimental to that goal.
More information about the lambda-dev