Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

java.lang.System.getLogger is incompatible with Android #763

Closed
vitorpamplona opened this issue Aug 28, 2022 · 4 comments
Closed

java.lang.System.getLogger is incompatible with Android #763

vitorpamplona opened this issue Aug 28, 2022 · 4 comments

Comments

@vitorpamplona
Copy link

Issue #456 described the decision to use JEP-264: Platform Logging API to redirect logs to slf4j. Unfortunately, Android has not provided a System.getLogger interface yet (I know, it sucks). This means that every use of 3.0+ on Android will simply crash on runtime.

A solution would use the org.slf4j:slf4j-api to abstract the desired logging frameworks without having a dependency on Java9.

@ben-manes
Copy link
Owner

ben-manes commented Aug 28, 2022

We don't support Android. If you only target that then using something like Store (NYTimes / Dropbox) or if multi-platform then consider using a facade like cache-api (Twitch) to swap to a more appropriate implementation. The needs of server and mobile caches favor different design decisions to optimize for, such as Android has lower concurrency requirements but byte/method count limits. For example during the development of Guava's Cache those discussions led the Android team to write LruCache because they did not think using Guava on mobile would make sense (which later popularity of proguard seemed to alleviate some of those concerns).

@vitorpamplona
Copy link
Author

It's too bad. 2.9 works great on Android. We have been using for quite some time without any issues.

@ben-manes
Copy link
Owner

ben-manes commented Aug 28, 2022

You are welcome to continue using 2.x, as that remains supported. It just has never been the focus of this library. More recently it seems that the Android community has pushing Kotlin and its multi-platform support as a reason to rewrite away from Java (as that is not transcoded). That would put pressure to have Caffeine rewritten, e.g. Dropbox translated Guava's Cache to Kotlin for their usage in Store, which server-side folks might dislike (e.g. a lot of grumbling due to Okthttp's changes). The communities are diverging and I think best served by experts in their respective areas.

@vitorpamplona
Copy link
Author

vitorpamplona commented Aug 28, 2022

Communities try to diverge but, in the end, they always come back together (or just don't block each other). It has been the story of the past 23 years in Java. They need each other way more than they realize.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants