Am Montag, 9. Juli 2012 18:22:09 UTC+2 schrieb Lukas Eder: What I'm most confused about: This discussion started off with JDK 7 > (JDBC 4.1) incompatibilities. That was an actual issue, and I hope > jOOQ 2.4 had resolved that. Then it was about separation of concerns. > Then, about cloning Configurations. Maybe I just don't understand your > problem domain, while you already tell me solution proposals? And now > you expect me to say "You're right"? :-) >
These topics are loosely connected. I have a talent to pick at code and find the sore spots really quickly. When I start to pull, there is a ripple effect. It drives project owners insane but often, I'm right and the reason why it's not changed is because it's too much effort. Then things stay broken which drives me insane. > Yes, that would be a nice design for client code. Instead of > implementing ConnectionProvider, you could implement DataSource (or > wrap it) and handle the transaction all the same. void > run(Configuration) would become void run(Factory) for now... > Which leads back to where this whole discussion started: Client code can't implement DataSource because the interface changes with every version of JDBC and that means you must have a build system which can compile code differently per Java version. Only, there is no standard build system for this, so every project must invent their own wheel. My solution: Create a wrapper instance that doesn't depend on the Java version and which accepts DataSource from the current runtime - no more dependency on the Java version. Does my solution suck? Yes. Does implementing JDBC interfaces suck more? Hell, yes. Can we get Oracle to stop this? Not likely plus the past is already broken. So my solution causes the least amount of pain and it even gives users of Java 1.4 a chance without an additional cost on your side. Regards, A. Digulla
