>Sorry, but you're the one that is wrong, it is not only about actually calling methods with types, it is about the
presenceor absence of those types when the JVM does decide to resolve the symbolic reference (eg when you reflect the
declaredmethods). I am about done with this discussion. I think the onus is on you to prove this scheme will work, not
forus to prove it won't work (which we already did). Your prove should not only include simple direct instance access,
butalso when using reflection **which is very common with JDBC drivers** (eg connection pools, tools/libraries that
bridgedifferences in JDBC implementations, etc).
I agree that this thread is done, because I already provided a proof that my hypothesis works (the link was published
yesterday),and my hypothesis never said that reflection would work. Whether or not reflection is MANDATORY for JDBC
alsois a fruitless discussion, as all of you WANT it to be supported.
>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.
I do not. You fear risks that do not exist if you go 100% with the JDBC specifications words, but I accept that you
liketo be safe from several uncertainties, so it is OK if we skip my idea and go with a different approach -- even when
Iam still convinced that it would be correct and working (but not for things you just WANT to support like reflection).
-Markus