Code generation with giant CRUD

Tom Klaasen10to1

www.javapolis.com

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”

6

www.javapolis.com

The problem

“Our domain model will likely contain a few hundred classes”

7

www.javapolis.com

The problem

“Oh, and we’re not sure which parts will stay generic and which won’t”

8

www.javapolis.com

The problem

“And please, have it done in 3 months, with 4 developers”

9

www.javapolis.com

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

10

www.javapolis.com

The problem

“(And don’t wait for the data modellers either. We really don’t have any time.)”

11

www.javapolis.com

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

13

www.javapolis.com

The problem

Result: 2000+ lines of code per domain object

For 4000 domain objects

Who wants to type these in?

14

www.javapolis.com

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?

15

www.javapolis.com

Other constraints

2 years ago: beginning of 2005 Java 1.4

16

www.javapolis.com

The approach

Generate everything But: make it possible to hand-code

everything Attribute definitions: in the DB

17

www.javapolis.com 18

DB Domain.java

DAO

.jsp

FormAction

Manager

.hbm.xml

Flow.xml

DB Tables

Generation process: first generation

www.javapolis.com

The tools

AppFuse + AppGen Ant XDoclet Hibernate

Home-written Access tool

19

www.javapolis.com

The tools

XDoclet: extended with custom annotations @gui hidden=”false” @relation mandatory=”true”

20

www.javapolis.com

Disadvantages

Ant: messed-up build scripts XDoclet

2 ‘design decisions’ for each information to be passed

slow

21

www.javapolis.com

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

22

www.javapolis.com

The end situation

2318

DB Domain.java

.jsp

.hbm.xml DB Tables

www.javapolis.com

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

24

www.javapolis.com

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?

25

www.javapolis.com

Conclusion

Code generation can make you flexible and responsive. Do try this at home.

(Or at work)

Q&AView JavaPolis talks @ www.parleys.com

Thank you for your attention