Can we make the API more explicit? about unleash-client-java HOT 5 CLOSED

If this is changed, I'd highly prefer an API that can compile-time checked.

As in, don't expose the current constructor, but have something like public static Unleash startPolling() in a UnleashBuilder or something like that. If that's not wanted, an IllegalStateException has to be thrown, defaulting to some other state is way more surprising and error-prone IMO.

Not sure if this is really needed though.

The way unleash is implemented now it is not really intuitive for the developer.

How so?

We see from time to time this ending up with memory leakage because the developer creates a new unleash instance per request handler.

Could all the clients use a static poller and metrics publisher so they all share that one instance instead? So you can instantiate multiple UnleashClients without worry

from unleash-client-java.

Could all the clients use a static poller and metrics publisher so they all share that one instance instead?

Unleash already uses just one static poller shared among all instances of unleash. This does not solve the memory leakage problem though, as they all register a callback.

The way unleash is implemented now it is not really intuitive for the developer.

It seems like developers does not realise that Unleash is a service, which will be running in the background, even after the thread creating it is terminated. Maybe we can do some magic around the initiating thread being terminated? Or unleash could detect if it is being instantiated thousands of times and give some kind of warning?

If this is changed, I'd highly prefer an API that can compile-time checked.

Yes, I agree, some kind of builder/factory is the way to go! But I still feel a bit reluctant to changing the API of Unleash. It will be confusing for people upgrading the client if they suddenly have to call a builder/factory.

from unleash-client-java.

The goal should be to make it harder/impossible to do the wrong thing without making it verbose to do the right thing.

Talked some offline with @theneva, any objection against using WeakReference?

from unleash-client-java.

Would be nice if that just works, have no personal experience using WeakReference in Java.

Care to make a PoC on using it?

from unleash-client-java.

closed via #67

from unleash-client-java.