Traditional way:

* Plain JDBC, as if no frameworks used:
Your Java code and your SQL code are tightly coupled. SQL code tor prepared statements are kept in Java code as string constants, parameters set as numbered values into prepared statement. Prepared statement is executed, results are retived from ResultSet explicitly. There is no or limited code reuse. 
Pros: very flexible
Cons: expensive to support, especially in cig production systems.

* If framework is used:
Set of classes created and fields/methods are annotated for database persistence. Framework preprocessing applied to extract structure and relationship, data model is extracted and database is created. Java application speaks to framework layer, which speaks to database. 
Pros: somewhat flexible
Cons: structure change is painful

DBAction way:

SQL code is stored separately from Java code, in a file of action definitions:
<SQL code here>

DBAction object is created by parsing action definition:
<Java code here>

Java application keeps Object properties in a form of key-value pairs [or provides Map interface for DBAction].
<Java code here>

<try now>