Thanks for your reply.
Setting the -javaagent doesn't seem to be doing much different. We're still measuring the same result. Setting the weaving.output as you suggest is not making any difference either. I'm even wondering if I've set it up correctly since there's nothing being written to the weaving directory I've configured. I can't seem to make that work.
Now, given the fact that invoking the .toString() method explicitly on the joda LocalDate object instead of concatenating the object as such seems to make a difference, we've also have been looking further into that: We've obtained the LocalDate code (through decompilation) and it seems like they have implemented a toString via annotation... perhaps that in combination with the eclipselink weaving is making the runtime go nuts or something.
In any case, we have a workaround for now. But the issue is still intreaging to me...
My guess is it is an ASM issue. EclipseLink uses ASM for byte code weaving, ASM probably encounter some byte-code it did not understand, causing it to generate something invalid.
You can try disabling weaving, using "eclipselink.weaving"="false" to confirm this.
You could try upgrading to 2.4 or 2.5 as there has been some ASM changes. Otherwise, your workaround of removing the offending byte-code is probably best.