>> With Java 8's defender methods / extension methods, these problems should >> be gone. > > Cool :-) Only ... it will be 2018 until I can use that release ...
Well, if 2018 is the next time you upgrade Java, then you have 6 years without any worries about JDBC API evolution ;-) >> This looks like the existing JDBC API to me. Re-implementing that might be >> a bad idea in terms of usability and compatibility. > > Well, duh. I introduced the API in my code so that my mapper would work with > more than a single version of Java (I was supporting 1.4, 5 and 6). But if > you only plan to support Java 8, then that's of course not an issue for you. jOOQ officially supports Java 6+. Any help making jOOQ runtime backwards-compatible to 5 or even 1.4 is very welcome. However, I might not be able to integration-test that. > Which means to me that I'll have to fork. I don't mind; I have lots of forks > here. It's just frustrating to have to do it because of so few lines of > code. I will re-read these threads again after my vacation to have a clearer view about the various requirements. Remember, it's a few lines of code for you, but a dozen of unit/integration tests for me and more (potentially confusing) API for all the other users. So it's worth thinking about these things twice (without a pina colada in my hand) :-) Stay tuned, and maybe send a patch for me to better understand what you're trying to do with your API enhancement. Cheers Lukas
