Primitives in Generics
brian.goetz at oracle.com
Fri Jul 9 13:59:20 PDT 2010
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
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
- 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
> On Fri, Jul 9, 2010 at 3:51 PM, Jesse Kuhnert<jkuhnert at gmail.com> wrote:
>> On Fri, Jul 9, 2010 at 3:38 PM, Brian Goetz<brian.goetz at oracle.com> wrote:
>>>>> ... 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
More information about the lambda-dev