Code generation with giant
CRUD
Tom Klaasen
10to1

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

Overall Presentation Goal
Reducing typing with code
generation
www.javapolis.com

The question
Who wants to type in 1000+
Java class files?
www.javapolis.com

The problem
Mission: “Create generic CRUD screens for

a domain model”
www.javapolis.com 6

The problem
“Our domain model will likely contain a few

hundred classes”
www.javapolis.com 7

The problem
“Oh, and we’re not sure which parts will

stay generic and which won’t”
www.javapolis.com 8

The problem
“And please, have it done in 3 months, with

4 developers”
www.javapolis.com 9

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

The problem
“(And don’t wait for the data modellers

either. We really don’t have any time.)”
www.javapolis.com 11

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

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

The problem
Result: 2000+ lines of code per domain

object
For 4000 domain objects

Who wants to type these in?

www.javapolis.com 14

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

Other constraints
2 years ago: beginning of 2005

Java 1.4

www.javapolis.com 16

The approach
Generate everything

But: make it possible to hand-code

everything
Attribute definitions: in the DB

www.javapolis.com 17

Generation process: first generation
.hbm.xml DB Tables
.jsp
FormAction
Domain
DB
.java
Flow.xml
Manager
DAO
www.javapolis.com 18

The tools
AppFuse + AppGen

Ant

XDoclet

Hibernate

Home-written Access tool

www.javapolis.com 19

The tools
XDoclet: extended with custom annotations

@gui hidden=”false”

@relation mandatory=”true”

www.javapolis.com 20

Disadvantages
Ant: messed-up build scripts

XDoclet

2 ‘design decisions’ for each information to be

passed
slow

www.javapolis.com 21

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

The end situation
.hbm.xml DB Tables
Domain
DB
.java
.jsp
www.javapolis.com 18
23

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

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

Conclusion
Code generation can make you flexible
and responsive. Do try this at home.
(Or at work)
www.javapolis.com

Q&A
View JavaPolis talks @ www.parleys.com

Thank you for your
attention