Enterprise Java

EasyCriteria has evolved to uaiCriteria. New name and more features

Hello, how are you?

I am very happy to announce the release of the uaiCriteria, the EasyCriteria evolution.

Was it really needed to change the framework name? Yes, sadly it was. I found  another framework with the same name, that is why I decided to change the name (I do not want any kind of legal problems). The difference of the framework is that the other framework works with MetaModel, and uaiCriteria works with strings as parameters.

About the framework name change:

  • Your code will work with this new version without a problem, the code is retro compatible
  • All EasyCriteria classes are annotated with @Deprecated and will be removed in the next version
  • The new classes has all the methods of the old version. If you want to change for the new code just “replace” the text EasyCriteria for UaiCriteria in your code
  • Again, I did not want to change the framework name but I do not want legal problems

The framework now has a mascot:



The new version has a lot of new stuff. Let us talk first about the structural changes:

  • The site has changed, now is http://uaicriteria.com
  • The repository has changed, now is on GIT (requested by a lot of develpers) https://github.com/uaihebert/uaicriteria
  • The SONAR plug-in was added to the pom.xml to help with code the code coverage and static analysis:


    uaicriteria cobertura
    uaicriteria cobertura

  • The old site will be deactivated, but all the old documentation was migrated.
  • The current API has some criteria limitations, using HAVING in the criteria is something that is not possible. We will create a new Interface/API to use with complex criteria – I am looking for a new name for the new Interface, could you suggest me one? (:

Let us talk about the new features:

Welcome to Batoo

Batoo is a JPA provider like EclipseLink or Hibernate. In this new version we got a good number of methods tested with Batoo.

Notice that I talked about “a good number of methods” but not most of the methods. Unfortunately Batoo has several problems with JPQL and Criterias, and I could not cover most of the methods with it.

uaiCriteria framework support almost all methods with EclipseLink, Hibernate and OpenJPA.


It is possible to choose which attributes will be returned:

    Person p

If we transform the JPQL above in Criteria:

finalUaiCriteria<Person> uaicriteria =
    UaiCriteriaFactory.UaiCriteriaFactory.createMultiSelectCriteria(entityManager, Person.class);


finalList multiselectList = uaiCriteria.getMultiSelectResult();

Some considerations about the code above:

  • Object will be returned if you select only one attribute
  • Object[] will be returned if you select more than one attribute
  • The JPA provider may return Vector instead of Object[] (with my tests EclipseLink was returning a Vector)


Now it is possible to do a subQuery like below:

select p from Person p 
where p.id in
        (select dog.person.id from Dog dog where dog.cute = true)

I will not talk about the several lines of native JPA criteria needed to do the JPQL above, but with UaiCriteria is very easy to do:

final UaiCriteria<Person> uaiCriteria = UaiCriteriaFactory.createQueryCriteria(Person.class);
final UaiCriteria<Dog> subQuery = uaiCriteria.subQuery("person.id", Dog.class); // dog.person.id
subQuery.andEquals("cute", true);
uaiCriteria.andAttributeIn("id", subQuery); //person.id

All you need to do is to create a subQuery informing its return; then call the method attributeIn of the root criteria.

MapIsEmpty [NOT]

The isEmpty method can be used with maps:


AttributeIn [NOT]

If you want to validate if a value is inside a list like the JPQL:

select p
from Payment p
    p.statusEnum in :enumList

You can create the JPQL above like:

final UaiCriteria<Payment> uaiCriteria = 
                           Arrays.asList(StatusEnum.VALUE_01, StatusEnum.VALUE_02));

The attribute could be a enum, integer, String, etc.

MemberOf [NOT]

The query below:

select d
from Departament d
where :person member of d.employeeList

Could be created like:

final UaiCriteria<Departament> uaiCriteria = 
uaiCriteria.andIsMemberOf(person, "employeeList");

Count and CountRegularCriteria

Now it is possible to do a count with a MultiSelect criteria. The count method was renamed to countRegularCriteria(). It works like the older version, just the name was refactored to make things more distinct.


Sometimes you need to count an attribute instead of an entity:

select count(p.id)
from Person p

You can run the JPQL above like:

final UaiCriteria<Person> uaiCriteria = 
final List result = uaiCriteria.getMultiSelectResult();

GroupBy and Aggregate Functions

Now it is possible to do a GroupBy with aggregate functions: sum, diff, divide, module,  etc.

select sum(p.value), p.status
from Payment p
group by p.status

Could be executed like:

final UaiCriteria<Payment> uaiCriteria = 
final List result = uaiCriteria.getMultiSelectResult();

New Maven Import

If you want to use the new version, just add the xml below to your pom.xml:


I hope you liked the news.

Do not forget to visit the new site ———–> http://uaicriteria.com

If you have any doubts, questions or suggestions just post it.

See you soon.

Hebert Coelho

Senior Java Development, with 4 certifications and a published book about JSF (portuguese only). Founder of the blog uaiHebert.com visited from more than 170 different countries.
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Newest Most Voted
Inline Feedbacks
View all comments
Yannick Majoros
Yannick Majoros
9 years ago

One of the key points of JPA’s Criteria API is type safety. This is sadly gone here.

In my opinion, there is much less value in this library than in the standard, so why use it? Making it “easy” (no real proof) looks like the excuse for this. I hope nobody has the bright idea to use this on real projects (at least not on project I’ll have to work with).

Back to top button