We Keep Coding

Different ways to access database in Java

There are a lot of technologies to access data using Java.
I was reading about some of them, including:
JPQL
HQL
Criteria API
Querydsl
jOOQ
JaQu
JDBC
ActiveJDBC
Now I am really confused because of the overhead. What are the main differences and similarities between these technologies? Which are most commonly used? Short comparison is more than welcome.

The fundamental foundation for database access in Java is JDBC. It is an interface (no implementation) that permits database vendors to expose their databases in a standard way, so Java programmers don't have to radically alter their code to support different relational databases.
That said, it accepts SQL, and SQL is standard, with so many variants that the standards do not permit cross database portability.
The rest of the platforms tend to build upon JDBC in an attempt to ease the cost of integrating with other databases. The numbers of ways one can interact with a database is varied, basically you get improvement on issuing SQL commands or the additional library takes over the writing of a compatible SQL command for you.
The two major categories are "database like" and "object storage" where object storage focuses on you storing a Java Object, and the libraries take care of most of the details of SQL generation.
Technology / query language / type / notes
Java Persistance API / JPQL / object store / not an implementation, but an interface allowing multiple implementations, query language is not table specific, but object specific
Hibernate / HQL / object store / a popular Java solution, but tied to Hibernate only.
Java Persistance API / Criteria API / object store / Criteria API is the code (programming) equivalent to the JPQL strings.
Java Persistance API & JDO / QueryDSL API / object store / Java API to build queries similar to Criteria API, but different
JDBC / jOOQ / direct JDBC / Java API that replaces SQL strings construction with method calls that are table centric
H2 database / JaQu / object store / Linked directly to one database, non-portable. Follows Microsoft LINQ syntax.
JDBC / ActiveJDBC / object store / Looks like a branded version of almost-JPA for webapps.
The two fundamental APIs in this space are JDBC and JDO, where the subset of JDO you wish to use if you are only going to support relational databases is JPA. Neither JDBC nor JDO provide a database connection directly, they are pure-play APIs. That said, a lot of database vendors push their APIs which don't leverage these technologies, I would advise not using any technology that isn't based on JDBC and JPA.
Again to leverage multiple implementations, I would also advise that you not use a query language that isn't based on JPQL (if you build queries in Strings) or the CriteriaAPI (if you build queries in code), both which are conceptual components of JPA. If you are using JDBC directly, use PreparedStatements for all issued SQL, and keep in mind that while you may be able to leverage your existing SQL codebase with a pure JDBC solution, you will likely get a better quality implementation (and possibly faster delivery) using JPA, because there are lots of corner cases in mapping Relational Databases to Java that very few existing database codebases handle.

Do not write JDBC code.
You will never do a better job of it than MyBatis and/or Hibernate.
Instead, learn and use either MyBatis or Hibernate.
MyBatis is simpler (and most likely sufficient for anything you will need) and Hibernate has a million features (none of which you probably need).

Using JDBC API and registering your DB class and making the connection.
Using Datasource, where you define DB details on your server like WebSphere or Weblogic
server And you lookup the defined datasource.
Using some ORM framework like Hibernate.

Can you run hibernate without a database set up?

I am currently working on an application that uses hibernate as its ORM; however, there is currently no database set up on my machine and I was wanting to start running some tests without one. I figure since hibernate is object/code based that there must be a way to simulate the DB functionality.
If there isn't a way to do it through hibernate, how can this be achieved in the general case (simulation of database)? Obviously, it wont need to handle large amounts of data, just testing functionality.

Just use an embedded DB like Derby
Maybe you could also try to use an ODBC-JDBC bridge and connect to an Excel or Access file, on Windows.

Hibernate is an object-relational mapping tool (ORM). You can't use it without objects and a relational database. Excluding either one makes no sense.
There are plenty of open source, free relational databases to choose from:
MySQL
PostgreSQL
Hypersonic
Derby
MariaDB
SQLite
You're only limited by your ability to download and install one.

Other options are using in-memory database like H2 / hsqldb

I assume you have hidden all the ORM calls behind a clean interface.
If you did, you could simply write another implementation of that interface backed by a Map that caches your objects.
You could then utilize this in your test environment.
But I have to agree with #duffymo, you should just go through the 'first pain' and set up a proper working enviroment.

I'm using H2. One of its major advantages is the use of dialects that simulate the behaviour of the more common DBs. For example - I'm using PostgreSQL and I define the dialect for Hibernate to be PostgreSQL. I'm using it for my integration tests - in each test I create the data that fits my scenario for this test, which is then erased pretty easily. No need to rollback transactions or anything.

Hibernate and SQL portability

I'm new in persistence and I'm reading the book "Pro JPA 2". I read that the problems of Java and JDBC pack is that
SQL is not portable
Tight coupling between Java code and SQL
The irony of JDBC is that, although the programming interfaces are
portable, the SQL language is not. Despite the many attempts to
standardize it, it is still rare to write SQL of any complexity that
will run unchanged on two major database platforms. Even where the SQL
dialects are similar, each database performs differently depending on
the structure of the query, necessitating vendor-specific tuning in
most cases.
My questions are:
IS the problem linked with SQL portability is still so critical?
As I understand, Hibernate, TopLink and other frameworks also have to create SQL queries from their metadata (annotations). How they arrange the problem linked with SQL portability?
Java & JDBC tight-coupling means that developer have to write SQL queries. Do I understand it correctly?
Thank in advance for your responses )

Yes the problem is with tight coupling between SQL and code and is very critical to project because if we need to migrate from one database to other without ORM, we need to change all the queries in the application.
Hibernate, TopLink and Other ORM Solutions converts your java code into SQL Queries and fires them to the database, but they are more standard and well tested so instead of directly working on Queries we can rely on ORM tools which will convert our code into queries and abstracts us from the complexity. So it is a good idea to use ORM tools instead of directly writing queries.
Yes, Java & JDBC tight-coupling means that developer have to write SQL queries directly which are not portable, and at time if the database layer changes you need to change all the queries. Instead if you use ORM solutions you can migrate to any database supported by ORM directly, by just changing some XML or configuration files.

SQL portability will be an issue if you ever need to switch to different database.
It is easy to think that you will never switch but that can be costly. I've been on projects that assumed the database would always be vendor x but later vendor y database was needed also. Lots of painful, tedious, rework was required to make application work with both databases.
I recommend that you always use standard SQL and/or use an ORM tool that writes only standard SQL.
My ORM, sormula, always creates standard SQL. If you've developed an application with sormula, all that is required to switch databases is to change the jdbc jar.

Using EntityManager with Table API

I'm working on a Java webapplication and want to access the database (PostgreSQL) via an database API for security reasons. The API of the database is built by database functions.
How can I call the API functions with an EntityManager? I figured out a way with native queries, but I think then there is not much left of ORM. Is there a way for example to lead the entityManager.persist() method to one of the database functions?

This is not a good idea. The entire point of JPA is to standardize the way the database is accessed and mapped to the Object layer. If you want to use native DB functions then you should use JDBC, possibly via SpringJDBCTemplate or some other tool that eases some of the pain. If you really feel like punishing yourself though, you could always create your own implementation of EntityManager and use that in your classes.

Hibernate project implementation

I am developing a project at Java fresher level.
I had to implement database interaction using Hibernate.
At the first stage, I started using HQL query language. But, later I come to know about Criteria queries through my previous questions.
But, still after learning Criteria, I am not getting what are the steps I should follow to fill and fetch data to and from database.
In fact, what are the packages and classes I need to develop manually and the script or query I need to write to fill/fetch data if I am given a database and table in it, using Criteria ?
Please also tell me, where would be difference when I use different database like PostGresql or MySQL within steps.

In fact, what are the packages and classes I need to develop manually and the script or query I need to write to fill/fetch data if I am given a database and table in it, using Crieteria?
Create an object model and map it to the tables using either annotations or xml mapping files. Classes that can be persisted are called Entities. Using the reverse engineering module of Hibernate Tools, it is possible to generate them.
Create instances of entities, set their attributes and use session.persist(Object) to persist them to the database to "fill data". Use the Criteria API to read from the database and fetch data. Data access is typically done in a data access layer using the DAOs pattern. DAOs expose finders and CRUD methods (Create, Read, Update, Delete).
If all this is new to you, I'd suggest to use Spring, it provides useful support classes and will help you to structure your application following the above pattern. Have a look at the Chapter 12. Object Relational Mapping (ORM) data access.
Please also tell me, where would be difference when I use different database like PostGres or MySQL within steps.
If their physical model differs, you may have to change the mapping of entities. Apart from that, switching from one database to another would require using the appropriate JDBC driver, changing the connection string and the Hibernate dialect (i.e. this is more a matter of configuration).