I can't seem to get the `ForbiddenMethodCall` to w...

# detekt

[bbaldino]

I can't seem to get the ForbiddenMethodCall to work, I've got it configured like so:

style:
  active: true
  ForbiddenMethodCall:
    active: true
    methods: ['java.util.concurrent.ExecutorService.submit', 'kotlin.io.println']

in a custom detekt.yml (which doesn't contain much else). I'm using the maven plugin and have it pointing to that config file. (I added println in there to try and test after the first one wasn't working.) It's not triggering for println calls or ExecutorService.submit calls. I tried adding another rule and that did work...so maybe I've just got something misconfigured for ForbiddenMethodCall ?

[gammax]

Do you have symbol resolution enabled?

[bbaldino]

Nope, unless it's on by default...didn't know about that

[gammax]

Yeah so ForbiddenMethodClass uses symbol resolution (that is experimental). To enable it you need to create a custom detektMain task and provide classpath and `jvmTarget`: https://detekt.github.io/detekt/groovydsl.html#using-type-resolution

[bbaldino]

Thanks! Looking now at how to configure that in the maven plugin.

[bbaldino]

How do people usually retrieve the classpath?

[gammax]

So you’re on Android right (saw your message in #ktlint), then it gets a bit tricker because of build variants. Ideally this should help: https://github.com/detekt/detekt/issues/2292

[bbaldino]

Oh, nope sorry this isn't on android...just normal jvm.

[gammax]

On a side note for us: we really need to work on this page https://detekt.github.io/detekt/type-and-symbol-solving.html

[bbaldino]

But I am using maven, not gradle

[gammax]

this isn’t on android...just normal jvm.

oops my bad, you’re right.

[bbaldino]

I was able to use ${java.class.path}, but I see lots of complaints about kotlin stdlib in detekt output

[gammax]

Does the rule work?

[bbaldino]

Nope, doesn't catch the issues (but they're in kotlin code, so that's likely why)

[bbaldino]

Ok, I have a couple java files in this repo too and I made a call to ExecutorService#submit there and it did catch it...so I think it's just a matter of the classpath not including the kotlin stdlib?

[gammax]

AFAIK Detekt should not even inspect Java source files 🤨

[bbaldino]

OH! You're right, it did catch them in the kotlin code!

[bbaldino]

It does dump a ton of errors though like: /Vp8UtilsTest.kt:56:32: error: cannot access built-in declaration '<http://kotlin.Int|kotlin.Int>'. Ensure that you have a dependency on the Kotlin standard library

[bbaldino]

It's weird that it works but seems to choke on all kotlin stdlib types

[gammax]

I don’t really know what is going on tbh. If you can open an issue on detekt with some reproducible test, we could look into it 👍

[bbaldino]

Ok, will take a shot at that

[bbaldino]

Ah, and I just noticed the rule forbidding println isn't detecting a use of println

[bbaldino]

I made a small repro project, but I feel like this is probably and issue with the classpath not including the kotlin classes

[bbaldino]

@gammax what is the configuration for setting the classpath in gradle?

[bbaldino]

I tried getting the output from mvn dependency:build-classpath and hard-coding that into the classPath field in the config for the maven plugin (it gives a string like /Users/bbaldino/.m2/repository/org/jetbrains/kotlin/kotlin-stdlib-jdk8/1.3.72/kotlin-stdlib-jdk8-1.3.72.jar:...), but I get complaints about warning: classpath entry points to a non-existent location...I dunno if that's from some sandboxing or something.

[bbaldino]

Ok, if I copy kotlin-stdlib-1.3.72.jar into the project directory and do <classPath>${java.class.path};${project.basedir}/kotlin-stdlib-1.3.72.jar</classPath> that does appear to work...