Primitives in Generics
neal at gafter.com
Fri Jul 9 14:23:57 PDT 2010
"closures" is slang for lambda expressions, which means lexically-scoped
function-valued expressions. Unfortunately, what is Brian is now calling a
lambda expression is neither lexically scoped nor function-valued.
On Fri, Jul 9, 2010 at 2:13 PM, Jesse Kuhnert <jkuhnert at gmail.com> wrote:
> Those are Nice things, just thought we were getting closures.
> On Friday, July 9, 2010, Brian Goetz <brian.goetz at oracle.com> wrote:
> > At the risk of stating the blindingly obvious...
> > We are constrained by many things:
> > - Source and/or binary compatibility
> > - "Spiritual" compatibility (i.e., don't too badly violate the common
> man's idea of "what Java is" or make Java too complex for the market segment
> in which it has succeeded)
> > - Specifiability, Testability, Implementability, Teachability
> > - Budget constraints
> > - Time constraints
> > - Political constraints
> > - Technical constraints
> > - Quality constraints
> > - Cross-dependencies with other initiatives going on inside the JDK
> development effort or other initiatives at Oracle
> > - etc etc etc
> > Some of these constraints we can talk about publicly (e.g.,
> compatibility); others are confidential (e.g., budgets).
> > On the other hand, the majority of the participants on this list are
> constrained only by:
> > - What they want Java to be if they had infinite time and resources
> > Now, even if I agreed 100% with someone else's vision for what Java
> should be, reality frequently forces us to accept less in the name of
> shipping software in our lifetime. This isn't because we don't understand
> the vision, or don't care about Java, or simply are morons, but because at
> the end of the day, what matters is what you ship, not what you talk about
> shipping in the future.
> > Without triage decisions of what features to leave out, we would never
> ship -- the set of "worthwhile" features is infinite! And not shipping is
> bad not only for Oracle, but for the Java community as a whole, since they
> never get the benefit of any innovation, just lots of promises about how
> good tomorrow will be.
> > In short, you probably are just frustrated and pouting. Frustrated is
> OK; life is imperfect.
> > As to this specific decision, to not solve A or B in JDK 7 and instead
> leave it to be tomorrow's problem -- of course we would like to see it
> solved now just as much as you do (duh!) You can blame it on the "guys
> upstairs" if you like; I think it is better to solve something in 7 and
> something more in 8 than to never ship anything.
> > So let's please focus on the half-full part of the glass. We've got a
> plan here for:
> > - lambda expressions
> > - SAM conversion
> > - Exception transparency
> > - Interface evolution
> > - Method references
> > That sounds like some good stuff to me.
> > On 7/9/2010 4:33 PM, Jesse Kuhnert wrote:
> > Sorry, to clarify.
> > It "feels" like most people who like to tinker in other languages -
> > even if on the side or smaller portions of projects - tend to not take
> > anything seriously that doesn't have common language support for
> > things like "closures" and parallel capabilities.
> > Given this choice of C you might start to assume Java is just going to
> > kind of limp along but Oracle isn't seriously attempting do anything
> > but minimal / easy (from a user acceptance / scary unknown / meeting
> > deadlines point of view) changes. Given that thought, how much longer
> > can people continue to look at the jvm as a viable runtime? (well,
> > realistically right now probably for a while still.. ;) ) There are
> > more projects coming out for this as well http://llvm.org/ .
> > I'm probably just frustrated and pouting, but seems kind of weird to
> > have seen all of this work only to to finish it up like this.
> > Guessing "someone from above" made the decision for you guys. Or
> > hoping.
> > On Fri, Jul 9, 2010 at 3:51 PM, Jesse Kuhnert<jkuhnert at gmail.com>
> > Really?
> > On Fri, Jul 9, 2010 at 3:38 PM, Brian Goetz<brian.goetz at oracle.com>
> > ... some mad professor cooked up :) :) :)
> > My take is that you have three choices:
> > A) Support function types covering primitives
> > B) Support primitives in generics
> > C) Do something that doesn't restrict your options to reconsider
> > (A) or (B) in Java8 in response to all the complaints about
> > sucky parallel performance.
> > Indeed so. We believe we have chosen (C). If we have not, please say
> > something!
More information about the lambda-dev