detekt extension that shamelessly kangs IntelliJ annotations. may probably not be needed once Jetbrains releases their gradle/maven plugin to do the same.
Inspections provided:
- BlockingCallContext: inspect blocking method calls within non-blocking context
- BlockingCallContextReclaimable: infer blocking calls within
Dispatchers.IOcontext which can be migrated to non-blocking alternatives - JerseyMethodParameterDefaultValue: infer if a probable jersey method contains a parameter with a default value
requires type resolution, so ensure you are setting the --classpath argument
java -jar detekt-cli-1.16.0-all.jar \
--plugins sidekt-1.0-SNAPSHOT.jar \
--classpath 'dep1.jar:dep2.jar' \
--jvm-target 1.8 \
--input 'src/' \
--config defalt-detekt-config.ymlfind a way to fail the build if these errors come up by setting very high weights
build:
maxIssues: 99999 # ...? not sure what's a better way to _force_ an error
excludeCorrectable: false
weights:
BlockingCallContext: 100000
JerseyMethodParameterDefaultValue: 100000sidekt:
BlockingCallContext:
active: true
# debug: 'stderr'
blockingMethodAnnotations: ['com.custom.annotations.BlockingCall']
blockingMethodFqNames: ['com.custom.wrapper.runBlocking']
blockingExceptionTypes: ['com.amazonaws.http.timers.client.SdkInterruptedException']
ioDispatcherFqNames: ['com.custom.Dispatchers.DB']
reclaimableMethodAnnotations: ['com.custom.annotations.ReclaimableBlockingCall']
reclaimableMethodFqNames: ['com.custom.wrapper.getSync']
blockingClassAnnotations: ['com.custom.annotations.BlockingClass']
blockingClassFqNames: ['com.custom.dao.SomeDao']
prints a whole lot of debug information, please do not set this.
takes one of 'stdout', 'stderr', or a directory path
these are the annotations which you may use in your code to denote blocking methods
in case the annotations marking the method as blocking cannot be inferred (probably due to annotation retention at SOURCE), then, such known methods' FQ names can be configured
methods annotated with @kotlin.jvm.Throws, and which end up throwing certain exceptions, can be used to identify blocking
methods.
please note: this will only work for methods in your own source code, and cannot come from the classpath since @kotlin.jvm.Throws
annotation retention is at SOURCE
blocking calls are allowed within specific dispatchers, namely, Dispatchers.IO; given they are specifically for the purpose. in case you have an additional IO dispatcher, you may configure the same
albeit dispatchers specifically meant for IO are meant for such "blocking" calls, there may be certain methods which already provide non-blocking method alternatives. such methods may be annotated with a distinct annotation, and configured
same as reclaimableMethodAnnotations, but allowing you to provide FQ names to the methods
these are the annotations which you may use in your code to denote blocking classes.
similar to blockingMethodAnnotations, for classes.
in case the annotations marking the class as blocking cannot be inferred (probably due to annotation retention at SOURCE), then, such known classes' FQ names can be configured.
similar to blockingMethodFqNames, for classes.
sidekt:
JerseyMethodParameterDefaultValue:
active: true
# debug: 'stderr'JerseyMethodParameterDefaultValue
this is in reference to the following issues; even with this being "fixed" (as in, not crash at runtime) in later versions, this is a pitfall; since nullable parameters always get set to null (due to how method matching works), and non-nullable values, if primitives, get set to the default values, and if not, throw a "Parameter specified as non-null is null" error on invocation.