Thursday, November 09, 2006

Just say no to DynaBeans

The subject of DynaBeans just came up on the mailing list, and it is one I've been asked about before - so I thought I would do a blog my answer.

Dynabeans was written as a solution for Struts back in 2000, they are not JavaBean compliant – thus they have no value outside of that provided with commons BeanUtils, thus coupling your enterprise system to BeanUtils forever – no other apps are aware of them, or able to script them like they can JavaBeans. They cannot be used with any database schema mapping tools, so you cannot easily leverage db schema generation tools. JBRules 3.0 has no support for mapping utilities thus you’ll only be able to script those from within evals. If you only use evals you will have crippled the engine to work like a simple chain of command scripting engine – under no circumstances do I recommend this. Evals are a worst use case for conditions that cannot be expressed in field constraints, as field constraints and conditional elements become more powerful the dependency of evals is reduced. Further more DynaBeans are backed by a map, each read or write results in a hashmap read or write – this is not a scalable solution.

A much better solution that works now for JBRules 3.0 is to have runtime class generation. See this blog entry here:

Tools like cglib make this trivial now:

BeanGenerator bg = new BeanGenerator();
bg.addProperty("foo", Double.TYPE);
bg.addProperty("bar", String.class);
Object bean = bg.create();

That produced bean can have hibernate mappings generated at runtime, so you’ll get runtime hibernate support. JBRules can compile drls at runtime using the classloader those beans where generated with thus providing full field constraint use of them and pojo like access in the consequence - much nicer :)

For JBRules 3.2 we will provide a feature called FactTemplates – this is akin to jess/clips DefTemplates. These allow people to define Facts without the need for a compiled class, which is preferable to some who want complete encapsulation of their rules and business objects within the drl. FactTemplates are backed by an array and thus read/writes are much faster. FactTemplates support both named and int values to specify the field for the value; named set/get result in a HashMap lookup so have similar performance to DynaBean. However JBRules provides compile time optimisation of those named fields and swaps them to int lookups – we will have support for this in the JFDI language too, which we also hope will be support in jBPM. FactTemplates will also provide mapping facilities which means they can be mapped to any underlying structure – be it JavaBean, a Hashmap or a DynaBean.

Post Comment


  1. Greetings, Programs:

    Congratulations on putting FactTemplates into version 3.2 of JBRules. The ability to create an object within the rules themselves is the first step to allowing the rule writer to extend the Java classes that have been pre-defined for him. Even though this is default for Jess and CLIPS and some others, it is critical for such products as JRules and Blaze Advisor where they don't have time to wait for a Java programmer to add the Java class in order for the Business Analyst to write a rule that needs a new object. Well, those are my thoughts, anyway. Good luck,


  2. We don't have mapping capabilities yet, from JavaBeans to FactTemplates, but it is something we hope to do eventually.

  3. How can I use runtime generated class (using BeanGenerator) in a drl file? I thought that I should import all classes I want to use inside drl script, but at the moment of writing drl file I don't know class name (it will be created by BeanGenerator). Is there any working example using this strategy?

  4. Usefuul information, thank you!

  5. Once you have traveled, the voyage never ends, but is played out over and over again in the quietest chambers. The mind can never break off from the journey.Flights to Addis Ababa