Thank you Harald, for adding some real good perspectives. > enhancement is a major nuisance in OpenJPA. It is, by user-(un)friendliness. It is not, by the value it adds to runtime. That enhancement is not user-friendly is our fault to get the ergonomics right. The internal process that really enhances the bytecodes is pretty solid.
> I'm spending valuable time explaining to my team why this is needed, You may have known/told these but let me reiterate few strengths of build-time enhancement. Firstly, enhancement adds real value to runtime. Even if there are niggles/wrinkles or outright pain in enhancing, once that pain is gone, when the code finally runs in a production box -- the application runs faster. a) performance -- there is no proxying, no virtual point arithmetic, no extra overhead on the application objects -- which could be accessed trillion times in a process lifetime b) memory footprint -- no double copy of data c) if remote client can afford/allow OpenJPA runtime, a better merge() operation > Why should users have to learn about extra build steps when they could do > without? Given everything a persistent object goes through in its life, to mange it with transaction warranty and that too transparently from the user application -- a managed agent *must* be present -- it could be subclassing, it could be proxying, it could be source code generation, it could be bytecode enhancement. Bytecode enhancement is the most powerful and most performant. The other vendors who had taken strong position in the past against byte-code enhancement, had later used the same technique in one way or other. So the question to ask is: are we OK with suffering a development hiccup to build a better application? My experience tells me that a little effort to integrate build-time enhancement in this age of massive automatic build environments goes a long way. > The most manifest problem with build-time enhancment is that it makes > your entity JAR depend on OpenJPA. This is a no-go when you use (parts > of) your entity model with different JPA providers. This could be a hairy problem, but often solvable via configuration. Tell us more about the scope and isolation via classloaders and the domain itself via persistent units, then we can have a more concrete discussion. Thank you again for bringing some real good points. ----- Pinaki Poddar Chair, Apache OpenJPA Project -- View this message in context: http://openjpa.208410.n2.nabble.com/Problems-with-load-time-enhancement-and-Spring-s-TomcatInstrumentableClassLoader-tp6554347p6588167.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
