> On Dec 21, 2015, at 6:20 PM, Brian Goetz <[email protected]> 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… :)
