Using AssertJ in production code

[arunbear]

Are there technical reasons to not use AssertJ in production code, e.g. as a more user-friendly version of the built-in Java assert?

I don't mind that it can't be disabled like the built-in assert (that's a feature according to some folks e.g. Pragmatic Programmer)

Thanks.

[joel-costigliola]

There is no reason, you can use it in production.

[scordio]

I'm going to bring a more pessimistic view than Joel 🙃

As I mentioned some years ago on StackOverflow, using AssertJ in production code is not the main focus of the library.

In case of input validation, there are a few alternatives that might be better candidates:

• Validate from Apache Commons Lang
• Preconditions from Google Guava
• Assert from the Spring Framework (in case of a Spring app)

However, there is nothing technical that prevents using AssertJ in production code. Nevertheless, I'd keep two things in mind:

• Production aspects have not been closely scrutinized, such as security or scaling.
• We generally assume the availability of a testing framework at runtime, which also means we don't do our testing without that available --> there might be side effects on certain features, like the exceptions we raise or soft assertions.

[arunbear]

Thank you. Let me put in a different way. Say I want something more user-friendly than the built-in assert and to be only used in the same situations where built in assert is appropriate (apart from needing to disable). (i.e. not for validation, and not using soft asserts) Would I have to basically fork AssertJ to get something like that? The other libraries mentioned are much less user-friendly.

…

On Tue, 16 Sept 2025 at 16:15, Stefano Cordio ***@***.***> wrote: I'm going to bring a more pessimistic view than Joel 🙃 As I mentioned some years ago on StackOverflow <https://stackoverflow.com/questions/69794092/use-assertj-in-spring-boot-production-code/69794779#69794779>, AssertJ is not designed to be used in production code. In case of input validation, Validate <https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/Validate.html> from Apache Commons Lang, Preconditions <https://guava.dev/releases/31.0.1-jre/api/docs/com/google/common/base/Preconditions.html> from Google Guava, or Assert <https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/util/Assert.html> from the Spring Framework (in case of a Spring app), may be good alternatives. There is nothing technical that prevents its usage. However, I'd keep two things in mind: - Production aspects have not been closely scrutinized, such as security or scaling. - We generally assume the availability of a testing framework at runtime, which also means we don't do our testing without that available --> there might be side effects on certain features, like the exceptions we raise or soft assertions. — Reply to this email directly, view it on GitHub <#3942 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAVDUNCPD3XESFCRRUSMCD3TASSPAVCNFSM6AAAAACGVEPEAOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINBRG42TSOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[scordio]

Forking is always an option, but it opens a totally different box of complexity 🙂

Keeping it simple: have you tried using AssertJ in production code already and faced some limitations?

Please feel free to give us feedback, and we're happy to discuss internally about how to support your use cases.

[arunbear]

I have not tried it in production code yet apart from some experiments (*). I hoped to find a definitive view from the authors first. (*) https://github.com/arunbear/java-dbc-examples/blob/master/src/main/java/org/example/Stack.java

…

On Tue, 16 Sept 2025 at 18:20, Stefano Cordio ***@***.***> wrote: Forking is always an option, but it opens a totally different box of complexity 🙂 Keeping it simple: have you tried using AssertJ in production code already and faced some limitations? — Reply to this email directly, view it on GitHub <#3942 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAVDULXE7XX35J7CKJVFAT3TBBFDAVCNFSM6AAAAACGVEPEAOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINBRHEZDGNY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[scordio]

I hope our exchange helped to have a better understanding of the AssertJ primary target.

However, it's not a closed door: we'd be happy to hear your experience and learn more about your use case, in case you face limitations!