Werner Punz wrote:
Jonathan Harley schrieb:
Werner Punz wrote:
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.
It is not perfect, but since most people proably will settle around
OpenJPA, Hibernate and the RI, I do not see this case exactly as a big
problem, because all three are opensource.
Anyway there are areas where a fix is needed, but that does not mean
that the JPA is a bad API,
Sure it does! Having problems is exactly what makes a bad API. Being
less powerful than previous APIs and current implementations also
makes a bad API. JPA is a "lowest common denominator" standard.
of all attempts to unify the ORM OODB layers
under a common standard this is one of the best so far.
Well, I disagree, I've given one concrete example and
there are plenty more. Just saying "it's really good" won't do.
It's a subset of JDO and a subset of Hibernate. I for one am
disappointed about that. It's true that there will be excellent
products based on it, some open source - but most of the best
things about those will be the parts that extend the standard.
One could argue that the same is true of JSF - a lot of the things
in tomahawk are there to cover deficiencies in the JSF standard. I
think that reveals a problem with the standard - it should never
have mandated the HTML tag library, with its table-based rendering,
reliance on JavaScript, XML-breaking id tags and so on. To me,
the brilliant things about JSF are the extensible architecture and
use of POJOs/dependency injection. Maybe the standard should have
focussed just on these.
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.
No standard is ever finished, JSF 1.0 was a huge construction site,
but with its third
incarnation (1.2) it is getting where it covers most grounds currently
needed.
I agree, JSF 1.0 had problems and 1.2 is looking better, and I look
forward to future versions getting better still with techniques from
facelets and AJAX being incorporated. 1.0 standards always have their
problems. I just think it's a shame that the EJB people took a "not
invented here" attitude to some of the good things in JDO and made some
mistakes that could easily have been avoided. So far, I'm hopeful that
that isn't happening in the JSF world, as the JSP/JSF specs seem to
be much more open to using the best ideas around.
Jon
--
.....................................................................
Dr Jonathan Harley .
. Email: [EMAIL PROTECTED]
Zac Parkplatz Ltd . Office Telephone: 024 7633 1375
www.parkplatz.net . Mobile: 079 4116 0423
