Hi folks! If you had a tool that could look throug...

# library-development

[Alexander Sysoev]

Hi folks!
If you had a tool that could look through your public APIs and report to you the ones you'd want to avoid having, what would you want this tool to detect?
As an example, it could've reported to you that using data classes is probably not the best idea, for reasons blah blah blah...

[Zac Sweers]

android lint and detekt are the canonical tools for this. I think there'd need to be a strong case (and IDE support) for introducing another one to our codebase

[hfhbd]

Does android lint support reporting method calls that should not be called? 👀

[Zac Sweers]

yeah

[Zac Sweers]

it has full access to PSI/UAST/KA

[Zac Sweers]

though it only runs in the IDE in android studio I think, really wish that would be unbundled as it's quite good and a better experience than detekt IMO

[hfhbd]

Yeah, but does it also include running the checks against class code published as a jar or source code only?
My usecase is to have a statically replacement of the deprecated security manager

[Alexander Sysoev]

Interesting. These two are general linters, do they have enough rules for your public APIs cases?

[Zac Sweers]

You can run against binaries but I wouldn't say it's best practice (though the default recommendation in android’s docs will end up doing that)

[Zac Sweers]

Neither has a public API lint like the one you described out of the box but they make it trivial to write custom lints that would enforce that

[Alexander Sysoev]

Still though, it can be rules for either of these too. I'm interested in what kind of rules you'd like to have

[Zac Sweers]

as default rules?

[Alexander Sysoev]

Yes, ones that by default would tell you if some APIs you are exposing to users are probably not good in one way or another

[Julia McClellan]

Android/AndroidX has metalava, which among other API tracking functionality runs various checks on the public API surface based on the Android API guidelines and Java/Kotlin interop guidelines

[Zac Sweers]

Ah if this is just ABI validation stuff then the biggest gap right now is there's no way to enforce compatibility with an older version. For example, with japicmp you can indicate the 1.0.0 version of a library and it'll enforce against that

[russhwolf]

Yeah having something to enforce compatibility would probably be the most useful thing. I also think warnings around potentially hard-to-evolve APIs would be helpful (like the data class example) but I don't know where the line is where that could start to feel too opinionated.

[Brais Gabin]

These are the specific rules for library developers that detekt has: https://detekt.dev/docs/rules/libraries/ it also have a ForbiddenMethodCall rule that is really handy.

But I also agree that a tool to enforce compatibility (binary compatibility & code compatibility) right now is a missing piece (and for sure detekt can't do that)