I have a project that I'm working on currently using Tomcat, Spring 4, Spring Security, MySQL, and JPA w/ Hibernate.I picked JPA from the standpoint that it's suppose to make swapping out the underlying implementation of ORM providers seamless, or at least less painful. I would say that this is  mentally using the spec over the implementation (JAX-RS) is the default standpoint of the Java development community.I'm curious if this is really a task worth doing. I'm sure if I used Hibernate directly I would gain some power because I could use features that are not part of the main JPA specification.Part of my concern comes from the idea of YAGNI. I'm essentially programming in a specific style and fashion (using JPA instead of Hibernate) so that at some point in the future I can swap out my ORM implementation. I severely doubt that will ever happen over the life of the product, so I'm essentially putting effort into something that I'll probably never reap the benefits of.What are your thoughts? Is programming to the interface worth it when it comes to stuff like JPA? Have you ever actually swapped an entire ORM implementation in a product? Have you ever been able to completely avoid the abstraction from something like JPA leaking anyways? I personally have a single native SQL call already (to clean out the database tables), and there's somethings I'd like to futz with that are built into the JPA spec (get/set prefixes to your methods, and the difference between MEMBER OF/IN, which only binding myself to an underlying implementation will get me any chance of avoiding.
Is staying implementation agnostic really worth it?
programming practices;jpa
so that at some point in the future I can swap out my ORM  implementation. I severely doubt that will ever happen over the life  of the product, so I'm essentially putting effort into something that  I'll probably never reap the benefits ofIn my experience, the typical enterprise project never swaps out:DatabaseORMLanguageI don't know the numbers, but the percentage of 2-tier apps I've seen implement and then change one of those things would probably be less than 10%. If it happens, it is rare, and it usually happens within the first 2-3 months of the project when people are still in discovery mode. Most systems I know are still running on their original platforms 8-10 years later. More often than swapping out an ORM, do you want to know what I've seen more of? Removing the ORM completely to drop down to SQL due to performance issues. So no matter what, in that case, your gonna be rewriting stuff.As far as implementation agnostic, its a myth. It really amounts to dumbing down. So my approach is to embrace the data layer. Make it a first class part of your language and design. It makes for happier, more successful projects.