fix: getState mandatory on EventProvider

[toddbaert]

In 3 event provider implementations, flagd-java, go-feature-flag-web, and even my own implementation of flagd-js, authors have forgotten to properly implement getState (which means the SDK assumes the provider is already READY and doesn't run initialize().)

This is an easy pitfall. To help with this, I'm making the implementation of getState required in the abstract EventProvider class, and will do similarly in the JS-SDK. I think this is a reasonable proposal because the EventProvider class is very new, and in the majority of cases a provider that can fire async events requires some kind of remote connection, so it will need initialization. This is technically a breaking change, but it would only impact the experimental events API, specifically the EventProvider implementations which could only be a few days old at this point, and which (due to my previous point) likely should have implemented this anyway.

It also adds some more doc about the importance of this method.

Relates to: open-feature/js-sdk#506

[codecov]

Codecov Report

Merging #531 (527c9f7) into main (8789f90) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               main     #531   +/-   ##
=========================================
  Coverage     95.36%   95.36%           
  Complexity      330      330           
=========================================
  Files            31       31           
  Lines           755      755           
  Branches         37       37           
=========================================
  Hits            720      720           
  Misses           18       18           
  Partials         17       17           

Flag	Coverage Δ
unittests	95.36% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed	Coverage Δ
...c/main/java/dev/openfeature/sdk/EventProvider.java	100.00% <ø> (ø)
...main/java/dev/openfeature/sdk/FeatureProvider.java	100.00% <ø> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[thisthat]

I support this change 👍
Should we provide an annotation to mark specific APIs experimental to feel less guilty when we do breaking changes? 🤔
Something similar exists in other projects:

• Guava
• gRPC

[toddbaert]

I support this change +1 Should we provide an annotation to mark specific APIs experimental to feel less guilty when we do breaking changes? 🤔 Something similar exists in other projects:

• Guava
• gRPC

This is an interesting idea IMO. Can you elaborate more on the user-experience of this? Does the annotation add something that developers can easily see in their IDE? Does it suppose a dev would open the source file? @thisthat

[thisthat]

This is an interesting idea IMO. Can you elaborate more on the user-experience of this? Does the annotation add something that developers can easily see in their IDE? Does it suppose a dev would open the source file? @thisthat

AFAIK, no IDE prints any special info for annotations. However, when I work on implementing an interface/abstract class I do look in the source file. Annotations are preserved in case of decompilation. It would be just a "FYI" for implementers.

[toddbaert]

This is an interesting idea IMO. Can you elaborate more on the user-experience of this? Does the annotation add something that developers can easily see in their IDE? Does it suppose a dev would open the source file? @thisthat

AFAIK, no IDE prints any special info for annotations. However, when I work on implementing an interface/abstract class I do look in the source file. Annotations are preserved in case of decompilation. It would be just a "FYI" for implementers.

OK that's kinda what I was assuming. I still like the idea.

[toddbaert]

At a minimum we should add these docs, but I think the small breaking change below is worth adding.

[Kavindu-Dodan]

Approved. We can make this a breaking change and bump the minor version. Given that the eventing support is new, I assume there are only a handful of adoptions of the previous sdk version.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

No Coverage information
0.0% Duplication