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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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>
