openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
Date Thu, 17 May 2007 23:43:54 GMT

Could extract from this verbiage the scenarios you'd like supported?

Do you need to run tests inside IDEA and have you classes enhanced  
after IDEA compiles them for you?

Do you need to run in a separate jvm, e.g. from maven, and have the  
classes enhanced as they are loaded?

I think the second of these can probably be made to work without any  
openjpa code changes by doing the same thing geronimo does, running  
with an enhancer agent that delegates to the openjpa enhancer as  
appropriate.  I'd imagine that if IDEA creates a new classloader for  
running the tests, and we can get some access to something about it,  
it ought to be possible to do on the fly enhancement there also.

What exactly are the problems with looking at an enhanced class in  
IDEA?  I haven't run into them....but I may not have been trying to  
debug the enhanced classes but rather openjpa + geronimo.

david jencks

On May 17, 2007, at 2:39 AM, James.Strachan wrote:

> Firstly before I start, openjpa is a great piece of software; I'm
> particularly fond of the documentation and in particular the query  
> language
> parts. The CSS for the site is also awesome :)
> However compared to hibernate, openjpa is still pretty painful to  
> use from
> an end users perspective and I don't think this should be the case;  
> plus I
> don't think it'll take much time to fix. While the pain is still  
> fresh in my
> mind I thought I'd post on how much more painful openjpa is to use  
> in a
> project. If you're short on time, the basic idea is its that  
> bytecode post
> processing stuff thats to blame :). Yes I know its probably faster  
> that way
> - its just so painful for Java programmers to work with. (And yes I  
> know one
> day we'll all have IDE plugins that hide the bytecode stuff etc etc).
> So the first thing is having to mess with your build (ant or maven)  
> to get
> the post processing properly integrated. Depending on if you have  
> persistent
> entities in your main or test area this can often trip you up a  
> little (as
> it did me). I don't know about folks on this list but the whole  
> idea of
> having to mess with my maven build gives me the jitters :). When  
> you get
> that far & the maven planets are aligned with openjpa, the next  
> hurdle you
> hit is how do you run stuff in your IDE. If like me you use IDEA  
> and maven
> 2, the project gets auto-created by default for all projects you  
> work on.
> However these don't work when you use openjpa as you hit the  
> dreaded 'cannot
> function at all as you've not run the up front bytecode post  
> processor you
> dummy!' type error when trying to run stuff in your IDE.
> So you then add the maven-generated classes to the front of the  
> classpath in
> your project. Hooray, after a day or two's work, you can now  
> actually use
> openjpa in your IDE and your build. YAY! The downside is that now when
> navigating around your Java code, whenever you navigate into an  
> entity bean,
> IDEA shows you the bytecode - not the source code as its confused  
> since the
> bytecode generated stuff is different to the source code it knows  
> about. So
> now you're faced with a dilemma - choose between navigating nicely  
> around
> your source code - or being able to actually run/debug your  
> application. I
> won't even get into the refactoring pain or having to continuously  
> run maven
> builds while developing code to avoid getting code completion/ 
> compile errors
> etc. (I prefer to keep in my IDE where possible).
> Compare this whole malarkey with hibernate. You add hibernate to  
> your pom,
> generate your project and you're good to go. No messing with your  
> project
> build; no messing with some secret ninja IDE stuff to be able to  
> actually
> run & debug your code while still being able to actually navigate the
> source. It just works. Now it might work in a crappy & slow way and  
> openjpa
> might be way way more efficient and powerful and whatnot - but I'd  
> rather
> have a cheap car that just works than a ferrari that you can only  
> drive on a
> tuesday if its sunny, but not too hot and refuses to even start if  
> its wet.
> FWIW I've just given up using openjpa for development; its just way  
> too
> painful. (I'm even hacking projects I work on so I use openjpa in  
> the maven
> build but explicitly switch to hibernate in development mode; yeah  
> its more
> work but at least I can use my IDE properly again).
> I'm cool with putting post processing into the build system (though  
> that
> should really only be an optimisation); but please can we have some
> inefficient but usable reflection/cglib type approach so folks can  
> easily
> switch from hibernate to openjpa (and stay there) without pulling  
> out our
> hair & swearing too much - or sneaking back at the first  
> opportunity to get
> an easy life?
> Please don't take this mail the wrong way - I truly want openjpa to  
> be a
> success, its a great piece of software. Its just a bit too hard to  
> use out
> of the box right now. I'd truly like it to be trivial to switch from
> hibernate to openjpa and never have to go back.
> How hard is it to add a reflection/cglib type alternative to the  
> upfront
> bytecode generation (like hibernate does) to save us from the
> development-time pain?
> -- 
> James
> -------
> -- 
> View this message in context: 
> post-processing-bytecode-%28another-beg-for-a-simple-reflection- 
> cglib-alternative-like-hibernate%29-tf3770760.html#a10660986
> Sent from the open-jpa-dev mailing list archive at

View raw message