Software not being free. Is YOUR software free and "not proprietary"? If so, how do you finance it? How do you earn a living? And why are you doing it?
Some is proprietary, some is open source. The service never is free. New features development is paid for by customers, even for open source stuff.
But I insist in using free software when possible. And I wont select a commercial alternative if there aren't strong reasons for it.
Also, I really believe in the power of Java EE specs. I wouldn't choose Java, which isn't the best language, if it didn't come with all of this: JSRs, RI, often multiple implementations, strong community, etc. I'm not just talking about the free stuff that you'll randomly find on the internet (and I count Spring in that), that isn't part of Java EE. I'm talking about the standardization process. The fact that there is a standard way of writing 90% of most applications, whatever the specific implementation is.
Only one implementation. How many people actually do use alternatives to Hibernate and why? Because they used to use TopLink for the last 20 years and the learning curve to switch to Hibernate is too high?
For the 5 last years or so, I didn't see anything but JPA. No Hibernate or Toplink specific stuff, or marginally. In fact, I only saw Hibernate a few times as an implementation, my last clients being with Eclipselink/OpenJPA. Lastly, I did a quite complex JPA POC on Glassfish/Eclipselink, that I later ran on Websphere/OpenJPA without problems.
You make it sound exceptional and difficult. It really isn't.
No public review. Who exactly is "public", and what are their main interests? (Do note that a major driving force for the JDK is Credit Suisse, for instance. What is your stake and relation with Credit Suisse?)
I've never been involved in the JDK, but I did give my opinion more than once for Java EE specs (JPA, JSF, EJB). Quite easy to do, the simplest but non-unique way being specification mailing lists, implementation development discussions, etc.
Only one body involved in its evolution. Do you say that to YOUR customers also, about your own software?
Whenever some big amount of work has been done, definitely. There is always at least one backup plan.
Anyway, this is not about my customers, but about yours ;-) I understand that you make it sound better than it is, but you'll understand that I don't :-D
SQL-oriented - and then "as a serious professional". What's not serious about SQL? In fact, SQL is reviewed by more entities than the JLS, let alone the JPA specs. Have you ever thought about that?
Sure, but the spec isn't even as strong. Just look at the differences between db vendors, how Oracle judges that it can violate 'details' (empty string is null, anyone?), etc.
I'm not underestimating SQL importance, but I strongly believe that there should be some abstraction from SQL in any serious application, whether OO or anything else.
More basic. Fair enough. But don't forget: You probably replaced your sophisticated EJB 2.0 framework by a more basic one, which was (at the time) proprietary, had only one implementation, had no public review, nor multiple bodies involved in its evolution. It was called Hibernate, prior to JPA.
It wasn't hibernate in my case, but anyway. Then came some evolution. It was long ago and I'm not going back.
Oh, and if JPA has to be learned fully, then I challenge you to also FULLY learn SQL, including all the SQL:2011 clauses, regardless of whether they're part of your specific implementation. Because as a serious professional, you shall fully learn SQL. And while you're at that, learn also everything about execution plans, and join, fetch, buffer caching, cursor caching and all other sorts of algorithms. Because there is no excuse for not knowing which SQL transformations are generated by your database's CBO.
I'm constantly learning, and am aware of a great deal of that. Still, if I write bugs by ignorance of SQL standards, I won't have any excuse for that.
(oh, and I sincerely hope you're neither a Windows, nor a Mac user, because that wouldn't be free, and there is only one implementation of each OS, and no public review, and only one body involved in their evolutions.)
I do run Windows, mostly because of Office than anything else. I'll welcome any serious alternative that doesn't look like it's 1992, but that's another stoy.
Anyway, I don't have any dependency on it. All my code builds and runs on linux on all my client infrastructure.
As a conclusion, I'd say that I don't even understand why someone would choose JOOQ over JPA. Why would you pay for something that's non-standard/proprietary when the alternative is free.
There is room from improvement in JPA. Why don't you just try some suggestion on the spec mailing list?