I think JPA remains unfinished for the moment mainly for political reasons. The final draft has been accepted if I remember correctly. Anyway you can choose what you prefer but I think you went a little bit too hard on Hibernate. I know the JDO community don't like Gavin King and have their own vision but Hibernate is a true masterpiece. It is very lightweight so you don't have a lot of depencencies on the framework itself. You would just have a lot of configuration information to migrate but right now Hibernate is the "de facto" standard in the persistance area for most people so I guess you won't have to migrate in the near future.
On a side note, what I like about JPA is that finally there is a first official Java aspect. Just hope to see more in the future (transaction, security, pooling, remote access, ...) so everything can run in a standard VM and you don't have to deal with the complexity of what you don't want. Well I am wandering far away from JSF right now but well I really like AOP :) I agree with the JBoss guys, this is the future of middleware services. On 4/5/06, Jonathan Harley <[EMAIL PROTECTED]> wrote: > Werner Punz wrote: > > Jonathan Harley schrieb: > >>Indeed. Because JPA is such a limited standard (only covers > >>relational datastores, for one thing), > > > > Actually that is not quite true, JPA is not really limited > > to relational datastores > > Well, I suppose not but its query language is (yet another) dialect > of SQL and it uses SQL and relational terminology throughout its > annotations. It's clear what its designers had in mind. > > >>JDO products as well as > >>Hibernate and Toplink will offer many extensions to the JPA standard. > >>Users will have a choice of using proprietary extensions (in the > >>case of Hibernate and Toplink) that lock them in to one vendor, or > >>standardised extensions (JDO) that give them a wide choice of vendor. > > > > Exactly, but the point is, there are no key issues why you have to lock > > yourself into it. > > In the future it probably will be, that it is best to code against jpa > > and use the extensions wisely, if needed (and in most cases it wont be > > needed) > > I disagree; I think it will be almost impossible not to use vendor > extensions. Take lazy loading, for example. JDO 2.0 defines exactly > which fields are available when an object is used while "detached" > from the store, and defines the exception which is thrown if client > code tries to access a different field. In Hibernate, whether access > succeeds depends on whether the field was already loaded, but a lazy > loading exception is thrown if not. In JPA, no particular behaviour > is defined, the spec merely observes that it might be "unsafe". If > you're using Hibernate JPA, no doubt you'll get the PROPRIETARY > Hibernate lazy loading exception, but using another vendor you > might just get null. > > Maybe this discussion is wandering a bit far away from JSF. The > point I wanted to make is that if you like JSF because it's a > standard which gives you the choice to change vendor (and that's > certainly one of the things I use to persuade our clients that JSF > is good) then you should also look at standards for other areas > such as persistence. JPA is obviously worth a look, but right now > it's unfinished and seems to me quite poorly thought out. > > > Jon > -- > ..................................................................... > Dr Jonathan Harley . > . Email: [EMAIL PROTECTED] > Zac Parkplatz Ltd . Office Telephone: 024 7633 1375 > www.parkplatz.net . Mobile: 079 4116 0423 > -- Alexandre Poitras Québec, Canada
