Migrating methods in Collections

[Ron Pressler]

> On Dec 21, 2015, at 6:20 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> 
>> 
>> 
>> 2. If methods are to be removed (as in made partial), instead of
>> magically disappearing them at the call site based on usage, perhaps we
>> should consider hiding them by source-code version (not from the class
>> file, of course, only hiding them in javac)? This is an explicit
>> decision to break source compatibility, but it has two mitigating
>> factors: 1/ javac conveniently has a source level (which, I hear, will
>> also result in hiding new methods starting with Java 9) and 2/ Java
>> already breaks source compatibility from time to time. I had quite a few
>> classes that didn’t compile under 8 because 8 changed the name
>> resolution rules wrt static imports (or, more precisely, made them
>> conform to the JLS, whereas they hadn't in prior versions). It took me
>> some time to figure out what was wrong, but hidden methods would be able
>> to give much better error messages.
>> 
> 
> 
> 
> 
> I'm not sure I'm following what problem you're trying to solve here? 
> (This sounds a little like the tricks we did with default methods when 
> compiling with the jdk8 compiler in -source 7 mode, where we didn't 
> consider default methods to be members of the class for some purposes 
> when viewed from 7 code?) Can you elaborate?
> 

Sure. Instead of demoting, say, remove(int) to a partial method, simply hide it from all source level 10 code, which will only be able to access removeAt, even on a List<String> (the method will still be in the class, of course). Cons: breaks source compatibility (but not binary compatibility) in a more major way than ever before, but Java has mechanisms to deal with that (source level), and automatic migration tools should be easy. Pros: less strange than partial methods; simpler to implement; a more general (albeit crude) migration mechanism, or, rather binary-compatible source-deprecation mechanism.


Now, it is a dramatic break, but Valhalla is quite dramatic anyway. Partial methods are a migration measure (we wouldn’t have needed them had the APIs been designed with values in mind, right?) but they’ll stay a part of the language forever, and they don’t have the general usefulness of default methods (unless there are non-migration reasons to make use of partial methods that make sense in Java).


> Yeah, this is what I meant by "Even though this works, its still not 
> that obvious." 
> 
> 
> inference concludes U=Animal, so everything is fine.
> 

Well, it’s obvious now… :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20151221/b86e8dac/attachment.html>