You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Alexey Romanenko <ar...@gmail.com> on 2020/09/18 15:21:36 UTC
Check for enough access to classes/methods of public API
Hello,
In Java SDK, from time to time we face with an issue with an access to classes or methods, that are explicitly supposed to be as a part of public user’s API, but, by mistake, are made private or package-private.
For example this issue [1], where KinesisClientThrottledException is package-private but it can be an argument in a public method of RateLimitPolicy interface if user wishes to implement its own.
// public interface
public interface RateLimitPolicy {
default void onThrottle(KinesisClientThrottledException e)
}
// package-private interface in the same package
class KinesisClientThrottledException {
…
}
So user won’t be able to implement it’s own RateLimitPolicy with overridden onThrottle() method since KinesisClientThrottledException is package-private
Does anyone know a tool or something like compilation option or Spotless check, that can detect a broken API at compilation time in case if, for example, arguments of public method don’t have enough access privileges for that? It would be very helpful to prevent such errors.
[1] https://issues.apache.org/jira/browse/BEAM-10816
Re: Check for enough access to classes/methods of public API
Posted by Alexey Romanenko <ar...@gmail.com>.
Yes, I also was thinking about that, but we have to change a package name pattern for all tests that test public API in this case. So it will require quite a lot of changes, no? Do I miss something?
> On 22 Sep 2020, at 18:37, Kenneth Knowles <ke...@apache.org> wrote:
>
> Another thing that can help is to put tests in a separate package. Then anything that is tested you cannot accidentally leave private. Of course if there is no test then it will not catch it. It can help make unit tests better by not testing implementation details. But when you do want to do some implementation detail test it is slightly less convenient - @VisibleForTesting stuff becomes always fully public.
>
> Kenn
>
> On Fri, Sep 18, 2020 at 9:43 AM Alexey Romanenko <aromanenko.dev@gmail.com <ma...@gmail.com>> wrote:
> Yes, the “friend” concept could not help with that. As a workaround, anyway user can make a class/method public with reflection.
>
> This error is quite rare but the problem that usually it can be noticed only when this broken API is started to be using, so after the release had already been happened.
>
>
>> On 18 Sep 2020, at 17:48, Luke Cwik <lcwik@google.com <ma...@google.com>> wrote:
>>
>> I only know of tooling that can be used to make sure that the existing API doesn't change.
>>
>> Also there isn't an explicit "friend" concept in Java but people do sometimes orchestrate public classes with methods that restrict who can use them[1] but I don't think this is a case of that.
>>
>> 1: https://stackoverflow.com/questions/14226228/implementation-of-friend-concept-in-java <https://stackoverflow.com/questions/14226228/implementation-of-friend-concept-in-java>
>> On Fri, Sep 18, 2020 at 8:21 AM Alexey Romanenko <aromanenko.dev@gmail.com <ma...@gmail.com>> wrote:
>> Hello,
>>
>> In Java SDK, from time to time we face with an issue with an access to classes or methods, that are explicitly supposed to be as a part of public user’s API, but, by mistake, are made private or package-private.
>>
>> For example this issue [1], where KinesisClientThrottledException is package-private but it can be an argument in a public method of RateLimitPolicy interface if user wishes to implement its own.
>>
>> // public interface
>> public interface RateLimitPolicy {
>> default void onThrottle(KinesisClientThrottledException e)
>> }
>>
>> // package-private interface in the same package
>> class KinesisClientThrottledException {
>> …
>> }
>>
>> So user won’t be able to implement it’s own RateLimitPolicy with overridden onThrottle() method since KinesisClientThrottledException is package-private
>>
>> Does anyone know a tool or something like compilation option or Spotless check, that can detect a broken API at compilation time in case if, for example, arguments of public method don’t have enough access privileges for that? It would be very helpful to prevent such errors.
>>
>>
>> [1] https://issues.apache.org/jira/browse/BEAM-10816 <https://issues.apache.org/jira/browse/BEAM-10816>
Re: Check for enough access to classes/methods of public API
Posted by Kenneth Knowles <ke...@apache.org>.
Another thing that can help is to put tests in a separate package. Then
anything that is tested you cannot accidentally leave private. Of course if
there is no test then it will not catch it. It can help make unit tests
better by not testing implementation details. But when you do want to do
some implementation detail test it is slightly less convenient -
@VisibleForTesting stuff becomes always fully public.
Kenn
On Fri, Sep 18, 2020 at 9:43 AM Alexey Romanenko <ar...@gmail.com>
wrote:
> Yes, the “friend” concept could not help with that. As a workaround,
> anyway user can make a class/method public with reflection.
>
> This error is quite rare but the problem that usually it can be noticed
> only when this broken API is started to be using, so after the release had
> already been happened.
>
>
> On 18 Sep 2020, at 17:48, Luke Cwik <lc...@google.com> wrote:
>
> I only know of tooling that can be used to make sure that the existing API
> doesn't change.
>
> Also there isn't an explicit "friend" concept in Java but people do
> sometimes orchestrate public classes with methods that restrict who can use
> them[1] but I don't think this is a case of that.
>
> 1:
> https://stackoverflow.com/questions/14226228/implementation-of-friend-concept-in-java
>
> On Fri, Sep 18, 2020 at 8:21 AM Alexey Romanenko <ar...@gmail.com>
> wrote:
>
>> Hello,
>>
>> In Java SDK, from time to time we face with an issue with an access to
>> classes or methods, that are explicitly supposed to be as a part of public
>> user’s API, but, by mistake, are made private or package-private.
>>
>> For example this issue [1], where KinesisClientThrottledException is
>> package-private but it can be an argument in a public method of
>> RateLimitPolicy interface if user wishes to implement its own.
>>
>> // public interface
>> public interface RateLimitPolicy {
>> default void onThrottle(KinesisClientThrottledException e)
>> }
>>
>> // package-private interface in the same package
>> class KinesisClientThrottledException {
>> …
>> }
>>
>> So user won’t be able to implement it’s own RateLimitPolicy with
>> overridden onThrottle() method since KinesisClientThrottledException is
>> package-private
>>
>> Does anyone know a tool or something like compilation option or Spotless
>> check, that can detect a broken API at compilation time in case if, for
>> example, arguments of public method don’t have enough access privileges for
>> that? It would be very helpful to prevent such errors.
>>
>>
>> [1] https://issues.apache.org/jira/browse/BEAM-10816
>
>
>
Re: Check for enough access to classes/methods of public API
Posted by Alexey Romanenko <ar...@gmail.com>.
Yes, the “friend” concept could not help with that. As a workaround, anyway user can make a class/method public with reflection.
This error is quite rare but the problem that usually it can be noticed only when this broken API is started to be using, so after the release had already been happened.
> On 18 Sep 2020, at 17:48, Luke Cwik <lc...@google.com> wrote:
>
> I only know of tooling that can be used to make sure that the existing API doesn't change.
>
> Also there isn't an explicit "friend" concept in Java but people do sometimes orchestrate public classes with methods that restrict who can use them[1] but I don't think this is a case of that.
>
> 1: https://stackoverflow.com/questions/14226228/implementation-of-friend-concept-in-java <https://stackoverflow.com/questions/14226228/implementation-of-friend-concept-in-java>
> On Fri, Sep 18, 2020 at 8:21 AM Alexey Romanenko <aromanenko.dev@gmail.com <ma...@gmail.com>> wrote:
> Hello,
>
> In Java SDK, from time to time we face with an issue with an access to classes or methods, that are explicitly supposed to be as a part of public user’s API, but, by mistake, are made private or package-private.
>
> For example this issue [1], where KinesisClientThrottledException is package-private but it can be an argument in a public method of RateLimitPolicy interface if user wishes to implement its own.
>
> // public interface
> public interface RateLimitPolicy {
> default void onThrottle(KinesisClientThrottledException e)
> }
>
> // package-private interface in the same package
> class KinesisClientThrottledException {
> …
> }
>
> So user won’t be able to implement it’s own RateLimitPolicy with overridden onThrottle() method since KinesisClientThrottledException is package-private
>
> Does anyone know a tool or something like compilation option or Spotless check, that can detect a broken API at compilation time in case if, for example, arguments of public method don’t have enough access privileges for that? It would be very helpful to prevent such errors.
>
>
> [1] https://issues.apache.org/jira/browse/BEAM-10816 <https://issues.apache.org/jira/browse/BEAM-10816>
Re: Check for enough access to classes/methods of public API
Posted by Luke Cwik <lc...@google.com>.
I only know of tooling that can be used to make sure that the existing API
doesn't change.
Also there isn't an explicit "friend" concept in Java but people do
sometimes orchestrate public classes with methods that restrict who can use
them[1] but I don't think this is a case of that.
1:
https://stackoverflow.com/questions/14226228/implementation-of-friend-concept-in-java
On Fri, Sep 18, 2020 at 8:21 AM Alexey Romanenko <ar...@gmail.com>
wrote:
> Hello,
>
> In Java SDK, from time to time we face with an issue with an access to
> classes or methods, that are explicitly supposed to be as a part of public
> user’s API, but, by mistake, are made private or package-private.
>
> For example this issue [1], where KinesisClientThrottledException is
> package-private but it can be an argument in a public method of
> RateLimitPolicy interface if user wishes to implement its own.
>
> // public interface
> public interface RateLimitPolicy {
> default void onThrottle(KinesisClientThrottledException e)
> }
>
> // package-private interface in the same package
> class KinesisClientThrottledException {
> …
> }
>
> So user won’t be able to implement it’s own RateLimitPolicy with
> overridden onThrottle() method since KinesisClientThrottledException is
> package-private
>
> Does anyone know a tool or something like compilation option or Spotless
> check, that can detect a broken API at compilation time in case if, for
> example, arguments of public method don’t have enough access privileges for
> that? It would be very helpful to prevent such errors.
>
>
> [1] https://issues.apache.org/jira/browse/BEAM-10816