Java SDK Update

[michaelkimball]

We're actively working on a refreshed Android SDK

When V3 of that SDK is released we plan to base the Java SDK off the same kotlin source. We'll take it out of beta at that point.

Originally posted by @pauldambra in #45 (comment)

I see that the V3 of the Android SDK was released back in December. How is the update of this SDK going? Are we able to use this https://github.com/PostHog/posthog-android/tree/main/posthog library without Android? (https://mvnrepository.com/artifact/com.posthog/posthog I believe). If so, can the docs https://posthog.com/docs/libraries/java be updated to reflect the new usage?

[marandaneto]

Hi @michaelkimball

Sadly not yet since https://github.com/PostHog/posthog-android/tree/main/posthog uses local storage caching which isn't available on non-Android devices.
The most important part missing is implementing in-memory caching, so events are cached in memory and sent in batches, probably a few other small changes but not much more.
The other thing is context isolation, since PostHog is a static class, it works for a single-user context but not for backend apps in which each request coming in is a different user, eg calling identify on thread A cannot leak to thread B, etc (Thread-local storage or allow one single instance per thread).
Those are the 2 major things that should change.

I cannot promise but I'll bring it into our Q2-24 plan, we are focused on making PostHog more mobile-friendly in Q1, stay tuned.

I'd be very happy to guide you in case you are willing to contribute and submit a PR though.

[marandaneto]

Relates to PostHog/posthog#16419

[martypitt]

Hey there! Just wondering if there's any updates here? Lack of decent logging controls in posthog-java (#53) has become a problem for us.

I'd happily raise the PR to fix this, but the project seems abandoned - wondering what the best path forward is, given plans for a rewrite.

[pauldambra]

👋 hey, not abandoned... but not many folks asking us for things :)

we still plan to unify things so that android and java sdks are based on the same kotlin core but it's not happened yet

[martypitt]

Thanks @pauldambra

If I were to pick up the fix for #53 and add in SLF4J instead of printing to stdout / stderr, would that:

• Be an acceptable approach?
• Be able to be merged / released?

[pauldambra]

I'll let @marandaneto have the final say - he'll have the good feel for length of time until any kotlin switcheroo

[pauldambra]

But @martypitt... it's a good 4 years since I regularly wrote java 🙈

if SLF4J is still the default totally happy to consider a PR

[marandaneto]

But @martypitt... it's a good 4 years since I regularly wrote java 🙈

if SLF4J is still the default totally happy to consider a PR

SLF4J is an abstraction of logging in general so it'd work with a few of the most popular ones such as logback, log4j, java logging, etc.

[marandaneto]

Thanks @pauldambra

If I were to pick up the fix for #53 and add in SLF4J instead of printing to stdout / stderr, would that:

• Be an acceptable approach?
• Be able to be merged / released?

Yes, the intention is that we stop using this SDK and start using this one instead.
addressing those points before though.
I did give it a try here and in the end, we have agreed to focus on something else until we have the time to do a proper refactoring and implement a stateless interface that would require a major breaking change for the Android SDK.
That said, since SLF4J is separated from the core logic of the Java SDK, I think it'd be fair to bring this in and later on just port the SLF4J bits to the Java core SDK.
Happy to review the contribution =)