Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce @CheckReturnValue into common Arc build items #38096

Merged
merged 1 commit into from
Jun 7, 2024

Conversation

geoand
Copy link
Contributor

@geoand geoand commented Jan 9, 2024

This makes the IDE warn extension authors when
they have created a build item but have not used it.

I encountered this in #38083 when I wrote something like:

UnremovableBeanBuildItem.beanTypes(Foo.class, Bar.class)

in a hurry and didn't stop to consider that the build item
was never being produced.

This makes the IDE warn extension authors when
they have created a build item but have not used
it.
I encountered this in quarkusio#38083
when I wrote something like:

```java
UnremovableBeanBuildItem.beanTypes(Foo.class, Bar.class)
```

in a hurry and didn't stop to consider
that the build item was never being
produced
@geoand geoand requested a review from mkouba January 9, 2024 08:27
@quarkus-bot quarkus-bot bot added the area/arc Issue related to ARC (dependency injection) label Jan 9, 2024
@mkouba
Copy link
Contributor

mkouba commented Jan 9, 2024

Well, these are static factory methods. What makes you think it would "produce" the build item as well? I mean it's like using a constructor 🤷. I'm not against adding those annotations but it feels a little bit inconsistent. Shouldn't we add this annotation to any factory method in any build item (which is IMO quite a common pattern)? Shouldn't we add this annotation to any constructor of a build item?

@geoand
Copy link
Contributor Author

geoand commented Jan 9, 2024

You are right in all counts, however mistakes like this are easy to make when using static methods as opposed to constructors where the new keyword keeps you honest event if you are mindlessly coding away.

Shouldn't we add this annotation to any factory method in any build item (which is IMO quite a common pattern)?

I believe so, I only added it to the ones I find the most useful and most widely used.

Shouldn't we add this annotation to any constructor of a build item?

I don't think so, because I seriously anyone would ever just create the build item with the constructor (as I mentioned earlier, the new keyword alerts you to the usage - or at least it does for me).

Copy link

quarkus-bot bot commented Jan 9, 2024

Failing Jobs - Building 9699fb8

Status Name Step Failures Logs Raw logs Build scan
Maven Tests - JDK 17 Build Failures Logs Raw logs 🔍
✔️ Maven Tests - JDK 17 Windows 🔍

Full information is available in the Build summary check run.
You can consult the Develocity build scans.

Failures

⚙️ Maven Tests - JDK 17 #

- Failing: integration-tests/maven 

📦 integration-tests/maven

io.quarkus.maven.it.DevMojoIT.testThatNewResourcesAreServed line 967 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: io.quarkus.maven.it.DevMojoIT expected "91d47644-7ec4-423f-953c-1de02161e5fd" but was "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua." within 2 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.AbstractHamcrestCondition.await(AbstractHamcrestCondition.java:86)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:691)
	at io.quarkus.maven.it.DevMojoIT.testThatNewResourcesAreServed(DevMojoIT.java:967)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)

io.quarkus.maven.it.DevMojoIT.testThatNewResourcesAreServed line 967 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: io.quarkus.maven.it.DevMojoIT expected "91d47644-7ec4-423f-953c-1de02161e5fd" but was "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua." within 2 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.AbstractHamcrestCondition.await(AbstractHamcrestCondition.java:86)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:691)
	at io.quarkus.maven.it.DevMojoIT.testThatNewResourcesAreServed(DevMojoIT.java:967)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)

Copy link
Member

@gsmet gsmet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's merge this, I don't want to check it again next time I do a review of the open PRs.

@gsmet gsmet merged commit eeaca37 into quarkusio:main Jun 7, 2024
50 of 51 checks passed
@quarkus-bot quarkus-bot bot added this to the 3.12 - main milestone Jun 7, 2024
@geoand geoand deleted the arc-builditems-checkreturnvalue branch June 7, 2024 15:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/arc Issue related to ARC (dependency injection)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants