On Wed, 17 Jun 2015 22:47:23 +0200, "Markus KARG" <markus@headcrashing.eu>
wrote:
> Sorry but you're wrong here.
>
> Vladimir's example was invalid. See
> https://gist.github.com/mkarg/88a89ae0dbffcfb7543e instead.
>
> Resolution will not fail. Even early static resolution won't. Check
again
> the chapter of JLS about the critera to throw the listed exceptions.
None
> of them is met with the corrected example
> https://gist.github.com/mkarg/88a89ae0dbffcfb7543e.
>
> The direct example will NOT fail on Java 7 as the method is not changed,
> but added. The original method is still in place. Both methods exist at
the
> same time and differ by signature, hence the linker of the old program
> finds the old method in the new class. No problem at all.
>
> The indirect example will NOT fail on Java 7 as a JRE 7 client will
never
> pass in an instance of a JRE 8 type (how should even know of its
> existence?), and the Java 6 machine executing the invoked method will
never
> INSTANTIATE that type so it will not fail. No problem at all.
>
> Still should work. You'd possibly like to set up a proof using the
> corrected example https://gist.github.com/mkarg/88a89ae0dbffcfb7543e.
:-)
Sorry, but you're the one that is wrong, it is not only about actually
calling methods with types, it is about the presence or absence of those
types when the JVM does decide to resolve the symbolic reference (eg when
you reflect the declared methods). I am about done with this discussion. I
think the onus is on you to prove this scheme will work, not for us to
prove it won't work (which we already did). Your prove should not only
include simple direct instance access, but also when using reflection
**which is very common with JDBC drivers** (eg connection pools,
tools/libraries that bridge differences in JDBC implementations, etc).
It sounds like you want to trade minor complexity in the build/IDE process
for a world of hurt for the users of your driver. I don't think that is a
good way forward.
Mark