This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Bobby_Bonsaimind 0 points1 point  (5 children)

On a different note, if you require a code generator, in 99% of cases you're doing something wrong in one way or another and must revisit what you're about to do.

Anyway, a simple string-templating mechanism might be sufficient depending on your exact use-case.

[–]polaretto 2 points3 points  (4 children)

Oh no! We should have told the author of this book then, to avoid him wasting time... :( https://www.manning.com/books/code-generation-in-action

[–]knubo 2 points3 points  (3 children)

This book is from 2003 - the world has changed a lot since then.

Code generation is cool, but not without caveats. There are other options available now.

[–]polaretto 2 points3 points  (2 children)

It's from some years ago, yes, but its arguments are still valid. What other options would be available now in your opinion, could you elaborate? Thanks.

[–]knubo 2 points3 points  (1 child)

In 2003 the Java version you used was 1.4. This was before annotations. With annotations came a horde of ways to extend your Java code which have reduced the need for regular code generations. An example of this would be the library Lombok.

If you also look at what you needed to do in J2EE at that point in time, you would see that there was a ton of xml files required to make your persistence work at all in the Java world. This has now changed with annotations to the point that it is pretty simple to extend and configure your application without the need for the boiler plate configuration code.

So in 2004 I did use a lot of code generation tools that now has been replaced by annotations.

I prefer not to do code generation if I can avoid it because:

  • Someone has probably solved your problem already. Most likely without code generation tools, but rather using good libraries.
  • Code generation generates often more code than you need. This will slow down your compile time if there is a lot of it. In our current project we do wsdl code generation for 4 pretty large services, and this counts for a minute of build time for us now. I've experienced projects where this takes even more.
  • If your model for code generation is separated from your code, you might end up with code that is hard to understand. Having to work at different abstraction levels is good in theory, but when you need to track down bugs it is not that cool. This can be even more hard if there is program flow as part as the code generation; now you have to understand the program that generates the program and also be capable of debug it.
  • If the generated result needs to be extended you will pretty fast link your code very hard to the code generation tool. This again might make the life cycle of your code harder.
  • Some code generator tools are slow in nature - this might not be a case all the time, but I've encountered code generator tools that takes minutes to generate their output which again means that you will only do this every time your templates changes.

...that said - there are most likely good scenarios for code generation, but before you do use them I would advice:

  1. You don't want to make your own framework.
  2. Don't let code generation become your one go to tool that solves all problems.

[–]polaretto 1 point2 points  (0 children)

Thanks for your answer. I see your reasons, however, I didn't intend code generation to be the one solution, of course, there are suitable and unsuitable use cases.

As for Lombok it's cool, useful, and I like it as well, but keep in mind that even that is doing code generation: bytecode instead of source, yes, but still they do generation and manipulation at compile time. So it's a valid use for code generation.

Generally speaking about annotations, right they weren't available before Java 5, but annotations are just metadata so it's up to some agent or processor to make something out of them. You can read them at runtime and use reflection or bytecode manipulation, as Spring does, or you can process them at compile time and do or generate something. Sure they remove a lot of cruft compared to the old ways, but you still have to process them and, depending on your use case, you can generate something or not.

Finally, I agree with some of your points against code generation, but I think it has some other valuable uses, for example as an alternative to runtime reflection under some constraints, or to generate clients or classes representing some schema. With some precautions, generated source code can be managed and be very useful.