I have created an issue for this: https://github.com/jOOQ/jOOQ/issues/5233
Giving this more thought, I'm positive that these experimental methods should be removed again. They did much more harm than add value. 2016-05-04 14:51 GMT+02:00 Lukas Eder <[email protected]>: > For the record: I have now tried to avoid the single-argument DSL.field() > method wherever possible in jOOQ's internals (about 20 occurrences), with > the following effect: > > Ordinary compilation (mvn clean install) time of jooq.jar: > > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 02:43 min > [INFO] Final Memory: 19M/316M > [INFO] > ------------------------------------------------------------------------ > > "Improved" compilation time of jooq.jar: > > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 02:21 min > [INFO] Final Memory: 18M/221M > [INFO] > ------------------------------------------------------------------------ > > So, there's a small but already significant improvement for ourselves, > which is certainly an additional motivation to get this right. An even > better effect is obtained if I remove all of the 22 DSL.field(Row[N]) > method overloads: > > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 02:14 min > [INFO] Final Memory: 20M/321M > [INFO] > ------------------------------------------------------------------------ > > These results would certainly favour the removal of said methods, which > might be fine, as they're documented as being "experimental". The existing > experimental behaviour could be restored e.g. via postfix notation: > > row.field() > > > Or by avoiding the overload: > > DSL.rowField(row) > > > I'm still hoping there will be a more optimal fix, but this one certainly > does look viable. > > 2016-05-04 13:55 GMT+02:00 Lukas Eder <[email protected]>: > >> Hi Samir, >> >> Thank you for bringing up this topic again. Yes, the issue still persists >> with jOOQ 3.8. >> >> I must admit, it has slipped off my radar. The issue didn't appear very >> pressing, as it doesn't happen often (only when using Java 8 with untyped >> plain SQL in deeply nested expression trees). But you have a valid point >> about new users running into this issue by accident and then getting the >> "wrong" impression. Besides, even users who know about this issue will >> accidentally run into it again and again, if they make frequent use of >> plain SQL, which probably happens more often than I would have expected. >> >> The problem is not the DSL.field(String) method itself, but the >> field(Row[N]) overloads that were introduced in jOOQ 3.6. Unfortunately, >> field(String) is very popular and useful, while field(Row[N]) is much less >> so, so while deprecating field(String) would help send the right warning to >> the user, it will also be rather annoying. I had rather removed >> field(Row[N]), which is, unfortunately, not possible if following a strict >> understanding of semantic versioning... >> >> I can see that there is a need (which I underestimated) for action here. >> But I'd like to also be clear about priorities. field(String) is *very* >> useful to many users... >> >> What other options do we have? >> >> 2016-05-04 6:44 GMT+02:00 Samir Faci <[email protected]>: >> >>> I know I've brought this up before and there's been some discussion on >>> this list >>> <https://groups.google.com/forum/#!topic/jooq-user/grv6Wu_sFtA>, stack >>> overflow and more then a few bugs opened on JDK to resolve this but I >>> thought I'd chime in since it's been a few months. >>> >>> Related articles / posts: >>> >>> >>> - >>> >>> http://stackoverflow.com/questions/34223249/slow-compilation-with-jooq-3-6-plain-sql-and-the-javac-compiler >>> - >>> http://stackoverflow.com/questions/30707387/troubleshoot-slow-compilation >>> >>> >>> @Lukas correct me if I'm wrong on this... >>> >>> The combination of jooq 3.6 and java 8 ( I believe as of jooq 3.7 Java 8 >>> is required? ) allows for using certain patterns that destroys your build >>> time. >>> >>> In other words these patterns: >>> >>> field("name"); // bad >>> field("name", String.class); // acceptable >>> Table.NAME; // auto-generated code, better but that's a personal opinion I >>> don't think there's much of a difference in this and the line above >>> >>> >>> >>> I assume this is an issue with jooq no matter which backend is used (ie. >>> mysql, nosql, postgres..etc ). >>> >>> My original post was from December and I haven't seen any progress from >>> Oracle to address this issue. >>> >>> ------------------------------ >>> >>> >>> Seeing as JDK's development cycle is outside of anyone's control on this >>> list, I wonder if it would make sense to at least mark the generic >>> field(String) as deprecated. >>> >>> I've seen this bring the build time as high as 35 minutes for a project >>> that would take 2-3 minutes at most with jooq 3.5. >>> >>> It's such a subtle bug and not very obvious for a new user to discover. >>> >>> If I were to pick up Jooq for the first time and running an updated >>> environment I'm most likely running Java 8 with the latest version and >>> noticing a horrible build time. It would be nice to at least update the >>> javadoc to mark it as deprecated and maybe redirect the user to a better >>> pattern to use pending an Oracle update? >>> >>> >>> Any thoughts from the Jooq developers / community. >>> >>> >>> -- >>> >>> Samir Faci >>> >>> PS. I saw Jooq 3.8 was released, I haven't tried that yet, but I assume >>> it suffers from the same limitations. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "jOOQ User Group" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
