Check for compiled constant values passed to method arguments

[JLLeitschuh]

I understand that determining what range of possible things that a method will be called with at runtime is, fundamentally, the halting problem, and unsolvable.

That being said, it's my impression that it would be possible to determine when a method is called with a compile-time constant value. To provide a few examples:

myCoolMethod(null);
anotherAwesomeMethod("SOME_CONSTANT");

I also believe that compile-time constants like this also end up being optimized by the compiler?

class A {
     private static final String CONSTANT_VALUE = null;

    void aMethod() {
        myCoolMethod(CONSTANT_VALUE);
    }
}

Use Case

Certain methods have security vulnerabilities when called with certain values. Usually, these are easy to spot because the developer simply uses a compile-time-constant.

For example, File.createTempFile contains a local-information disclosure vulnerability if the 3rd argument passed is null.

Ask

Is there any easy way currently in ArchUnit to detect compile-time constants passed to functions at their call-sites?

[hankem]

I don't think that there is an easy way, unfortunately.
As far as I know, ArchUnit does currently not import any information about method argument values.

(But thanks for the well-structured question! 💙 I wish I could have given another answer... 😉)

[codecholeric]

Yes, unfortunately this is not possible at the moment. So far ArchUnit does not analyse bytecode information in context. I.e. we scan local information like method Foo.bar(..) is called or field Foo.baz is read.
What you are asking about would basically need to analyse the call stack and consider separate statements in combination. E.g. "load constant CONSTANT_VALUE" then "call method myCoolMethod" -> we can derive which constant value was passed for this specific occasion.
While it is theoretically possible to do this I have not looked into it any further so far.
I will close this issue for now, but if anybody wants to grab this and try to implement support for such a case, I'm all open to talk about it 😉 Probably the next natural step would be to make constant pool information available at all though, since that would be a precondition (compare e.g. #446 or #131).