How do I stop @RooToString using ReflectionToStringBuilder?

[menno.j]

When I use @RooToString and look at the generated toString aspect declaration, it's using a ReflectionToStringBuilder. Disappointing to say the least. I had expected it to generate a toString that didnt use reflection at run-time (for performance reasons), else what is the point of using aspects?

Any way of telling it to build a toString which doesnt use reflection?

Cheers,
Menno

[Alan Stewart]

@RooToString used to introspect fields but this slowed down the shell for projects with a moderate amount of entities. The reflection kkethod works OK in most cases. If you don't need a toStriing method, you can opt out or simply override it on classes where there are nested objects

[menno.j]

Hi Alan,

Thanks for the explanation.

Most of the projects I have worked on it is not acceptable to use a ReflectionToStringBuilder for runtime performance reasons. It is even banned at some sites in their coding standards. So most developers end up using the IDE to generate a toString implementation which uses a normal StringBuilder. So I was hoping we could use the @RooToString to avoid this boilerplate code in our classes. Which I thought was one of the benefits of using Roo.

Perhaps the choice between using introspection and reflection could be added as an element of the @RooToString annotation, with reflection as the default? This way a developer can have some entities which need a non-reflection toString for performance reasons, and others where reflection is ok.

Also what exactly slows the shell down when using introspection? Isn't the introspection only required when an entity has a new member is added or an existing member is changed?

Cheers,
Menno

[Alan Stewart]

Also what exactly slows the shell down when using introspection? Isn't the introspection only required when an entity has a new member is added or an existing member is changed?

Any change to any java file causes metadata notifications to occur in the whole project and every ITD is re-generated in memory, compared to what is on disk, and re-written out if it differs. This is whether you have 2 entities or 2000. Generating toString metadata was a very expensive operation as is with web scaffold metadata. The previous code was cumbersome and unrelaible in generating a proper toString method and so we got rid of it in favour of a simpler solution. From testing, and googling, it appears the RefectionToString builder also has recursion protection.

In most cases runtime perfomance is good, but if you have deep nestings, I can appeciate there would be a performance hit. In these cases you can exlude fields in the RooToString annotation and these will be as added to the commons builder as excluded field names, or you can of course push-in refactor the method and provide your own. There were a lot of other more important issues to solve at the time, like multi-module maven support and JSF capability, than to pour a lot of effort for a toString method.
Alan