No constructors warning for HQL using DTO class constructor

[Eccenux]

Apache NetBeans version

Apache NetBeans 30

What happened

I keep getting a warning "No constructors can de found that match the argument types" for HQL with DTO class.

Language / Project Type / NetBeans Component

Java Maven Web application project

How to reproduce

Package structure (simplified):

• webapp (REST controllers)
  • api (interface, dto)
  • core (DAO, service)
    • api (interface, dto)
    • ent (entities)

in example-api:

package com.example.domain;

import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;

@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
public class ResourceCategoryMini {
	private Long id;
	private Boolean active;
	private String label;
	private String description;
}

in example-core:

package com.example.core.dao;

import java.util.List;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Repository;
import com.example.domain.ResourceCategoryMini;

@Repository
public class ResourceCategoryDAO {
	@Autowired
	protected SessionFactory sessionFactory;

	/**
	 * Returns a minimal resource category list.
	 *
	 * @return resource category list
	 */
	public List<ResourceCategoryMini> listMini() {
		Session session = sessionFactory.getCurrentSession();

		var results = session.createQuery("""
			select new com.example.domain.ResourceCategoryMini(
				r.id,
				r.active,
				r.label,
				r.description
			)
			from ResourceCategoryEntity r
			order by id asc
			""", ResourceCategoryMini.class)
			.getResultList();

		return results;
	}
}

Did this work correctly in an earlier version?

No

Operating System

Windows 11 version 10.0 running on amd64; UTF-8; pl_PL (nb)

JDK

Runtime: OpenJDK Runtime Environment 21.0.8+9-LTS

Apache NetBeans packaging

Community provided installer

Anything else

That error is always shown when using DTO class in HQL.

Oh, and the project is based on Spring MVC + Hibernate + HikariCP data-source if that matters.

Are you willing to submit a pull request?

No

[neilcsmith-net]

Make sure you're using a Lombok version compatible with JDK 26, and review the information in #8221

[Eccenux]

I'm using JDK 21 as the NetBeans runtime. I use JDK 21 because I had problems with NetBeans crashing and/or the clipboard not working with the JDK provided by the NetBeans installer.

I do use the latest Lombok version (org.projectlombok:lombok:jar:1.18.46:provided), which seems to support JDK 24: projectlombok/lombok#3772 ...and support JDK 26 too: projectlombok/lombok#4019

[neilcsmith-net]

The runtime JDK isn't relevant, as you can see in the linked discussion. The IDE editor uses the JDK 26 compiler internally. NB31 will use JDK 27-ea. Lombok is effectively unsupported - it may or may not work, but you're on your own and it's not something that we can do anything about.

[Eccenux]

If that is the case, then why not just compile stable NetBeans with a stable JDK? Most libraries still work with JDK 17 LTS. Does NetBeans really need to be so close to the bleeding edge in terms of the compiler?

Also note that Lombok is used by 35k publicly published projects. One of them is Spring Boot, which has 81k stars on GitHub. Both are actually more popular then NetBeans.

And also Lombok does already work with JDK 26 and yet NetBeans fails to detect the Lombok constructor.

[Eccenux]

I mean, don't get me wrong. I've been a fan of NetBeans for a long time, but as a Tech Lead and simply as a developer, I would love to keep recommending NetBeans to other developers.

[neilcsmith-net]

If that is the case, then why not just compile stable NetBeans with a stable JDK? Most libraries still work with JDK 17 LTS. Does NetBeans really need to be so close to the bleeding edge in terms of the compiler?

Yes, unless you don't think people using NetBeans should be able to edit any code above JDK 17! The IDE uses a backported version of the latest compiler to parse source code.

Lombok is a horrible hack that messes around with the internals of the Java compiler, which is why it continually breaks as NetBeans updates its parsing support for the latest JDKs. It is almost always optional (eg. in Spring Boot), and rapidly becoming unnecessary and part of Java's past. The small volunteer team here is going to keep concentrating our limited time on making NetBeans work well with the latest tools and JDKs.

And also Lombok does already work with JDK 26 and yet NetBeans fails to detect the Lombok constructor.

Sure, but also not the actual issue! It's likely either a configuration problem with the project or something wrong in Lombok. It's possibly caused by an underlying issue with expectations inside the IDE. If the latter, and you find the underlying problem, then please open a report or PR for that.

EDIT : possibly make sure you check that proc:full is set in the project. It might be that annotation processing is not being triggered at all in the IDE?

[lahodaj]

NetBeans uses javac as a library to model the Java source code - for use in code completion, etc. I.e. there's a lot of code in NetBeans that directly links against the javac API, and it is not something that could (or should) be easily avoided or abstracted.

So, NetBeans has roughly three options:

• use an arbitrary older javac as the Java modeling library - like the suggested JDK 17. Then NetBeans would simply not understand any newer Java feature since JDK 18. This is obviously unfeasible.
• use an up-to-date javac as the modeling library (JDK 27's javac for NetBeans 31, I believe). Then NetBeans supports up-to-date language features. And while the javac API evolution is not 100% compatible, the incompatibilities are small. So in this approach, well-behaved annotation processors are supported well. (Well-behaved: using the API, not breaking into internals.) The drawback is that not-well-behaved APs, like Lombok, have troubles when they don't support the up-to-date internals.
• support linking against multiple javac versions (but always run against a single javac version at runtime). We did this for some time in the past, and there are two problems: a) causes unmaintainable reflection mess, when trying to use a newer Java model - this actually escalates quite quickly; b) javac is getting more stable over time, so using an older version of javac can lead to additional crashes/exceptions/broken stuff, especially in presence of erroneous code.

I think use of up-to-date javac is the only viable option. It is unfortunate that Lombok sometimes does not work, but I would say that's more a deficiency in Lombok, that it touches internals/non-API. And that the onus is on them to keep Lombok up-to-date with javac internals if they opt to rely on the internals.

[Eccenux]

Hm... OK. I think I understand the problem better. So, it's not like there are separate modules for autocomplete, linting, and things like that. It's all integrated into NB (or at least no longer separated enough). That's a tough one.

I guess one solution for users (devs like me) is not to update to the latest NetBeans version unless all their projects require the latest Java. That's not great, though, because new versions of NB is not only for Java, it also bring better support for things like JavaScript and CSS editing. And current installer is replacing previous version, which most of the time is good, but in this case not so much.

So... Even if supporting multiple javac versions is difficult (and I understand that it might not be appealing to you or you may even despise that idea), it does sound like something you should strive to support, or alternatively provide better separation between the NB modules. People will still use Lombok because it provides better compatibility then using records. Not sure if you had something else in mind that can be better for POJO/DTO?

There is another option: provide a plugin for Lombok. I'm not sure how feasible that is, since I haven't developed a NetBeans plugin yet. There is a plugin for IntelliJ IDEA, which, unfortunately, is what most of my team uses. IJ has its own set of problems, but it does have Lombok support.

[neilcsmith-net]

I guess one solution for users (devs like me) is not to update to the latest NetBeans version unless all their projects require the latest Java.

Not that it's relevant to your current issue, but we already recommend anyone who must use Lombok stick with even-numbered NetBeans releases, as they should always contain a GA compiler rather than an EA one.

Please ensure annotation processing is actually running in the editor too.

Even if supporting multiple javac versions is difficult ... it does sound like something you should strive to support,

I do love it when people volunteer other people's free time! 😉 Realistically, it's not happening. As @lahodaj says, what we have is really the only viable option. Any deficiency is in Lombok.

@lahodaj thanks for that good summary. I think we should reconsider a pinned issue on this, rather than the pinned discussion at https://github.com/apache/netbeans/discussions/categories/tips-tricks-and-workarounds that we ended up with. We seem to keep answering similar questions. Perhaps we can quote or summarize what you said above.

[Eccenux]

Even if supporting multiple javac versions is difficult ... it does sound like something you should strive to support,
I do love it when people volunteer other people's free time! 😉 Realistically, it's not happening. As @lahodaj says, what we have is really the only viable option. Any deficiency is in Lombok.

No worries, I don't expect you to drop everything and work on it 😉. I don't even realistically expect to change your mind in this discussion. I'm a volunteer too, e.g. admin and dev on Wikipedia, and I always say I'll think about it... and sometimes get to it. That's all there is to it.

Not that it's relevant to your current issue, but we already recommend anyone who must use Lombok stick with even-numbered NetBeans releases, as they should always contain a GA compiler rather than an EA one.

Perhaps that distinction should be made clearer in the documentation or other communications. I don't recall reading anything like that recently. It might be a good idea to mention different release tracks on the downloads page:
https://netbeans.apache.org/front/main/download/

[mbien]

I am not super interested in lombok issues, but a quick test with @Data classes and also the ResourceCategoryMini example above using NB 30 worked. The constructors (and methods) do appear to be available from the point of view of NB. No errors in the editor layer etc.

(but as others mentioned it didn't work using the voting candidate of NB 31 since lombok doesn't support JDK 27 yet for some reason).

however:

I keep getting a warning "No constructors can de found that match the argument types" for HQL with DTO class.

That error is always shown when using DTO class in HQL.

by error you mean warning? or the other way around? This almost sounds like a second annotation processor doesn't see the result of the first processor. It is unclear to me where that message is coming from.

[Eccenux]

by error you mean warning? or the other way around? This almost sounds like a second annotation processor doesn't see the result of the first processor. It is unclear to me where that message is coming from.

JPQL validation error / warning, not sure what is the best wording here.

PS: I did add <proc>full</proc> for the Maven compiler plugin. That didn't change anything (still a warning in NB, still works fine in auto-tests and Tomcat).

[neilcsmith-net]

I'm going to move this over to discussions, because I'm not sure if there's anything to look at here. @Eccenux if you can provide a minimal, reproducible example project then it's perhaps something someone can take a look at.