You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add support for multi-valued status filter in tasks API #315
To support filtering by multiple statuses, I suggest adding a new method with a different name, like listTasksMultipleStatuses(...)
Overloading the existing listTasks(...) with a EnumSet version causes issues when passing null, since Java can’t tell whether it's meant to be a Status or a EnumSet
Hence it breaks existing code like:
listTasks(projectId, null, null, null, null);
Other solutions I looked at were either too complex or introduce breaking changes.
A separate method is the simplest and safest solution with no breaking changes
Let me know if adding new method with different name sounds like a good idea
Yes, something like this. This approach is ideal when we have many optional parameters. It's also very easy to update this class when we add new parameters to the API and maintain backward compatibility with existing users.
Activity
Rituraj2610 commentedon Apr 2, 2025
Hii, Can you help me understand more about this project?
andrii-bodnar commentedon Apr 2, 2025
Hi @Rituraj2610, please refer to the CONTRIBUTING guide.
korzol commentedon Sep 22, 2025
Hello. I can get this issue as well. Kindly assign it to me
korzol commentedon Sep 22, 2025
Hello @andrii-bodnar
To support filtering by multiple statuses, I suggest adding a new method with a different name, like listTasksMultipleStatuses(...)
Overloading the existing listTasks(...) with a EnumSet version causes issues when passing null, since Java can’t tell whether it's meant to be a Status or a EnumSet
Hence it breaks existing code like:
listTasks(projectId, null, null, null, null);Other solutions I looked at were either too complex or introduce breaking changes.
A separate method is the simplest and safest solution with no breaking changes
Let me know if adding new method with different name sounds like a good idea
andrii-bodnar commentedon Sep 22, 2025
Hello @korzol,
I believe we can still have the overloaded
listTasksmethod. For example, take a look at thelistScreenshotsimplementation:crowdin-api-client-java/src/main/java/com/crowdin/client/screenshots/ScreenshotsApi.java
Lines 60 to 68 in 027181e
There are three different overloaded methods for this case. It also has a similar requirement with the comma-separated values.
In our case, we could probably create another
listTaskswithList<Status> status. Please let me know what you think.korzol commentedon Sep 23, 2025
Thanks for the example with listScreenshots
The reason the overloads work fine there is that the method signatures differ not only by types but also by the number of parameters:
So even if null is passed, Java can clearly resolve which method to call based on the number of arguments.
In the case of listTasks(), we have two overloads:
These ^ have the same number of parameters, and both Status and EnumSet can accept null. So when calling:
listTasks(projectId, null, null, null, null);Java throws an "ambiguous method call" error — it doesn't know which method to use.
I see these possible ways to make overload works:
Explicitly cast null to make the call unambiguous, like:
listTasks(projectId, null, null, (Status) null, null);Use a different method signature (e.g. different number of arguments)
Use a differently named method for the multiple-status case
Never use it like
listTasks(projectId, null, null, null, null);Kindly let me know what you think - happy to adjust the approach based on feedback
andrii-bodnar commentedon Sep 23, 2025
@korzol thanks for the explanation!
Can we then have an overload like this:
listScreenshots(Long projectId, ListScreenshotsParams params)?korzol commentedon Sep 23, 2025
@andrii-bodnar Absolutely. Will do it like this
listTasks(Long projectId, ListTasksParams params)andrii-bodnar commentedon Sep 23, 2025
Yes, something like this. This approach is ideal when we have many optional parameters. It's also very easy to update this class when we add new parameters to the API and maintain backward compatibility with existing users.
korzol commentedon Sep 23, 2025
Thank you. Of course, this is definitely the cleanest and most flexible way to support optional parameters and future-proof the API.
feat: Support for multivalued status as described in issue crowdin#315.
korzol commentedon Sep 23, 2025
@andrii-bodnar PR is ready for review #334
feat: Support for multivalued status as described in issue crowdin#315.