Virtual extension methods -- a strawman design

[Osvaldo Doederlein]

Oops, bad finger. Finishing last email: I can also wonder if javac could
help in that transition, especially if we're not lucky wrt APIs. If I have
code like myList.shuffle(), I suggest to consider the possibility of
compiling this into a straight call to Collections.shuffle(List) (as defined
by the 'default' in the defender). This might require some extra javac
option, used together with -source 7 -target 6, or even with -target 7 if
the API retrofitting comes only in SE8. The compiler could generate a
warning if it can't see, from myList's static type, that the default
implementation is guaranteed to be used even in the current platform. And
when the compiler can see that, I suggest that the static call is always
generated because that saves the cost (however small) of
devirtualizing/inlining this call.

Another suggestion: lift all Arrays.* methods into the primitive-array
types, so we can write e.g.

int[] arr = ...;
arr.fill(10);

This would make the defender methods proposal more orthogonal, even if (as
usually) the mechanism is hardwired for the primitive array types - javac
would just rewrite the code above to the proper invokestatic, without any
intermediation or polymorphism. I know that half the people in this list
will hate me for recalling that Java has these primitive arrays, but this is
the language that we are evolving and there's no benefit in pretending that
the old, ugly types don't exist or are not massively used even in new code.

A+
Osvaldo

2010/5/15 Osvaldo Doederlein <opinali at gmail.com>

> 2010/5/15 Brian Goetz <brian.goetz at oracle.com>
>
> > Could you not add closures first and save the library changes for a
>> > future update? The problem of retro-fitting the core API's does make
>> > sense in terms of time frame but it's kind of now or never (or a few
>> > years from now) in terms of having another opportunity to add them
>> > without another new major version number isn't it?
>>
>> Yes, and it is quite possible we may end up doing just that.
>>
>
> I understand that the development of new APIs takes some time to design and
> implement, so leaving that for SE8 would be acceptable as a tradeoff for not
> missing lambdas at all or delaying SE7 further again. But I think at least
> the adaptation of existing APIs should be a no-brainer? Even if this amounts
> to only a handful of methods (like Collections.*), these are very critical
> APIs that tend to be used a lot because collections in general are pervasive
> in modern Java code. So we can allow application code to make a big step
> forward, even with a small and conservative first step of API retro-fitting.
>
> Like Mark said, "there's not a moment to lose" :) but I say that in the
> context of the Java language's window of opportunity to remain... well,
> attractive. Lambdas are already very late, even if JDK 7 ships tomorrow and
> with state of the art lambdas including full API support. Pushing a
> significant part of that to JDK 8 will be almost as bad as just skipping JDK
> 7 and having lambdas only in JDK 8 (or never at all). The Java platform
> blurs the line between the Java language and its core libs (in the sense
> that the language has no good extensibility mechanism and no built-in
> support for concepts that are handled at the language level in some other
> languages - so we rely a lot on core libs); so if SE7 only does the language
> part, this will create serious fragmentation when we have the library
> support later. We'd have two Java-with-lambdas variants, v7+ and v8+, and
> that will suck in the v7->v8 transition period.
>
> I can
>
>