Message11943

@Jim: That isn't (I think) what I'm getting at. I was thinking of private classes implemented in Java. (I suppose it might happen via Python.)

When a class is detected to be private (or module-inaccessible), PyJavaType.init calls handleSuperMethodArgCollisions to expose equivalent methods from ancestors and interfaces. *And then it returns.* We do not execute the subsequent parts of init, such as those that give special treatment to classes implementing collection interfaces or Comparable.

In cases I've come across in testing, this is ok, because the private class extends a public class (like AbstractList) that has already had this treatment, and the special methods will be found along the MRO. But it isn't guaranteed there there be such an ancestor, if I create a class that implements Comparable directly, say.

My preferred answer to this would be that we don't have exceptional processing for private classes up front, but that the main-line of init should take accessibility into account in its fine-grain logic. (Simply removing the return doesn't work.)

That wouldn't prevent access to private methods, or private but exported classes, if the option is set to allow it. Accessing private objects is a sign something is wrong IMO, but it may be something outside your control for which that is the work-around of last resort.