fix: isList check in Value checks type of list

[rgrassian-split]

A list of any type would be able to be created due to the new object constructor. This makes it so that the isList check only returns true if the list contains objects of type Value (or is empty).

[codecov-commenter]

Codecov Report

Merging #70 (d13a310) into main (00af2f8) will increase coverage by 0.05%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##               main      #70      +/-   ##
============================================
+ Coverage     91.27%   91.32%   +0.05%     
- Complexity      159      162       +3     
============================================
  Files            19       19              
  Lines           344      346       +2     
  Branches         14       16       +2     
============================================
+ Hits            314      316       +2     
  Misses           21       21              
  Partials          9        9              

Flag	Coverage Δ
unittests	91.32% <100.00%> (+0.05%)	⬆️

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

Impacted Files	Coverage Δ
src/main/java/dev/openfeature/javasdk/Value.java	88.40% <100.00%> (+0.34%)	⬆️

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

[rgrassian-split]

@justinabrahms @toddbaert please check out this PR, as I was updating the Split Provider I noticed it would be possible to set a list of any time due to the new constructor. This change should make it so that only lists containing Values are allowed to be created through that constructor

[toddbaert]

Thanks for adding this check. I think we'll have a similar issue in dotnet too. I will address it there.

[toddbaert]

Thinking about it more, would it be better to instead check that the list type is sane when we instantiate the value? The Object constructor already throws. We could add this same test on the object constructor and throw if the List is not of type value. That way, it's impossible to ever create such a value. @rgrassian-split

[rgrassian-split]

Thinking about it more, would it be better to instead check that the list type is sane when we instantiate the value? The Object constructor already throws. We could add this same test on the object constructor and throw if the List is not of type value. That way, it's impossible to ever create such a value. @rgrassian-split

@toddbaert Can you elaborate, I'm a bit confused. Right now the object constructor calls the isList method which would fail so it's impossible to create a value that is a list of things other than values.

Also as an fyi, it turned out that this object constructor was less useful than we thought it would be and I'm not sure we will end up using it for our Split Provider. The reason being if we have on our end something like a List<String> and want it as a value we would really want to turn this into something like Value<List<Value<String>>>, but the object constructor can't do that for us so that's a case we still have to handle special.

The fetching as an object has been very useful though thanks for that

[toddbaert]

@rgrassian-split oof, I misread the test, and didn't recall that isList() is called from the object constructor - so the net behavior you've implemented is basically what I was hoping for.