Hello community I have now evaluated two options of decreasing verbosity with aliasing:
1. Replace classes by interfaces. Tables stay static members, fields are methods in tables: https://sourceforge.net/apps/trac/jooq/ticket/688 2. Replace static members by instance members and let generated tables return copies of themselves from the as() method: https://sourceforge.net/apps/trac/jooq/ticket/117 Option 1 has the advantage that it is easier to use polymorphism for custom extensions as suggested by Sander, even remote ones like Postgres' (multiple!) table inheritance. The disadvantage is that fields would always be followed by parentheses(), and besides, this would be a major change in jOOQ's internal architecture, with risk of major bugs. Option 2 has the advantage that it is easy to implement in jOOQ and does not touch jOOQ architecture. Only the code generator needs to be slightly adapted, and one or two jOOQ internals. I currently don't see any disadvantage at all. Besides, this has proven to work well for QueryDSL, a similar framework as jOOQ, with more focus on general querying rather than full-fledged SQL. See the discussion with Timo Westkämper here: https://groups.google.com/forum/#!topic/jooq-user/VNyevvq6MmY In order to reduce the implementation risk and the impact on the API, I have chosen option 2 and will not implement #688. The choice whether to generate static or instance members is up to the user. This will be a jooq-codegen parameter, which defaults to "instance members". Even when upgrading to jOOQ 2.0, you can continue using the static model. A complex sample query involving quite a bit of aliasing and subquerying can be found in my most recent blog post: http://lukaseder.wordpress.com/2011/11/14/jooq-meta-a-hard-core-sql-proof-of-concept/ Beta testers are very welcome! Download the latest snapshot here: https://oss.sonatype.org/content/repositories/snapshots/org/jooq/ Cheers Lukas
