We Keep Coding

Migrate Hibernate 5.2 to JPA 2.1

I want to remove direct Hibernate references from my Java EE 7 server application so that I will not have a compile-time dependency on hibernate-core in the future. As a replacement, I want to use the plain JPA API.
So far, I figured out that org.hibernate.annotations.Cascade and org.hibernate.annotations.CascadeType can be mostly transferred to the cascade-parameter of JPA's #ManyToOne or #OneToMany.
Also, org.hibernate.annotations.Type seems to be replaceable by a suitable JPA #Converter.
However, there are more usages of Hibernate in my code where I am struggling more:
org.hibernate.annotations.Immutable
org.hibernate.annotations.OptimisticLock
org.hibernate.annotations.DiscriminatorOptions
org.hibernate.annotations.Fetch
org.hibernate.EmptyInterceptor
Could you give me any hints if and how those can be migrated to JPA? Alternatively, links to a Hibernate → JPA migration guide/tutorial would be very appreciated.

You can't replace these unless you want to rewrite your application. You shouldn't try to avoid these annotations IMO as that would just leave you with a bad performing application that is probably still not portable. Hibernate is the de-facto JPA implementation, so I doubt you want to move away from it.

Using DashDB as a database (instead of a Data warehouse)

Note: This is not a programming question (at least at the moment). Once I start progressing further would seek assistance from the community on programming questions. Feel free to delete this, if this question is deemed inappropriate.
I am trying to start using DashDB as a Database on Bluemix. The DashDB data would be consumed by a Java/Java EE app
I am not planning to use this as a Data warehouse.
DashDB as I understand it has two flavours - Regular (using this term loosely here to refer to the standard offering ) and DashDB Transactional.
DashDB Transaction, i believe is used for transactional workloads.
I wanted to understand if JPA would play well with DashDB. I am unable to locate good information in this space.
Should we use denormalized design for both DashDB Regular and Transactional?

The dashDB Transactional Bluemix plan provides a dashDB database that is optimized for online transaction processing (OLTP). This means that it is designed for highly structured repetitive processing and it supports ACID transactions. That said you should use all the best practices you would use with a classic RDBMS: normalization, constraints and so on. I confirm that the dashDB-JPA integration is not well documented yet, but there should be no particular problem in using it with JPA. Since your application will run on Liberty Runtime, when you bind the dashDB service instance the server.xml is automatically configured with dataSource with a JNDI name and the database driver jars are also added.

JPA does not work seamlessly with DashDB today. DashDB uses organized by column be default and JPA does not work well with it. There is no specific way today to set organize by row using an annotation in JPA. We tried to override the DB2Dictionary but that did not work either.
If i drop the table using sql statement and recreate the table using sql statement appended with organize by row, then JPA is able to read the table.
Not sure who should be fixing this issue - JPA or DashDB :)

Use of Spring data JPA with maven in Eclipse

I'm new with Spring and I would like to use Spring Data with Jpa, Maven and Mysql in Eclipse environment. Then I'm going to use Tomcat as application server
I read a lot of tutorial but all of them are different from each other therefore don't understand what I have really to do. At the moment I'm confusing between these technology and DAO/DAL structure
Must I use Hibernate?
I have to use it with java JPA and then I have to add Spring data?
If anyone has an example or a tutorial I thank him.

Official spring data link
For spring-data-jpa,maven,mysql,hibernate,eclipse example tutorial
Hibernate is optional, it depends on your use case what you want to do. Its a ORM for mapping your db tables into java objects and have lot of other features like session caching, second level caching, criteria queries, validation, search/filters etc.
If you are just testing queries to load data you can use spring jpa queries directly, you will find examples in spring-data-jpa link

Is JPA enough to perform CRUD operations

For a few days, I have been researching JPA and Hibernate.
Now I got confused about JPA - Hibernate interactions.
I know JPA is a specifcation and Hibernate implements it. But the missing point is a working principles . I mean in a real application, what does hibernate do and what does jpa do ? I am trying to get below questions. Let me ask you;
Question 1 : Is JPA only abstract notion ? Does it consist of only interfaces? (I have observed that everyting is interafce in
javax.persistance package.)
Question 2 : Is JPA enough to perform CRUD operations ? (Is it possible to use JPA without Hibernate or etc.) If it does , why we need JPA providers such as Hibernate or etc. ?
Question 3 : And last one , I am searching for concrete something. I
need to know Database->JPA->Hibernate interaction. For
example while Saving and fetching something , What does happen in
background ?which one is performing database operations(hibernate or jpa) or which one is responsible for providing db connection ?
I mean, in jpa/hibernate based application , who is responsible for what?

Question 1:
Yes, exactly! JPA is just a specification as you already know. It only says what can be done but doesn't say how it should be done or doesn't implement any behaviour. You can use JPA annotations with javax.persistence classes but in the end when you run your application nothing will happen!
Question 2:
As I said above, JPA is just a blueprint saying what can be done. Hibernate, OpenJPA, Toplink etc. actually implement that specification. They perform the operations differently so there might be tradeoffs in speed etc. but all of them have to be able to perform the same set of operations specified by JPA. Some might give you more features but never less.
Question 3:
Again JPA isn't performing any actions, it just specifies what can be done. How it's done, how the code <-> db interaction is performed, what kind of SQL queries are created it's all implementation specific and will differ (for instance Hibernate might create different SQL queries for the same thing than OpenJPA). How your DB interactions are performed in the end is determined during runtime by the implementation (Hibernate). You can try to find it all in the documentations for the concrete implementation. You can also print the SQLs that are performed for instance.
You might ask "then why do I need JPA"? Well that's because you can (in theory!) change the implementation just by changing the jar on the classpath to a different library (i.e. from Hibernate to Toplink). In practice sometimes it's not that easy due to implementation specific features or how each implementation handles SQL queries, tables etc.

As you state JPA is just a specification, so there is no implementation but every Java EE container should support it ( implementation of JPA is included in application server ).
JPA implementations in Popular application servers :
Glassfish - EclipseLink (reference implementation)
JBoss - Hibernate
Websphere - JPA for WebSphere Application Server persistence, Apache OpenJPA
So when you are using application server you can use JPA interface to perform any CRUD operation through particular JPA implementation.
Tomcat does not support JPA out-of-the-box. You can use JPA in applications deployed on Tomcat only if these applications embed some JPA implementation. Or use Apache TomEE project which provide JavaEE features for Tomcat.
Remember that Hibernate has JPA implementation but also more addictional (cool) features. But if you are using only elements from JPA spec you can anytime easily switch to another JPA implementation.

As you mentioned yourself: JPA is a specification, Hibernate an implementation!
1: Yes, correct this is the technical part of the specification in form of Java Interfaces.
2: NO, JPA is not "enough", JPA can't do anything, it is just a specification.
3: An Interaction exists only between Hibernate and the Database (actually, there are other parts like the database driver involved, but don't mind...).
The idea behind this separation is you can write code that only uses the interfaces from javax.persistence. At one single place you (or maybe a container like an application server) define which implementation you want to use. This makes your application very portable, and you could choose to switch implementations as you like (theoretically, in practice it is never that easy...)

Embedding database operations in our framework

We started writing a Java Framework for our company. But we don't have enough experience about Java. We decided to use JPA framework for database CRUD operations.
What do you suggest about that:
about defining persistence.xml. We search creating dynamic
EntityManager and found some documents but we don't know that is
it best way.
Is it a good way that create a layer over JPA base db operations?
(for example CRUD methods.)
How can we do calling JPA CRUD methods from my CRUD methods in
framework?
We will use this framework for desktop and web applications. Is
deployment a problem for us.
Do we have to use EJB?
Is there alternative to JPA which you suggest? (example: ADF,JDBC)
Thanks

It highly depends on your requirements and what you want to do with your "framework". I do not know enough of your project to give you a real advise, but here are some thoughts:
What do you mean with "framework"? Are you developing a library which other people should use? What should be the purpose of your framework? Is it a data access layer for some of your company data? If so: JPA is a kind of a standard and might be a good fit since it is widely used. If other people should use your "framework" it is good to use something which is standard and used in many other applications and tools.
Do you really need a data access layer on the desktop? Do you have a rich client? It is no problem to just "deploy" the application to the desktop, but a data access layer must always be configured and (maybe) updated. And that's where the pain begins when you use a rich client. Users must configure a database, the database must be installed or accessible remote and the version of the client must match the version of the database. Sooner or later this will hit you.
What else have you considered already? What about a ORM? Hibernate might by a good and popular fit. Also eBeans which is used in Play! is very cool. If you make a CRUD applications, frameworks like eBeans are doing most of the work out-of-the-box for you. You create a model (just POJOs + annotations) and the frameworks provides the complete data access layer (including the database setup).