I just checked out the Xtend code generator and I do have to say it is easier to understand and may use it as starting point for my own code generation. My compliments to Digulla. Right now I tried to look into using jOOQ's code generator to just generate simple static String constants for table and column names that have no jOOQ dependency. String constants are nice because you can use them in Annotation arguments. When you regenerate the code string constants from the database and your code doesn't compile then you know that there is a mismatch.
I looked at the generator (albeit briefly) but felt like I would have to almost rewrite the generator to do such. -Adam On Wednesday, October 10, 2012 10:59:46 AM UTC-4, digulla wrote: > > Am Mittwoch, 3. Oktober 2012 15:06:30 UTC+2 schrieb Lukas Eder: > > I think I'm ready to take a superficial stand on this topic. >> Essentially, I can say that Xtend / Xtext will not be added as a >> dependency for jOOQ 3.0's code generator. I feel that these >> technologies are not >> >> 1. stable enough (Aaron himself pointed out various flaws repeatedly, >> e.g.: http://blog.pdark.de/2012/10/02/xtend-for-java-developers/) >> > > Just like with any technology, Xtend has flaws. From my experience, the > advantages outweigh the flaws. > > >> 2. independent enough (They create additional required compile-time >> and runtime-dependencies) >> > > We'd need a version of Xtend on Maven Central but that shouldn't be a show > stopper. Other projects need the same plus the generated code doesn't have > any dependencies. The dependencies are only necessary when someone works on > the code generator itself. > > I understand that you're reluctant to add new dependencies to jOOQ > (because problems in them will end up on your mailing list) but, as always, > it's a question of "how much do I get and how much do I have to pay?" > > >> 3. java enough (The tools impose a new non-Java but Javaesque syntax. >> jOOQ is about Java) >> > > Correct. Java simply doesn't have what it takes. You CAN write a > Mandelbrot Set generator in SQL (you can find the query in my blog > somewhere) but is that a SMART thing to do? All languages are Turing > complete. That doesn't mean you can solve each problem with an equal amount > of effort. > > >> 4. interoperable enough (Xtend / Xtext code cannot be mixed with Java >> code) >> > > Bullshit. I'm extending Java classes from Xtend and I'm extending Xtend > classes in Java. The output of Xtend is pure Java. What gives you the idea > that Java isn't compatible with Java? > > While they seem to be nice tools to be used in highly specialised >> client environments, they cannot be imposed on a broader audience. >> > > Code generators are a specialized niche. There are people who believe that > you can write and maintain code generators in Java but these people simply > don't know what they're talking about or they have unreliable memory. > > >> However, the need for improved customisability of the code generator >> have been well received. What Aaron has shown to me proves that it is >> relatively simple to create a highly extensible, generic code >> generation API that allows for arbitrary artefact generation >> overrides. It should be possible to override default code generation >> with any other Java-based means, including Xtend / Xtext. >> > > ... as long as you don't care about maintenance. Sure, Xtend is pure Java, > so you can do everything in plain Java. > > I implemented your code generator in ONE WEEK. How many months did the > Java version take? How often did you try to fix something just to break it > even worse? If you compare my code to the Java version, which one can you > understand? > > >> I have also thought about moving away from string-based source code >> generation. For instance to the way XJC does with an object-oriented >> Java syntax model. I don't think jOOQ should go down that path either, >> as code generation isn't necessarily about Java (think of generating >> Scala, XML or any other code/document type). > > > All this approaches have one major drawback: You need many lines of code > to produce one line of output. When writing a flexible code generator, your > tool should fit the bill. I bet you don't use a road train to go shopping. > Unlike all the other tools, Xtend was designed to write code generators. > > Yes, it's a moving target. Yes, there are flaws. > > But ... > > All the other solutions have much bigger flaws. I've been writing code > generators for 20 years. I wrote them in C, tcl, Python, Java, Perl, ksh, > XML/XSLT, AST-based approaches (like XJC), JSP. They all had one major > drawback: You couldn't mix source code with templates. > > We all hate JSPs. They suck. But why? > > - There is no good editor. > - If you make a change, it's hard to see what the result will be. > - You don't reliably get compile errors in the editor > - You need to deploy the file to a web server (edit -> deploy -> wait 5 > minutes -> test) > > Xtend is a lot like JSPs but it doesn't suffer from these because there is > a good editor. Code is compiled right away as you type (and more complex > validations happen when you safe it). There is code completion, even inside > templates. The code is readable (unlike JSPs) because you can indent it. > Unlike JSPs, the output is also readable. > > Regards, > > A. Digulla >
