3. Tom Klaasen
Works professionally with Java since 1999
Co-founder of 10to1 (http://www.10to1.be)
Has worked on a project involving a lot of
code generation over the last 2 years
tom@10to1.be
www.javapolis.com
5. The question
Who wants to type in 1000+
Java class files?
www.javapolis.com
6. The problem
Mission: “Create generic CRUD screens for
a domain model”
www.javapolis.com 6
7. The problem
“Our domain model will likely contain a few
hundred classes”
www.javapolis.com 7
8. The problem
“Oh, and we’re not sure which parts will
stay generic and which won’t”
www.javapolis.com 8
9. The problem
“And please, have it done in 3 months, with
4 developers”
www.javapolis.com 9
10. The problem
“And use RUP. But don’t wait for the
analysts to finish their job, because we
don’t have that kind of time”
Change your code when the Use Cases are
finished
www.javapolis.com 10
11. The problem
“(And don’t wait for the data modellers
either. We really don’t have any time.)”
www.javapolis.com 11
12. The problem
Domain model with 500+ classes
Each class: 1 interface, 2 implementations
Relations between those objects are first-
class citizens
Also 1 interface, 2 implementations
Some classes have a lot of performance-
gaining methods
Fine-grained getters and setters for the relations
Each class has 10+ attributes
Each needing a getter and a setter
www.javapolis.com
13. The problem
For each domain class:
DAO
Manager
FormAction
form.jsp
searchform.jsp
list.jsp
editflow.xml
Another 1000 lines of Java, JSP and XML
code
www.javapolis.com 13
14. The problem
Result: 2000+ lines of code per domain
object
For 4000 domain objects
Who wants to type these in?
www.javapolis.com 14
15. The problem
Most of the constructs will change over
time
4000 x 2000 lines of code are subject to change
Who wants to make these corrections?
www.javapolis.com 15
16. Other constraints
2 years ago: beginning of 2005
Java 1.4
www.javapolis.com 16
17. The approach
Generate everything
But: make it possible to hand-code
everything
Attribute definitions: in the DB
www.javapolis.com 17
18. Generation process: first generation
.hbm.xml DB Tables
.jsp
FormAction
Domain
DB
.java
Flow.xml
Manager
DAO
www.javapolis.com 18
19. The tools
AppFuse + AppGen
Ant
XDoclet
Hibernate
Home-written Access tool
www.javapolis.com 19
20. The tools
XDoclet: extended with custom annotations
@gui hidden=”false”
@relation mandatory=”true”
www.javapolis.com 20
21. Disadvantages
Ant: messed-up build scripts
XDoclet
2 ‘design decisions’ for each information to be
passed
slow
www.javapolis.com 21
22. Improvements
Maven
Clean project structure
FreeMarker
More flexible than XDoclet
Read directly from the DB
Don’t always generate everything
More and more hand-coded ‘generic’ files
As knowledge about the domain grew
www.javapolis.com 22
23. The end situation
.hbm.xml DB Tables
Domain
DB
.java
.jsp
www.javapolis.com 18
23
24. The pros
Always flexible
When no knowledge available: generate
everything
Override with hand-coded parts where necessary
When patterns and securities arise: hand-code
them in a generic way
www.javapolis.com 24
25. Comparison with other solutions
Hand-code everything (and every change)
Hire a lot of code monkeys
Design everything generically, correctly the
first time
And good luck with that
Trails
Code is not generated
Thus impossible to override
Rails (with JRuby)
This started in 2005, remember?
www.javapolis.com 25
26. Conclusion
Code generation can make you flexible
and responsive. Do try this at home.
(Or at work)
www.javapolis.com