Theprogrammersfirst | A technical portal.

@Column The @Column annotation is used to specify the mapping between a basic entity attribute and the database table column. JPA defines rules for implicitly determining the name of tables and columns. For a detailed discussion of implicit naming see Naming. For basic type attributes, the implicit naming rule is that the column name is the same as the attribute name. If that implicit naming rule does not meet your requirements, you can explicitly tell Hibernate (and other providers) the column name to use. Explicit column naming @Entity(name = "Product") public class Product { @Id private Integer id; private String sku; private String name; @Column( name = "NOTES" ) private String description; } Here we use @Column to explicitly map the description attribute to the NOTES column, as opposed to the implicit column name description.

@CollectionTable The @CollectionTable annotation is used to specify the database table that stores the values of a basic or an embeddable type collection. @CollectionTable is used for the mapping of collections of basic or embeddable types. Applied to the collection-valued field or property. By default, the columns of the collection table that correspond to the embeddable class or basic type are derived from the attributes of the embeddable class or from the basic type according to the default values of the Column annotation. In the case of a basic type, the column name is derived from the name of the collection-valued field or property. In the case of an embeddable class, the column names are derived from the field or property names of the embeddable class. To override the default properties of the column used for a basic type, the Column annotation is used on the collection-valued attribute in addition to the ElementCollection annotation. To override these defaults for an em...

@Cacheable The @Cacheable annotation is used to specify whether an entity should be stored in the second-level cache. If the persistence.xml shared-cache-mode XML attribute is set to ENABLE_SELECTIVE, then only the entities annotated with the @Cacheable are going to be stored in the second-level cache. If shared-cache-mode XML attribute value is DISABLE_SELECTIVE, then the entities marked with the @Cacheable annotation are not going to be stored in the second-level cache, while all the other entities are stored in the cache. The value of the Cacheable annotation is inherited by subclasses; it can be overridden by specifying Cacheable on a subclass. Cacheable(false) means that the entity and its state must not be cached by the provider. Learn About Caching

Caching At runtime, Hibernate handles moving data into and out of the second-level cache in response to the operations performed by the Session, which acts as a transaction-level cache of persistent data. Once an entity becomes managed, that object is added to the internal cache of the current persistence context (EntityManager or Session). The persistence context is also called the first-level cache, and it’s enabled by default.

@Basic The @Basic annotation is used to map a basic attribute type to a database column. Basic value types usually map a single database column, to a single, non-aggregated Java type. Hibernate provides a number of built-in basic types, which follow the natural mappings recommended by the JDBC specifications. Internally Hibernate uses a registry of basic types when it needs to resolve a specific org.hibernate.type.Type. The simplest type of mapping to a database column. The Basic annotation can be applied to a persistent property or instance variable of any of the following types: Java primitive types, wrappers of the primitive types, String, java.math.BigInteger, java.math.BigDecimal, java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Time, java.sql.Timestamp, byte[], Byte[], char[], Character[], enums, and any other type that implements java.io.Serializable. The use of the Basic annotation is optional for persistent fields and properties of these types. If the Bas...

The @AttributeOverrides is used to group several @AttributeOverride annotations. @AttributeOverrides used to override mappings of multiple properties or fields. Example:     @Embedded     @AttributeOverrides({             @AttributeOverride(name="startDate",                                 column=@Column("EMP_START")),             @AttributeOverride(name="endDate",                                 column=@Column("EMP_END"))     })     public EmploymentPeriod getEmploymentPeriod() { ... }

The @AttributeOverride annotation is used to override an attribute mapping inherited from a mapped superclass or an embeddable. When AttributeOverride is applied to a map, "key." or "value." must be used to prefix the name of the attribute that is being overridden in order to specify it as part of the map key or map value. To override mappings at multiple levels of embedding, a dot (".") notation form must be used in the name element to indicate an attribute within an embedded attribute. The value of each identifier used with the dot notation is the name of the respective embedded field or property. If AttributeOverride is not specified, the column is mapped the same as in the original mapping. Example 1:     @MappedSuperclass     public class Employee {         @Id protected Integer id;         @Version protected Integer version;         protected String address;         ...

The @AssociationOverrides is used to group several @AssociationOverride annotations. @Target(value={TYPE,METHOD,FIELD}) @Retention(value=RUNTIME) public @interface AssociationOverrides Used to override mappings of multiple relationship properties or fields.         Example:     @MappedSuperclass     public class Employee {              @Id protected Integer id;         @Version protected Integer version;         @ManyToOne protected Address address;         @OneToOne protected Locker locker;              public Integer getId() { ... }         public void setId(Integer id) { ... }         public Address getAddress() { ... }         public void setAddress(Address address) { ... }         public Locker getLocker() { ... }...

The @AssociationOverride annotation is used to override an association mapping (e.g. @ManyToOne, @OneToOne, @OneToMany, @ManyToMany) inherited from a mapped superclass or an embeddable. JPA defines the @AttributeOverride annotation to handle this scenario. This way, the mapping conflict is resolved by setting up explicit name-based property-column type mappings. If an Embeddable type is used multiple times in some entity, you need to use the @AttributeOverride and @AssociationOverride annotations to override the default column names defined by the Embeddable. Considering you have the following Publisher embeddable type which defines a @ManyToOne association with the Country entity: Embeddable type with a @ManyToOne association @Embeddable public static class Publisher { private String name; @ManyToOne(fetch = FetchType.LAZY) private Country country; //Getters and setters, equals and hashCode methods omitted for brevity } @Entity(name = "Country") ...

The @Access annotation is used to specify the access type of the associated entity class, mapped superclass, or embeddable class, or entity attribute. As a JPA provider, Hibernate can introspect both the entity attributes (instance fields) or the accessors (instance properties). By default, the placement of the @Id annotation gives the default access strategy. When placed on a field, Hibernate will assume field-based access. When placed on the identifier getter, Hibernate will use property-based access. Field-based access @Entity(name = "Book") public static class Book { @Id private Long id; private String title; private String author; //Getters and setters are omitted for brevity } When using field-based access, adding other entity-level methods is much more flexible because Hibernate won’t consider those part of the persistence state. To exclude a field from being part of the entity persistent state, the field must be marked with the @Transient anno...

The TestContext framework provides support for dynamic property sources via the @DynamicPropertySource annotation. This annotation can be used in integration tests that need to add properties with dynamic values to the set of PropertySources in the Environment for the ApplicationContext loaded for the integration test. The @DynamicPropertySource annotation and its supporting infrastructure were originally designed to allow properties from Testcontainers based tests to be exposed easily to Spring integration tests. However, this feature may also be used with any form of external resource whose lifecycle is maintained outside the test’s ApplicationContext. In contrast to the @TestPropertySource annotation that is applied at the class level, @DynamicPropertySource must be applied to a static method that accepts a single DynamicPropertyRegistry argument which is used to add name-value pairs to the Environment. Values are dynamic and provided via a Supplier which is only invoked when ...

ResourceLoader The ResourceLoader interface is meant to be implemented by objects that can return (that is, load) Resource instances. The following listing shows the ResourceLoader interface definition: public interface ResourceLoader {     Resource getResource(String location); } All application contexts implement the ResourceLoader interface. Therefore, all application contexts may be used to obtain Resource instances. When you call getResource() on a specific application context, and the location path specified doesn’t have a specific prefix, you get back a Resource type that is appropriate to that particular application context. For example, assume the following snippet of code was executed against a ClassPathXmlApplicationContext instance: Resource template = ctx.getResource("some/resource/path/myTemplate.txt"); Against a ClassPathXmlApplicationContext, that code returns a ClassPathResource. If the same method were executed against a FileSystemXmlApplicat...

An InputStreamResource is a Resource implementation for a given InputStream. It should be used only if no specific Resource implementation is applicable. In particular, prefer ByteArrayResource or any of the file-based Resource implementations where possible. In contrast to other Resource implementations, this is a descriptor for an already-opened resource. Therefore, it returns true from isOpen(). Do not use it if you need to keep the resource descriptor somewhere or if you need to read a stream multiple times.

This is a Resource implementation for ServletContext resources that interprets relative paths within the relevant web application’s root directory. It always supports stream access and URL access but allows java.io.File access only when the web application archive is expanded and the resource is physically on the filesystem. Whether or not it is expanded and on the filesystem or accessed directly from the JAR or somewhere else like a database (which is conceivable) is actually dependent on the Servlet container.

This is a Resource implementation for java.io.File and java.nio.file.Path handles. It supports resolution as a File and as a URL.

This class represents a resource that should be obtained from the classpath. It uses either the thread context class loader, a given class loader, or a given class for loading resources. This Resource implementation supports resolution as java.io.File if the class path resource resides in the file system but not for classpath resources that reside in a jar and have not been expanded (by the servlet engine or whatever the environment is) to the filesystem. To address this, the various Resource implementations always support resolution as a java.net.URL. A ClassPathResource is created by Java code by explicitly using the ClassPathResource constructor but is often created implicitly when you call an API method that takes a String argument meant to represent a path. For the latter case, a JavaBeans PropertyEditor recognizes the special prefix, classpath:, on the string path and creates a ClassPathResource in that case.

UrlResource UrlResource wraps a java.net.URL and can be used to access any object that is normally accessible with a URL, such as files, an HTTP target, an FTP target, and others. All URLs have a standardized String representation, such that appropriate standardized prefixes are used to indicate one URL type from another. This includes file: for accessing filesystem paths, http: for accessing resources through the HTTP protocol, ftp: for accessing resources through FTP, and others. A UrlResource is created by Java code by explicitly using the UrlResource constructor but is often created implicitly when you call an API method that takes a String argument meant to represent a path. For the latter case, a JavaBeans PropertyEditor ultimately decides which type of Resource to create. If the path string contains well-known (to it, that is) prefix (such as classpath:), it creates an appropriate specialized Resource for that prefix. However, if it does not recognize the prefix, it assume ...

This versatile ApplicationContext implementation is capable of accepting not only @Configuration classes as input but also plain @Component classes and classes annotated. Spring’s AnnotationConfigApplicationContext introduced in Spring 3.0. When @Configuration classes are provided as input, the @Configuration class itself is registered as a bean definition and all declared @Bean methods within the class are also registered as bean definitions. When @Component and JSR-330 classes are provided, they are registered as bean definitions, and it is assumed that DI metadata such as @Autowired or @Inject are used within those classes where necessary. Simple Construction In much the same way that Spring XML files are used as input when instantiating a ClassPathXmlApplicationContext, you can use @Configuration classes as input when instantiating an AnnotationConfigApplicationContext. This allows for completely XML-free usage of the Spring container, as the following example shows: p...

The @Bean annotation is used to indicate that a method instantiates, configures, and initializes a new object to be managed by the Spring IoC container. For those familiar with Spring’s <beans/> XML configuration, the @Bean annotation plays the same role as the <bean/> element. You can use @Bean-annotated methods with any Spring @Component. However, they are most often used with @Configuration beans. Annotating a class with @Configuration indicates that its primary purpose is as a source of bean definitions. Furthermore, @Configuration classes let inter-bean dependencies be defined by calling other @Bean methods in the same class. The simplest possible @Configuration class reads as follows: @Configuration public class AppConfig {     @Bean     public MyService myService() {         return new MyServiceImpl();     } } The preceding AppConfig class is equivalent to the following Spring <beans/> XML: <be...

If you would like to use a qualified name for the dependency that should be injected, you should use the @Named annotation, as the following example shows: import javax.inject.Inject; import javax.inject.Named; public class SimpleMovieLister {     private MovieFinder movieFinder;     @Inject     public void setMovieFinder(@Named("main") MovieFinder movieFinder) {         this.movieFinder = movieFinder;     }     // ... }

@Inject Instead of @Autowired, you can use @javax.inject.Inject as follows: import javax.inject.Inject; public class SimpleTestInject {     private MovieFinder movieFinder;     @Inject     public void setMovieFinder(MovieFinder movieFinder) {         this.movieFinder = movieFinder;     }     public void listMovies() {         this.movieFinder.findMovies(...);         // ...     } } with @Autowired, you can use @Inject at the field level, method level and constructor-argument level.

split(String toSplit, String delimiter) Split a String at the first occurrence of the delimiter. Method: public static String[] split(@Nullable String toSplit, @Nullable String delimiter) Example: String[] list = StringUtils.split( "Hello1, Hello2" , "," ); Split a String at the first occurrence of the delimiter. Does not include the delimiter in the result. Parameters: toSplit - the string to split (potentially null or empty) delimiter - to split the string up with (potentially null or empty) Returns: a two element array with index 0 being before the delimiter, and index 1 being after the delimiter (neither element includes the delimiter); or null if the delimiter wasn't found in the given input String

isEmpty(Object str) Check whether the given object (possibly a String) is empty. This method accepts any Object as an argument, comparing it to null and the empty String. As a consequence, this method will never return true for a non-null non-String object. The Object signature is useful for general attribute handling code that commonly deals with Strings but generally has to iterate over Objects since attributes may e.g. be primitive value objects as well. Method: public static boolean isEmpty(@Nullable Object str) Example:  StringUtils.isEmpty(null) = true  StringUtils.isEmpty("") = true  StringUtils.isEmpty("Hello") = false

Current sorting implementations provided by the Java Collections Framework (Collections.sort and Arrays.sort) all perform the sorting operation sequentially in the calling thread. This enhancement will offer the same set of sorting operations currently provided by the Arrays class Example: public class Arrays {   ...   public static void parallelSort(byte[] a) { ... }   public static void parallelSort(byte[] a, int fromIndex, int toIndex)   public static void parallelSort(short[] a) { ... }   public static void parallelSort(short[] a, int fromIndex, int toIndex)     {...}   ... }

Hibernate Architecture Hibernate, as an ORM solution, effectively "sits between" the Java application data access layer and the Relational Database. The Java application makes use of the Hibernate APIs to manipulate its domain data. As a JPA provider, Hibernate implements the Java Persistence API specifications and the association between JPA interfaces and Hibernate specific implementations can be visualized in the following diagram: SessionFactory (org.hibernate.SessionFactory) A thread-safe (and immutable) representation of the mapping of the application domain model to a database. Acts as a factory for org.hibernate.Session instances. The EntityManagerFactory is the JPA equivalent of a SessionFactory and basically, those two converge into the same SessionFactory implementation. A SessionFactory is very expensive to create, so, for any given database, the application should have only one associated SessionFactory. The SessionFactory maintains services tha...

In predicate IN predicates performs a check that a particular value is in a list of values. Its syntax is: in_expression ::=     single_valued_expression [NOT] IN single_valued_list single_valued_list ::=     constructor_expression | (subquery) | collection_valued_input_parameter constructor_expression ::= (expression[, expression]*) In HQL, single_valued_expression can refer to a far more broad set of expression types. Single-valued association are allowed, and so are component/embedded attributes, although that feature depends on the level of support for tuple or "row value constructor syntax" in the underlying database. Additionally, HQL does not limit the value type in any way, though application developers should be aware that different types may incur limited support based on the underlying database vendor. This is largely the reason for the JPQL limitations. The list of values can come from a number of different sources. In the constructor_expre...

Between predicate Analogous to the SQL BETWEEN expression, it checks if the value is within boundaries. All the operands should have comparable types. Between predicate examples List<Person> persons = entityManager.createQuery( "select p " + "from Person p " + "join p.phones ph " + "where p.id = 1L and index(ph) between 0 and 3", Person.class ) .getResultList(); List<Person> persons = entityManager.createQuery( "select p " + "from Person p " + "where p.createdOn between '1999-01-01' and '2001-01-02'", Person.class ) .getResultList(); List<Call> calls = entityManager.createQuery( "select c " + "from Call c " + "where c.duration between 5 and 20", Call.class ) .getResultList(); List<Person> persons = entityManager.createQuery( "select p " + "from Person p " + "where p.name between ...

Like predicate Performs a like comparison on string values. The syntax is: like_expression ::=     string_expression     [NOT] LIKE pattern_value     [ESCAPE escape_character] The semantics follow that of the SQL like expression. The pattern_value is the pattern to attempt to match in the string_expression. Just like SQL, pattern_value can use _ and % as wildcards. The meanings are the same. The _ symbol matches any single character and % matches any number of characters. Like predicate examples List<Person> persons = entityManager.createQuery( "select p " + "from Person p " + "where p.name like 'Jo%'", Person.class ) .getResultList(); List<Person> persons = entityManager.createQuery( "select p " + "from Person p " + "where p.name not like 'Jo%'", Person.class ) .getResultList(); The optional escape 'escape character' is used to specify an escape character used...

Order by The results of the query can also be ordered. The ORDER BY clause is used to specify the selected values to be used to order the result. The types of expressions considered valid as part of the ORDER BY clause include: state fields component/embeddable attributes scalar expressions such as arithmetic operations, functions, etc. identification variable declared in the select clause for any of the previous expression types Additionally, JPQL says that all values referenced in the ORDER BY clause must be named in the SELECT clause. HQL does not mandate that restriction, but applications desiring database portability should be aware that not all databases support referencing values in the ORDER BY clause that are not referenced in the select clause. Individual expressions in the order-by can be qualified with either ASC (ascending) or DESC (descending) to indicate the desired ordering direction. Null values can be placed in front or at the end of the sorted set using...

Group by The GROUP BY clause allows building aggregated results for various value groups. As an example, consider the following queries: Group by example Long totalDuration = entityManager.createQuery( "select sum( c.duration ) " + "from Call c ", Long.class ) .getSingleResult(); List<Object[]> personTotalCallDurations = entityManager.createQuery( "select p.name, sum( c.duration ) " + "from Call c " + "join c.phone ph " + "join ph.person p " + "group by p.name", Object[].class ) .getResultList(); //It's even possible to group by entities! List<Object[]> personTotalCallDurations = entityManager.createQuery( "select p, sum( c.duration ) " + "from Call c " + "join c.phone ph " + "join ph.person p " + "group by p", Object[].class ) .getResultList(); The first query retrieves the complete total of all orders. The sec...

HQL and JPQL queries are inherently polymorphic. List<Payment> payments = entityManager.createQuery( "select p " + "from Payment p ", Payment.class ) .getResultList(); This query names the Payment entity explicitly. However, all subclasses of Payment are also available to the query. So, if the CreditCardPayment and WireTransferPayment entities extend the Payment class, all three types would be available to the entity query, and the query would return instances of all three. This behavior can be altered in two ways: by limiting the query to select only from the subclass entity by using either the org.hibernate.annotations.Polymorphism annotation (global, and Hibernate-specific). See the @Polymorphism section for more info about this use case. The HQL query from java.lang.Object is totally valid (although not very practical from a performance perspective)! It returns every object of every entity type defined by your application mappings.

Distinct For JPQL and HQL, DISTINCT has two meanings: It can be passed to the database so that duplicates are removed from a result set It can be used to filter out the same parent entity references when join fetching a child collection Using DISTINCT with SQL projections For SQL projections, DISTINCT needs to be passed to the database because the duplicated entries need to be filtered out before being returned to the database client. Using DISTINCT with projection queries example          List<String> lastNames = entityManager.createQuery( "select distinct p.lastName " + "from Person p", String.class) .getResultList(); When running the query above, Hibernate generates the following SQL query: SELECT DISTINCT     p.last_name as col_0_0_ FROM person p For this particular use case, passing the DISTINCT keyword from JPQL/HQL to the database is the right thing to do. Using DISTINCT with entity queries DISTINCT can also be...

Another means of adding to the scope of object model types available to the query is through the use of implicit joins or path expressions. Simple implicit join example List<Phone> phones = entityManager.createQuery( "select ph " + "from Phone ph " + "where ph.person.address = :address ", Phone.class ) .setParameter( "address", address ) .getResultList(); // same as List<Phone> phones = entityManager.createQuery( "select ph " + "from Phone ph " + "join ph.person pr " + "where pr.address = :address ", Phone.class ) .setParameter( "address", address) .getResultList(); Reused implicit join List<Phone> phones = entityManager.createQuery( "select ph " + "from Phone ph " + "where ph.person.address = :address " + "  and ph.person.createdOn > :timestamp", Phone.class ) .setParameter( "address", add...

The FROM clause can also contain explicit relationship joins using the join keyword. These joins can be either inner or left outer style joins. Explicit inner join examples List<Person> persons = entityManager.createQuery( "select distinct pr " + "from Person pr " + "join pr.phones ph " + "where ph.type = :phoneType", Person.class ) .setParameter( "phoneType", PhoneType.MOBILE ) .getResultList(); // same query but specifying join type as 'inner' explicitly List<Person> persons = entityManager.createQuery( "select distinct pr " + "from Person pr " + "inner join pr.phones ph " + "where ph.type = :phoneType", Person.class ) .setParameter( "phoneType", PhoneType.MOBILE ) .getResultList(); Explicit left (outer) join examples List<Person> persons = entityManager.createQuery( "select distinct pr " + "from Person pr ...

The FROM clause The FROM clause is responsible for defining the scope of object model types available to the rest of the query. It is also responsible for defining all the "identification variables" available to the rest of the query.

Insert statements HQL adds the ability to define INSERT statements as well. There is no JPQL equivalent to HQL-style INSERT statements. HQL INSERT statement is: insert_statement ::=     insert_clause select_statement insert_clause ::=     INSERT INTO entity_name (attribute_list) attribute_list ::=     state_field[, state_field ]* The attribute_list is analogous to the column specification in the SQL INSERT statement. For entities involved in mapped inheritance, only attributes directly defined on the named entity can be used in the attribute_list. Superclass properties are not allowed and subclass properties do not make sense. In other words, INSERT statements are inherently non-polymorphic. select_statement can be any valid HQL select query, with the caveat that the return types must match the types expected by the insert. Currently, this is checked during query compilation rather than allowing the check to relegate to the database. Thi...

Delete statements DELETE statements is the same in HQL and JPQL: delete_statement ::=     delete_clause [where_clause] delete_clause ::=     DELETE FROM entity_name [[AS] identification_variable] A DELETE statement is also executed using the executeUpdate() method of either org.hibernate.query.Query or javax.persistence.Query.

UPDATE statements is the same in HQL and JPQL: update_statement ::=     update_clause [where_clause] update_clause ::=     UPDATE entity_name [[AS] identification_variable]     SET update_item {, update_item}* update_item ::=     [identification_variable.]{state_field | single_valued_object_field} = new_value new_value ::=     scalar_expression | simple_entity_expression | NULL UPDATE query statements int updatedEntities = entityManager.createQuery( "update Person p " + "set p.name = :newName " + "where p.name = :oldName" ) .setParameter( "oldName", oldName ) .setParameter( "newName", newName ) .executeUpdate(); int updatedEntities = session.createQuery( "update Person " + "set name = :newName " + "where name = :oldName" ) .setParameter( "oldName", oldName ) .setParameter( "newName", newName ) .executeUpdate(); int updatedEntities = session.createQu...

SELECT statements in HQL is: select_statement :: =     [select_clause]     from_clause     [where_clause]     [groupby_clause]     [having_clause]     [orderby_clause] The simplest possible HQL SELECT statement is of the form: List<Person> persons = session.createQuery("from Person" ).list(); The select statement in JPQL is exactly the same as for HQL except that JPQL requires a select_clause, whereas HQL does not. List<Person> persons = entityManager.createQuery( "select p " + "from Person p", Person.class ) .getResultList(); Even though HQL does not require the presence of a select_clause, it is generally good practice to include one. For simple queries the intent is clear and so the intended result of the select_clause is easy to infer. But on more complex queries that is not always the case. It is usually better to explicitly specify intent. Hibernate does not actually enforce that a se...

In Hibernate, the HQL query is represented as org.hibernate.query.Query which is obtained from a Session. If the HQL is a named query, Session#getNamedQuery would be used; otherwise Session#createQuery is needed. Obtaining a Hibernate Query org.hibernate.query.Query query = session.createQuery( "select p " + "from Person p " + "where p.name like :name" ); Obtaining a Hibernate Query reference for a named query org.hibernate.query.Query query = session.getNamedQuery( "get_person_by_name" ); Basic Query usage - Hibernate org.hibernate.query.Query query = session.createQuery( "select p " + "from Person p " + "where p.name like :name" ) // timeout - in seconds .setTimeout( 2 ) // write to L2 caches, but do not read from them .setCacheMode( CacheMode.REFRESH ) // assuming query cache was enabled for the SessionFactory .setCacheable( true ) // add a comment to the generated SQL if enabled via...

When using Hibernate, you can execute entity queries either via JPA or the Hibernate-specific API. the query API was also merged, and now the Hibernate org.hibernate.query.Query interface extends the JPA javax.persistence.Query. Next, we are going to see how the query API differs between the standard JPA interfaces and the Hibernate-specific API. JPA Query API In JPA, the query is represented by javax.persistence.Query or javax.persistence.TypedQuery as obtained from the EntityManager. The create an inline Query or TypedQuery, you need to use the EntityManager#createQuery method. For named queries, the EntityManager#createNamedQuery method is needed. Obtaining a JPA Query or a TypedQuery reference Query query = entityManager.createQuery( "select p " + "from Person p " + "where p.name like :name" ); TypedQuery<Person> typedQuery = entityManager.createQuery( "select p " + "from Person p " + "where p.na...