Loading...
Java enterprise projects tend to wrap Split.io behind abstraction layers and Spring configuration classes. FlagShark traces through those layers to find every treatment evaluation and maps it to your Split environment.
FlagShark generates a PR that removes the dead branch and keeps only the winning code path
@Service
public class PaymentService {
private final SplitClient splitClient;
public PaymentService(SplitClient splitClient) {
this.splitClient = splitClient;
}
public PaymentResult process(String userId, PaymentRequest req) {
String treatment = splitClient.getTreatment(userId, "payment-processor");
if ("stripe-v2".equals(treatment)) {
return stripeV2Processor.process(req);
} else if ("adyen".equals(treatment)) {
return adyenProcessor.process(req);
}
return stripeV1Processor.process(req); // control
}
}@Service
public class PaymentService {
public PaymentResult process(String userId, PaymentRequest req) {
return stripeV2Processor.process(req);
}
}FlagShark uses Annotation scanning and Java AST for SDK method detection to find every call to getTreatment(), getTreatments(), track()across your Spring Boot, Micronaut codebase.
Each detected flag key is matched against your Split.io project to check rollout status, last evaluation date, and whether the flag is archived or still active.
For each stale flag, FlagShark creates a pull request that removes the SDK call, eliminates the dead code branch, and preserves the winning path. Every PR includes a before/after diff you can review.
Split.io's Java SDK requires explicit `destroy()` calls to flush events — if your codebase has a `@PreDestroy` method that calls `splitClient.destroy()`, removing all flags means that lifecycle method becomes orphaned too.
Grep misses flags behind abstractions. AST-level scanning catches SDK calls that regex can't.
Every cleanup goes through code review. No surprises, no broken builds.
Only flags at 100% rollout for your configured threshold are suggested for removal.
New stale flags are detected automatically. Your codebase stays clean without manual audits.
getTreatment()getTreatments()track()Plus custom patterns you define in .flagshark.yaml
FlagShark scans for `SplitClient` bean injections via constructor or field injection, then traces every `getTreatment` and `getTreatments` call. It resolves treatment string comparisons to identify each code branch.
Yes. FlagShark follows the call chain through wrapper classes that delegate to `SplitClient`. If your team has a `FeatureFlagService` that internally calls `getTreatment`, FlagShark traces through it.
FlagShark identifies `track` calls co-located with treatment checks and marks them for review. It also detects impression listeners registered at SDK initialization time.
Connect your repo, see stale flags in minutes, and get cleanup PRs automatically.
Free tier available • No credit card required • 5-minute setup
Detect and remove abandoned Split.io treatments from your TypeScript frontend and Node.js backend.
Find and clean up stale Split.io feature flag treatments in Django, FastAPI, and Flask projects.
Identify and safely remove stale Split.io treatments from Go services using AST-based analysis.
Detect and clean up stale Split.io feature flags in Rails and Sinatra applications.
Practical guide to removing stale LaunchDarkly flags from Spring Boot and Micronaut applications.
Find and remove dead Unleash toggles from Spring Boot applications and Java microservices.
Find and remove dead PostHog flags from Spring Boot and Java backend services.
Find and safely remove stale ConfigCat feature flags from Spring Boot and Java enterprise applications.