Texo/Design Concepts/Runtime Model Approaches

Different approaches for linking pojo's and the runtime model

While designing and developing Texo different approaches have been tried to integrate pojo's and the runtime model. The current approach (generating separate wrapper classes which a Model interface) is chosen because:

• best performance (compared to other approaches): all model access method calls are direct method calls which are compiled together with the rest of the code (so the java compiler can optimize).
• manually changable: all the model access code is generated and can be changed by the developer. Texo will maintain/keep manual changes when re-generating the code.
• simple/easy: adds no complexities at runtime (no special class handling) and requires no special setup when building (the generated code is just simple java classes).

Here is a description of the other approaches which have been tried or considered (and an argumentation why they were not used):

• generate model annotations in the pojo: this fits very nicely in the Java annotation concept (use an annotation to attach metadata to a class). The reasons for not choosing this solution:
  • will add compile time dependency of the pojo to Texo annotations.
  • to call the correct getter/setter at runtime java reflection needs to be used. Method calls using Java reflection are about 100 times slower than non-reflection calls.
• use class enhancement at runtime: so at runtime add the implementation of a Model interface to each pojo. The reason that this approach was not chosen:
  • this means that also a different classloader has to be used for Texo generated classes. Many frameworks (OSGI, Seam, ORM-solutions) also make use of class enhancement and their own classloading specifics. The feel is that there is too much risk in trying to integrate Texo runtime class enhancement with possibly unknown frameworks that want to make use of Texo.
  • when developing against the Model api you need to cast to the Model interface (as there is no , so you loose a bit of compile time checking.
  • possibly loose optimizations done by the java compiler when building
  • the implementation of the model interface can not be changed by the user (currently the Model wrapper is also generated and can be adapted by a user, the manual changes are maintained when re-generating).
• enhance classes at build time: (see the very interesting Lombok project), the reason that this approach was not chosen:
  • we would force the user to change the build setup. Although Lombok and Java makes comparatively easy, build setup is a topic which should not be underestimated, so any change there is avoided as much as possible.
  • the class file is not insync with the source code, so debugging is more difficu