Hi Timo, Thanks for your feedback.
> The problem with interfaces is that they need to be managed. In a > generic Bean populating environment they cannot be instantiated. There will always be "beans" backing the interfaces. These ideas haven't been worked out in detail yet, but I'd imagine there will be plenty of factory methods allowing for accessing backing beans. For instance, Creating a new record is simple: <R extends Record> R Factory.newRecord(Table<R> table); With the T_TREE example this would translate to a call similar to this one: TTreeRecord record = create.newRecord(TTree.T_TREE); This factory method is already available in jOOQ today. So the move from beans to interfaces is backwards-compatible to a great extent. Also, interfaces allow static final members, so today's static final singleton instances of Tables, Fields, etc will probably still be available, too. Managing those types is up to the client code. These things can be achieved one way or the other with frameworks like spring, for instance. I don't know enough about my client's integrations of jOOQ, but I don't think there will be major problems. > Maybe they could be an alternative to generated beans or bean > implementations could be provided for the interfaces. That's a good point. With interfaces representing tables/fields, client code can inject new implementations into jOOQ. I don't see the immediate use-case, but I can imagine that this opens up new possibilities... Have you had similar thoughts for QueryDSL? Your generated artefacts are also modeled as classes, not interface, if I remember right? Cheers Lukas
