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.
