Primitives in Generics

Brian Goetz brian.goetz at
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 
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 .
> 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>  wrote:
>> Really?
>> On Fri, Jul 9, 2010 at 3:38 PM, Brian Goetz<brian.goetz at>  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
>>> something!

More information about the lambda-dev mailing list