-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
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). |
It's too bad. 2.9 works great on Android. We have been using for quite some time without any issues. |
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. |
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. |
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.The text was updated successfully, but these errors were encountered: