add support for feature flags

[msiebert]

API looks like:

LocalFlagsConfig localConfig = LocalFlagsConfig.builder()
     .pollingIntervalSeconds(60)
     .build();

MixpanelFlagsClient flagsClient = new MixpanelFlagsClient(
    "YOUR_PROJECT_TOKEN",
    localConfig
);

// Start polling for flag definitions
flagsClient.getLocalFlags().startPollingForDefinitions();

// Evaluate a flag
Map<String, Object> context = new HashMap<>();
context.put("distinct_id", "user-123");
boolean enabled = flagsClient.getLocalFlags().isEnabled("new-feature", context);

GitHub Copilot Summary

This pull request introduces feature flag support to the Mixpanel Java SDK, providing both local and remote evaluation modes. It updates the documentation to describe these new capabilities, adds demo examples, and modifies the main MixpanelAPI class to support feature flags configuration. The version is bumped to 1.6.0-flags, and build resources are updated to support new features.

Feature Flags Support:

• Added local and remote feature flag evaluation support to the SDK, allowing users to check feature flags and variants either via background polling (local) or real-time API calls (remote). This includes new constructors and internal logic in MixpanelAPI to handle feature flag clients. [1] [2] [3] [4] [5] [6] [7]

• Added two demo files, LocalEvaluationExample.java and RemoteEvaluationExample.java, to demonstrate usage of both local and remote feature flag evaluation. [1] [2]

Documentation Updates:

• Updated README.md to document the new feature flags support, including usage examples for both local and remote evaluation, and reorganized sections for clarity. [1] [2] [3] [4] [5] [6]

Build and Versioning:

• Bumped the SDK version to 1.6.0-flags in pom.xml to reflect the new feature flag functionality.
• Updated build resources in pom.xml to include filtering and resource management for .properties files.

[Copilot]

Pull Request Overview

This PR adds comprehensive feature flags support to the Mixpanel Java SDK, introducing both local and remote evaluation modes. Local evaluation provides fast, low-latency flag checks by polling flag definitions from the API and evaluating them client-side using deterministic hashing. Remote evaluation makes real-time API calls for each flag check.

Key changes:

• Complete feature flags implementation with local and remote evaluation modes
• FNV-1a hash-based variant selection algorithm for consistent user assignment
• Background polling mechanism for automatic flag definition synchronization
• Comprehensive test coverage for both evaluation modes

Reviewed Changes

Copilot reviewed 30 out of 30 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
MixpanelAPI.java	Integrated feature flags support with new constructors accepting LocalFlagsConfig/RemoteFlagsConfig
MixpanelFlagsClient.java	Main client coordinating local/remote providers and exposure tracking
LocalFlagsProvider.java	Implements local evaluation with polling and hash-based variant selection
RemoteFlagsProvider.java	Implements remote evaluation via API calls
BaseFlagsProvider.java	Base class providing shared HTTP functionality and evaluation helpers
HashUtils.java	FNV-1a hashing implementation for deterministic variant assignment
Model classes	Data structures for flags, variants, rollouts, and evaluation results
Config classes	Configuration builders for local and remote evaluation modes
Test files	Comprehensive unit tests for all providers and utility classes
Demo files	Example code demonstrating local and remote evaluation usage
README.md	Updated documentation with feature flags usage examples
pom.xml	Version bump and resource filtering configuration

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Corrected spelling of 'Goesthrough' to 'GoesThrough' in test method name.

Suggested change

	public void testIsQaTesterFalseWhenUserGoesthroughNormalRollout() {
	public void testIsQaTesterFalseWhenUserGoesThroughNormalRollout() {

[efahk]

Can this be simplified by invoking the MixpanelAPI(boolean useGzipCompression) after setting the flags client

[efahk]

Can we use this once & genericize the config passed to it

[efahk]

Given the form of this class, consider splitting the common behavior into an abstract flags client. Or maybe this can just go into the base/local/remote flagsproviders directly. Might not need another layer of indirection here

[efahk]

I'd drop the '-flags' from the version in the pom file. Kind of non-standard for semantic versioning

[msiebert]

I'd drop the '-flags' from the version in the pom file. Kind of non-standard for semantic versioning

@efahk I'd done this as sort of a nod to the idea we'd talked about where we wanted it to be beta. Should I just throw a -beta at the end of it?