Update cache to caffeine

[kirillovsky]

Hi! Looks like you use Guava only for caching. Did you consider to migrate from Guava to Caffeine?
Caffeine advantages:

• Caffeine has managed to optimize cache-related latency, equivalent throughput to Guava - https://stackoverflow.com/a/55501343
• Guava maintainers recommend using Caffeine, which is better updated and supported.
  Examples of comments from guava maintainers on this matter:
  • LocalCache computeIfAbsent updates write timestamp on existing entries, affecting expireAfterWrite caches google/guava#3700 (comment)
  • best Cache pattern for freezing keys on miss? google/guava#3972 (comment)
  • Can LoadingCache reset expire time? google/guava#3667 (comment)
    More examples - Consider Caffeine for Caching to Replace Guava After EOL of Java 7 Support newrelic/newrelic-java-agent#258 (comment)
• From the point of view of software architecture and security, it is preferable to use highly specialized libraries (Caffeine),
  compared to a large set of common utils that cover a large set of developer needs (Guava)

More other it's reduce Opa-Kafka-Plugin fat-jar size from 2.9MB to 917Kb

[anderseknert]

Thanks! I'm really out of the loop around most things JVM these days, but it seems reasonable to me. @scholzj, wdyt?

[scholzj]

I think originally, the use of Guava was good because Kafka already used Guava in the first place. However, that is not the case anymore and Kafka seems to be using Caffeine now as well (not sure what exactly they use it for and if the motivation for the change was the same as suggested here or completely different).

So I think moving to Caffeine might make sense. But as the Kafka 4.0 and latest main branch are using Caffeine 3.1, it would be good to understand if it works with that as well (I have no idea what the differences are between Caffeine 3.1 and 3.2 and if they are backward compatible - avoiding multiple versions on the classpath always makes things easier).

[scholzj]

I guess if we don't use it anymore, there is no reason to list it here?

[kirillovsky]

Removed

[scholzj]

There seem to be some white space changes here which will screw up the Git history. Can we keep only the real code changes and remove the whitespace changes?

[kirillovsky]

Removed please check

[anderseknert]

@kirillovsky LGTM, but could you please revert the whitespace changes so that we can merge this? Thanks!

[kirillovsky]

@anderseknert @scholzj Thanks for checking my PR. Fixed

[kirillovsky]

@anderseknert @scholzj Regarding useless whitespaces in my PR. It's happens case my IDEA automatically changes Line separator from LF (POSIX style) to CRLF (OS Windows style). But there is a way to avoid it automatically (via .gitattributes) - https://docs.github.com/en/get-started/git-basics/configuring-git-to-handle-line-endings#per-repository-settings. Can i add it to your repo? What do you think?

[anderseknert]

Sure! The majority of changes still look style related though? If you want to break up long lines or fix style issues, it's always better to do so in a PR only submitted for that purpose, as combining a change in behavior/semantics and style changes makes reviewing much more difficult. But that aside, looks good to me, and @scholzj is you agree, go ahead and merge.

[scholzj]

Thanks. LGTM.

[scholzj]

Sure! The majority of changes still look style related though? If you want to break up long lines or fix style issues, it's always better to do so in a PR only submitted for that purpose, as combining a change in behavior/semantics and style changes makes reviewing much more difficult. But that aside, looks good to me, and @scholzj is you agree, go ahead and merge.

Yeah, I agree that in general it is best to do such changes in a separate PR to have clearer history.