An equivalent to this test didn't previously exist, but I think it's important to verify that thread interruption works since there needs to be a way to cancel blocking operations.

I think dropping in a mutually compatible library is fine. However, we faced a similar challenge with PHP and caching, and opted to have the upstream SDK essentially pass in the library. I wonder if we should consider doing similar here, basically having this SDK take an interface that can Base64 encode/decode and then Java SDK will pass in something that uses java.util.Base64 and Android SDK something that uses android.util.Base64?

Note it seems you're doing something similar for JSON mapping

I thought of that too, but since this is a static method, it will require me to add a lot more indirection in the SDK. If you're ok with that level of indirection, I can add it.

The added indirection is OK.
What do you think about a "compatibility" class to capture everything, like

interface EppoApiCompat {
String base64Encode(...)}
FlagConfigResponse parseUfcJson(String...)
...
// could do string joining, but the algo is simple enough to just have our own loop.
String joinStrings(String[] arrayOfStrings){...}
}

It can be an param to the EppoClient constructor and be passed around as needed. Test harnesses can use a default implementation based on java.util here (or android.util in android-sdk). wdyt?

That sounds good to me. We're still investigating whether we want to modify the Eppo SDK further, so I won't make this update yet, but if we decide to press forward, I'll definitely incorporate this change.

Would we want to stay away from Jackson-specific stuff here?

I vaguely recall one of the main reasons we used Jackson is because it could more easily differentiate between arrays and objects than Java's built-in JSON parsing. But if we code around that, we may be able to remove Jackson entirely. Unless it's much slower on parsing, which may matter for Android app initialization times. In which case, I think upstream-provided parser as you're doing here may be the move.

Since this API returns a Jackson-specific type, we must rely on Jackson in this specific method. I might create a parallel method that returns a MapperNode when I finalize this PR

To help maximize code reuse and prevent drift, what if this extends the non-java-6 flavor and then uses the template pattern, with only the language level differences overwritten in the ConfigurationRequestorJava6 class?

Note: I don't know if this is possible for building. A quick chat with AI suggests its not, and what you have is the way to go 😞

Would we end up in callback hell if we just refactored the core to use callbacks instead of CompletableFutures? The initialization code is certainly cleaner with CompletableFutures

I'd actually like to get rid of CompletableFuture if possible and provide callbacks because CompletableFuture relies on the ForkJoin Pool, and clients would probably like to minimize the number of thread pools in their apps.

You could certainly provide wrapper APIs that expose CompletableFuture, but some clients are going to use RxJava (which has its own thread pools), and some will use Kotlin coroutines (which has its own thread pools). I imagine customers would like to avoid creating one more thread at startup if possible.

A simple way to do this would be to provide a synchronous API like I did here, and then provide a CompletableFuture wrapper around it.

I agree that moving a direction of un-opinionated (i.e. un thread-pool coupled) async/futures/callbacks is ideal in an SDK that is used across such a vast array of deployments.

In your opinion, what is the "async" API that most java developers would prefer to see on the SDK? Callbacks, CompletableFutures or something else? I am eager to get your feedback here.

I think callbacks make the most sense, and then if you wanted to go for extra credit, you could publish extension libraries with RxJava2, RxJava3, Kotlin Coroutines, and CompletableFutures bindings.

Modern Android developers are mostly using Kotlin Coroutines now. RxJava2 was common until about 2020, so there are probably still a lot of apps out there using it. I don't think RxJava3 is very common because it came out around the same time as Kotlin Coroutines.

Ah this is to avoid a trailing delimiter 👌

I could also do:

for (Iterator<String> i = this.stringArrayValue; i.hasNext();) {
  String string = i.next();
  stringBuilder.append(string);
  if (i.hasNext()) {
    stringBuilder.append(delimiter);
  }
}

I think this 👆 is more readable.

I wonder if to remove code duplication and keep tests in sync we could have one test suite that using a data provider or something runs each test on both implementations. Although things may get funky with mocking, but perhaps we could have an abstract parent class or shared helper methods or something.

I could create some abstractions to reduce duplication, but I find that too much abstraction in tests obscures the point of the test itself, so I'm generally ok with copypasta in test-land.

I also like this as a separate class because it establishes strong boundaries between Java6-land and Java8-land.

However, if this doesn't match the philosophy of your project, I'm happy to refactor.

I think this 👆 is more readable.

The added indirection is OK.
What do you think about a "compatibility" class to capture everything, like

interface EppoApiCompat {
String base64Encode(...)}
FlagConfigResponse parseUfcJson(String...)
...
// could do string joining, but the algo is simple enough to just have our own loop.
String joinStrings(String[] arrayOfStrings){...}
}

It can be an param to the EppoClient constructor and be passed around as needed. Test harnesses can use a default implementation based on java.util here (or android.util in android-sdk). wdyt?

Would we end up in callback hell if we just refactored the core to use callbacks instead of CompletableFutures? The initialization code is certainly cleaner with CompletableFutures