Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 12025 invoked from network); 18 May 2007 00:43:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 May 2007 00:43:50 -0000 Received: (qmail 45284 invoked by uid 500); 18 May 2007 00:43:56 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 45249 invoked by uid 500); 18 May 2007 00:43:56 -0000 Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: open-jpa-dev@incubator.apache.org Delivered-To: mailing list open-jpa-dev@incubator.apache.org Received: (qmail 45240 invoked by uid 99); 18 May 2007 00:43:56 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 May 2007 17:43:56 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of mprudhomapache@gmail.com designates 64.233.162.238 as permitted sender) Received: from [64.233.162.238] (HELO nz-out-0506.google.com) (64.233.162.238) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 May 2007 17:43:49 -0700 Received: by nz-out-0506.google.com with SMTP id j2so1133889nzf for ; Thu, 17 May 2007 17:43:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=uCskwgo5848bi+7NuXOzmtYrjn2W/1+b0jeLf+/TeNJto4ZC1rJq5sfDbWprR3T2C6iWZ4KKSzTq5kTxIdoQmB9OimOPvlUrHAPR4hauK83tPAKXRR5GFDaQJgl1Ck/qZ9wzgqVKQnDVyjdr25cOpP16zAB1LUpQK/xcJ81Z+Lk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=Nfse9tnnXPJ1JCmb/pa7DibBQmwRzuF5QseV+6crPe9IJCy1W1FDs4IWBd8YI9Kc9y+E7Uvb7sFLPWnbyCHHGDBPdk9DxtfSISr1MBiErq0YQEFetQPgEDxPdn4gdz8ijZ5iB0hTDvqLON0Dj7Xgw7rm+y5AJCsavncfgGN+/44= Received: by 10.65.183.7 with SMTP id k7mr5220177qbp.1179449008335; Thu, 17 May 2007 17:43:28 -0700 (PDT) Received: from ?192.168.15.100? ( [66.248.222.34]) by mx.google.com with ESMTP id e1sm1091884nzd.2007.05.17.17.43.27; Thu, 17 May 2007 17:43:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <464CF3F2.30905@bea.com> References: <10660986.post@talk.nabble.com> <7262f25e0705170819i8a52d61x7f772ccca97ab6dc@mail.gmail.com> <464CF3F2.30905@bea.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marc Prud'hommeaux Subject: Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate) Date: Thu, 17 May 2007 17:43:10 -0700 To: open-jpa-dev@incubator.apache.org X-Mailer: Apple Mail (2.752.3) Sender: Marc Prud'hommeaux X-Virus-Checked: Checked by ClamAV on apache.org On May 17, 2007, at 5:31 PM, David Ezzio wrote: > I think that the issues raised are best solved with tools, > documentation, and examples. > > Of course, if one has been coding to Hibernate for years, it's > unlikely > that any combination of tools, documentation, and examples will make > OpenJPA easier to use for that person, but that's not the standard. Sure it will. If you are using one JPA implementation, be it Hibernate, Toplink, or anything else, and you want to "drop in" OpenJPA to test it out and see what the performance difference is, if it doesn't work immediately, you are likely to walk away. I think that easing the process for someone already familiar with JPA to get started with OpenJPA without having to pour through documentation about build-time tools or runtime agent flags is a supremely useful project, especially at this point where we are on the brink of graduation and will soon be getting a lot more attention. > Another important point, in my view, is to make sure the tests run as > well on Windows (without cygwin!) as they do on Linux, Unix, and OS/X. > For example, using File.separator to construct resource path names > works > great on everything but Windows. This seems orthogonal to the issue of easing OpenJPA's bytecode enhancement process. If you find cases where we are relying on hardcoded UNIX paths, these are obviously bugs and should be handled by creating JIRA issues. > David > > Marc Prud'hommeaux wrote: >> >> I think this is a very worthwhile project. James and a few others >> excoriated me about this issue over beers after JavaOne last week, >> and, >> while the bruises from their rhetorical assault are still healing, >> their >> observations about the comparative "out of the box" ease of use >> OpenJPA >> compared to other systems definitely bears attention. >> >> As Patrick mentioned, we aren't too far away from being able to use a >> dynamic subclassing approach. >> >> Another option I've been thinking about recently is that in JDK >> 1.6, you >> can dynamically attach an agent at runtime to your own JVM (using an >> implementation-specific mechanism), and using the provided >> Instrumentation, you can redefine existing methods in classes, even >> after the classes have already been loaded. While you cannot add or >> remove methods or fields, we might be able to re-work our >> PCEnhancer to >> use a newly-generated inner class and a lookup in some >> IdentityHashMap >> to perform the same function. E.g., instead of our currently enhanced >> class: >> >> public class SomeEntity { >> private String someField; >> private StateManager stateManager; // generated >> >> public String getSomeField() { >> return pcgetSomeField(this); >> } >> >> // generated method >> private static String getSomeField(SomeEntity entity) { >> if (entity.stateManager == null) >> return entity.someField; >> else >> entity.stateManager.getField(1, entity); >> } >> } >> >> >> we would instead do something like: >> >> >> public class SomeEntity { >> private String someField; >> >> public String getSomeField() { >> return GeneratedInnerClass.pcgetSomeField(this); >> } >> >> private static class GeneratedInnerClass { >> >> private static String getSomeField(SomeEntity entity) { >> StateManager stateManager = GlobalIdentityMap.get(entity); >> >> if (stateManager == null) >> return entity.someField; >> else >> stateManager.getField(1, entity); >> } >> } >> } >> >> >> From the brief amount of time I've spent thinking about this, I >> think >> we can get 99% of the way there with our current approach. >> >> The remaining 1% is a situation where if someone creates an >> instance of >> SomeEntity *before* we ever initialize the BrokerFactory (and thus >> perform the re-definition of known entity classes), we might get >> passed >> an entity instance that isn't persist-able (since you cannot >> redfine the >> methods for an already-created object, only for objects that will >> subsequently be created). >> >> >> In summary, we have 3 different possibilities for removing the >> requirement for build-time enhancement and launch-time agent >> specification: >> >> 1. Use reflection: considerably slower, would require drastic >> rework of >> all our interaction with PersistenceCapable instances, but wouldn't >> require any fancy class-generation/enhancement >> >> 2. Dynamic subclassing: easier to implement, but would require >> people to >> use property accessors for everything, and wouldn't support >> EntityManager.persist(someInstance) >> >> 3. Dynamic agent attachment and class re-definition: more >> difficult to >> implement than #2, and would require JDK 1.6 + JVM >> implementation-dependent attachment mechanisms, but might provide the >> most functionality >> >> >> Does anyone have any thoughts about this? Especially any new ideas >> for >> other ways to do this would be very interesting for all of us to >> hear. >> >> >> On May 17, 2007, at 8:19 AM, Patrick Linskey wrote: >> >>>> 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? >>> >>> Not particularly hard. There are a few APIs that would break for >>> some >>> cases, but it's even pretty straightforward to do a subclassing >>> approach for property-based access type without losing much >>> performance -- the only cost in that configuration is with >>> persistent-new instances. >>> >>> -Patrick >>> >>> On 5/17/07, 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 >>>> ------- >>>> http://macstrac.blogspot.com/ >>>> >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/the-pain-of-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 Nabble.com. >>>> >>>> >>> >>> >>> --Patrick Linskey >>> 202 669 5907 >> >> > > > Notice: This email message, together with any attachments, may > contain information of BEA Systems, Inc., its subsidiaries > and affiliated entities, that may be confidential, proprietary, > copyrighted and/or legally privileged, and is intended solely for > the use of the individual or entity named in this message. If you > are not the intended recipient, and have received this message in > error, please immediately return this by email and then delete it.