Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: implemented support for tracking #1228

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

warber
Copy link

@warber warber commented Nov 22, 2024

This PR

  • adds support for Tracking as per Spec

Related Issues

Fixes #1164

@warber warber marked this pull request as ready for review November 22, 2024 13:23
@warber warber requested a review from a team as a code owner November 22, 2024 13:23
import dev.openfeature.sdk.exceptions.GeneralError;
import dev.openfeature.sdk.exceptions.OpenFeatureError;
import dev.openfeature.sdk.exceptions.ProviderNotReadyError;
import dev.openfeature.sdk.exceptions.*;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please no star imports

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I think the IDE "optimized" this. I need to figure out how to configure IntelliJ to avoid wildcard imports for regular files while still allowing them for test files. This is probably still useful for things like static imports of Mockito assertions in tests...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i started with #1098 i should finish it, to prevent this in the future

Copy link

codecov bot commented Nov 22, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.46%. Comparing base (13811dc) to head (ae1e7c5).
Report is 2 commits behind head on main.

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #1228      +/-   ##
============================================
+ Coverage     93.07%   93.46%   +0.39%     
- Complexity      441      451      +10     
============================================
  Files            41       42       +1     
  Lines          1025     1056      +31     
  Branches         85       85              
============================================
+ Hits            954      987      +33     
+ Misses           44       43       -1     
+ Partials         27       26       -1     
Flag Coverage Δ
unittests 93.46% <100.00%> (+0.39%) ⬆️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@aepfli aepfli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you the changes look good, but please remove the start imports, and (personal preference) use assertJ for assertions. Plus the comment i wrote regarding the assertCode

Comment on lines 43 to 50
client.track("event");
client.track("event", ctx);
client.track("event", details);
client.track("event", ctx, details);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[suggestion] This code looks like it has no purpose, but we check if the code runs without issue. we should add here an assertion, to make it clear what the purpose is. we do have AssertJ available and there is assertThatCode(() -> {})..doesNotThrowAnyException(); see assertJ docs

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the intention was to explicitly "test" that the API aligns with the spec design. I wasn’t aware of AssertJ—thanks!

@aepfli
Copy link
Member

aepfli commented Nov 25, 2024

I will wait for a few more days, to give other @open-feature/sdk-java-maintainers the possibility to respond before merging this. Thank you for the contribution

@toddbaert
Copy link
Member

Will review tomorrow!

@lukas-reining
Copy link
Member

I will also have a look tomorrow if I find time :)

@@ -1,5 +1,6 @@
package dev.openfeature.sdk;

import javax.annotation.Nullable;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't allow usage of javax. We actually removed it from the SDK some time ago because it's very explicitly not allowed at some orgs, but it comes in transitively to this repo. Believe it or not, the Nullable annotation is present at runtime too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity are there other classes which should not be used, might be worth adding archUnit tests preventing those imports. But we should define a list for that.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dropped the @nullable hint (even though it would've been a nice touch).
Maybe we could consider creating our own annotation for that?

*/
@EqualsAndHashCode
@ToString
public class MutableTrackingEventDetails implements TrackingEventDetails {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think to be consistent with the rest if the SDK we should also implement a ImutableTrackingEventDetails.

Not exactly a blocker for me but I think it would be a good idea.

@@ -19,6 +11,16 @@
import lombok.Getter;
import lombok.extern.slf4j.Slf4j;

import javax.annotation.Nullable;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.



@Getter
private final float target;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
private final float target;
private final float value;

Looks like a copy/paste error here - this should be called value. I also think Number would be a better type since it will support all kinds of precision scenarios.

Copy link
Member

@toddbaert toddbaert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Defintely on the right track, please see:

In particular. These are blockers from my POV.

Copy link

sonarcloud bot commented Nov 28, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[FEATURE] Implement Tracking in Java SDK
4 participants