JPQL aliasing using `id` breaks EclipseLink queries

[hgwr]

Summary

After upgrading to Spring Boot 4.x (Spring Data JPA 4.0.x) with EclipseLink 5.0.0-B13, some derived queries fail at runtime.
This issue appears to be separate from #4145 (IN clause list binding).

Background / Regression

We recently upgraded our project from Spring Boot 3.x to 4.x.
After the upgrade, several repository methods based on derived queries started failing at runtime unless rewritten using explicit @Query JPQL.

This suggests a regression or compatibility gap introduced by the combination of Spring Data JPA 4.x and EclipseLink 5 (Hermes JPQL parser).

Actual behavior

1. existsBy… derived queries fail with JPQL syntax error

EclipseLink 5 (Hermes) rejects JPQL generated for existsBy… queries due to an implicit alias in the select clause.

Example exception:

BadJpqlGrammarException: ... Syntax error parsing ... select o.id id ...

Generated JPQL (example):

SELECT o.id id FROM OfUser o
WHERE UPPER(o.email) = UPPER(?1)
  AND o.id != ?2
  AND o.isDelete != ?3

Hermes appears to reject select o.id id (implicit alias without AS).

2. Parameter mismatch in findByIdAndIsDeleted

Some derived queries fail with a positional parameter binding error:

InvalidDataAccessApiUsageException:
Query argument 2 not found in the list of parameters provided during query execution

This seems to indicate that EclipseLink 5 under-reports positional parameters for certain derived queries.

Expected behavior

Derived queries should execute successfully on EclipseLink 5 without requiring explicit JPQL annotations.

Steps to reproduce (minimal)

Entity

@Entity
class SoftDeleteUser {

  @Id
  @GeneratedValue
  Long id;

  @Column(nullable = false)
  String email;

  @Column(nullable = false)
  Integer isDeleted;
}

Repository

interface SoftDeleteUserRepository
    extends JpaRepository<SoftDeleteUser, Long> {

  boolean existsByEmailIgnoreCaseAndIdNotAndIsDeletedNot(
      String email, Long id, Integer isDeleted);

  Optional<SoftDeleteUser> findByIdAndIsDeleted(
      Long id, Integer isDeleted);
}

Test scenario

1. Persist two users with isDeleted = 0
2. Call
   existsByEmailIgnoreCaseAndIdNotAndIsDeletedNot("USER@EXAMPLE.COM", otherId, 1)
3. Call
   findByIdAndIsDeleted(activeId, 0)

Environment

• Spring Boot: 4.0.x
• Spring Data JPA: 4.0.2 (or current 4.x)
• EclipseLink: 5.0.0-B13
• JDK: 17
• Database: H2 (in-memory); also reproduced with other databases

Workaround

Annotating repository methods with explicit JPQL using @Query avoids these failures.

Additional notes / possible direction

• Hermes appears to reject JPQL with implicit select aliases (select o.id id).
• EclipseLink 5 also seems to under-report positional parameters in some derived queries, leading to ?2 binding errors.

Links

• Related issue: findByNameIn(List) fails with IllegalArgumentException using EclipseLink #4145 (different problem: IN-clause list binding)
• Candidate fix with regression tests (fork):
  Improve derived query compatibility with EclipseLink 5 hgwr/spring-data-jpa#1
• Fix EclipseLink 5 derived query compatibility #4168

[mp911de]

Thank you for your issue report and. We appreciate community contributions, but we do need them to meet a reasonable baseline for consideration. This in detail this is:

• Expressing your intent with a concise and reasonable description
• Providing what situation you've encountered, describing your setup, ideally with a reproducer provided as GitHub repository, and what you would expect

When issues require significant effort from our side to initially understand your request, we have to deprioritize or even reject them in favor of tickets that are ready for discussion as we have to be mindful of our limited time, and we need to focus it where it has the most impact. If you would like us to spend some time working on this issue, please spend some time making this a substantial and quality ticket description.

When describing your concern, please focus on the aspects that matter. There's no need to duplicate parts of our code in the description or use excessive summarization or bullet lists that are typically artifacts of unedited AI tool outputs. Instead, use rather links if you want to point out subtle details that matter in the specific context. Avoid conflicting requests such as asking for guidance and then answering questions yourself, as such descriptions neglect raising a ticket in the first place. The ticket mixes the id keyword issue with undereporting positional parameter bindings. Because of a wall of text it is next to impossible to reasonably approach this ticket.

Let's focus on the id part:

There's indeed a mismatch in rendering aliases. JPA specifies the AS keyword for aliasing while we do not include AS in the generated JPQL statement (Currently usingSELECT u.id id vs SELECT u.id AS id). After adding AS, the parser still complains about using id as alias:

[15, 17] The identification variable 'id' cannot be a reserved word. (SELECT u.id AS  [ id ] ...; Bad SELECT u.id AS id FROM User u WHERE u.lastname = :lastname grammar [JPQL]

We can omit aliases for the majority of cases; however, for tuple queries used for projections (that aren't well supported by EclipseLink anyways), we require explicit aliases. That's something we can fix with a much less invasive (a more appropriate) change than proposed in #4168.

I would ask you to close your PR #4168 and instead, submit a pull request to address the under-reporting of positional parameters issue. Please spend some time to come up with a integration test arrangement that reuses existing entities instead of introducing new ones.