Please have a look at our presentation at EclipseCon Europe: http://www.slideshare.net/kthoms/recipes-to-build-code-generators-for-nonxtext-models-with-xtend
Sample projects here: https://github.com/kthoms/xtend-codegen-examples

~Karsten

Hi

You give no indication on the kind of Java code you want.

If you just require class structure, UML2Ecore will enable you to get standard EMF Java generation to do good things.

You can enrich your UML model with OCL constraints and bodies and these should propagate through UML2Ecore into the Java. You can choose interpreted OCL or use OCL2Java to embed direct Java code.

If you require state machines or other advanced UML facilities, you need to look at 'real' UML code generators. I'm not aware of any that have exploited the OCL2Java capabilities.

Regards

Ed Willink

Hi

UML2Ecore should suit you well. NB there is only a default constructor, since EMF imposes default construction then property-by-property assignment in order to support generic loading from XML.

You can add Java bodies manually. Or you can use OCL definitions within your OCL, or merged from a separate OCL document. The OCL tooling is autogenerated from a UML class structure model and an OCL document defining invariants. The OCL2Java in principle supports all normal OCL (no @pre, oclIsNew, oclIsInState) but as I use it more and more, I steadily find bugs to fix.

Regards

Ed Willink

A simple "translate UML to Java" approach is just naive and does not have any benefit in practice. That is also why you won't find good approaches.

What kind of classes would you expect? While "normal" classes could be translated to POJOs that is usually not what you'd expect. Normally code generation from UML makes more sense when it is domain specific, with a profile. Then a class could be mapped to some persistent technology, like Hibernate or whatever. Or how would you map relationship kinds aggregation vs. composite? This is semantically a huge difference, while its implementation might be different approaches possible.

A simple "translate UML to Java" approach is just naive and does not have any benefit in practice. That is also why you won't find good approaches.

If you would start to describe a mapping from UML to Java you will very soon experience that this is too ambiguous how an implementation would look like, especially if you don't work with a proper profile.