-
Notifications
You must be signed in to change notification settings - Fork 300
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
Using MethodReferences is still breaking soundness #1258
Comments
Method calls and method references (and also lambda expressions) are very different in the byte code ( These different domain objects need to be addressed accordingly. There is a fluent API for both kinds of rules:
¹ Example: The following java code:class Target {
static void method(int i) {
System.out.println("method called!");
}
void methodCall() {
Target.method(1);
}
void methodCall() {
Target.method(1);
}
void methodReference() {
stream1().forEach(Target::method);
}
void lambda() {
stream1().forEach(i -> Target.method(i));
}
static Stream<Integer> stream1() {
return Stream.of(1);
}
} may be compiled to the following byte code:
|
Thanks for the clarification, accessTargetWhere() indeed works in both cases. I will adapt our rules and that should fix the problem in our case. However, please make sure that this is mentioned in the Documentation In [1], both callMethodWhere() and accessTargetWhere() do not provide any JavaDoc. References |
You're clearly right that the documentation can be improved. 🙈 |
A note for the people that come after us: when using accessTargetWhere(), it is better to do it this way:
Otherwise, you might run into rather subtle issues. |
Aaah... 🤯 I'm sorry for that! |
I have a question.
Java 8 was released in 2014[1] and introduced Closures along with Lambda expressions and method references into the language[2].
Since then, a number of issues have been opened by different people noting that ArchUnit does not support method references
(see for instance #713, #215, #649).
All of these issues are closed for a while now (since 2022 to be exact), so I would have expected ArchUnit to support method references by now.
However, when I test the newest version 1.2.1, I find that ArchUnit is still (in 2024 - 10 years after that feature was introduced!) unable to deal with method references.
Concretely,
given the following class whose sole method is for some reason prohibited:
and this being enforced by the following ArchUnit Rule:
then we see that this works fine on a program like
but fails to detect any problem in the following program
although the two are clearly equivalent and both programs clearly call Target.methodInQuestion() as apparent by their outputs:
Could you help me understand what is going on?
References
[1] https://en.wikipedia.org/wiki/Java_version_history
[2] https://www.oracle.com/java/technologies/javase/8-whats-new.html
The text was updated successfully, but these errors were encountered: