how to write a single jpa specification for multiple entities

I am working on a Spring Boot - App that has multiple entities having some identical columns for filtering.

Currently, I have the same query defined in multiple repositories, so after doing some research, I've stumbled across an article about JPA - Specifications: https://spring.io/blog/2011/04/26/advanced-spring-data-jpa-specifications-and-querydsl/

So I made a generic class to build JPA-Specifications:

public final class GenericSpecifications<T>
{
    public Specification whereNameLikeAndDateGreatherThan(String fieldName, String fieldDate, String name, LocalDate date)
    {
       return (root, query, builder) -> builder.lessThan(root.get(columnName), date);
    }
}

So in the service I can use:

repository.findAll(whereNameLikeAndDateGreatherThan(Person_.name, Person_.date, "Max", LocalDate.now());

In this way, I have one query/specification in a central place and I don't need to write/maintain the same query on all repositories.

However, I have more complex queries, where I need to filter over multiple columns.
This means that my methods, in my GenericSpecification-Class, become too bloated, since I need to pass multiple column names and the search-values, so I could end up with methods with 6 or more parameters.

I could define an Abstract-Entity class extended by all other entities.This abstract entity would have all the common fields in order to be sure that all the entities have the same columns.
Then I can use these names for filtering, so I don't have to pass the field/coulmn-names at all.

But, I am not sure if this is the cleanest approach to my problem.
Do you know if there is a better way to do this?

I think the cleanest approach is to use inheritance, but in the specification creator, not the entities. So for example something like (didn't try if it compiles so it probably doesn't, but should give the idea):

class BasicSpecificationBuilder<T> {
    public Specification<T> stringEqual(String fieldName, String value) {
        // root is Root<T> here, don't know if this needs to be specified
        return (root, query, builder) -> 
                builder.equal(root.<String>get(fieldName), value);
        }
    }
    public Specification<T> dateAfter(String fieldName, LocalDate value) {
        return (root, query, builder) ->
                builder.<LocalDate>greaterThan(root.get(fieldName), value);
    }
}
// extend per entity type and required queries
class ContractSpecificationBuilder<Contract> extends BasicSpecificationBuilder<Contract> {
    public Specification<Contract> contractsCreatedAfter(String partner, LocalDate date) {
        return (root, query, builder) -> 
            stringEqual(Contract_.partnerName, partner)
                .and(
            dateAfter(Contract_.closeDate, date));
    }
}
class EmployeeSpecificationBuilder<Employee> extends BasicSpecificationBuilder<Employee> {
    public Specification<Employee> employeesJoinedAfter(String name, LocalDate date) {
        return (root, query, builder) ->
            stringEqual(Employee_.name, name)
                .and(
            dateAfter(Employee_.entryDate, date));
    }
}

This way you have a collection of builder methods in the base class you can reuse, and queries that don't explode because they're separated per entity. There may be a little code duplication as in the example above - if there's too many of those, you can refactor these common combinations into the base class.

class BasicSpecificationBuilder<T> {
    public Specification<T> stringEqualAndDateAfter(String stringField, String stringValue, String dateField, LocalDate dateValue) {
    public Specification<Employee> employeesJoinedAfter(String name, LocalDate date) {
        return (root, query, builder) ->
            stringEqual(stringField, name)
                .and(
            dateAfter(dateField, date));
    }
}
class ContractSpecificationBuilder<Contract> extends BasicSpecificationBuilder<Contract> {
    public Specification<Contract> contractsCreatedAfter(String partner, LocalDate date) {
        return stringEqualAndDateAfter(Contract_.partnerName, partner, Contract_.closeDate, date);
    }
}

That's a matter of taste and code quality settings (we had a code duplication measure in SonarQube with a limit, but I don't think this would have crossed the limit).

Since these are all factory methods, you can do pretty much the same thing with classes providing static methods and the "base" class containing the basic methods as static utility methods. I kind of dislike the syntax for generic static methods though.

That's all assuming you read the Baeldung intro on how to use Specification and didn't like that approach.