Private methods handled as virtual for inherting classes #36

Activity

1. cowtowncoder commented on Feb 4, 2017

   

   cowtowncoder

   on Feb 4, 2017

   Member

   More actions

   @meszibalu Thank you for reporting this. It may take a while for me to look into this but just adding a note to mention I saw this.

   I am not 100% sure I understand problem from description, but I assume reproduction explains it.
2. cowtowncoder commented on Sep 9, 2017

   

   cowtowncoder

   on Sep 9, 2017

   Member

   More actions

   Hmmh. I don't think I agree here -- I don't see why both private methods should be reported.
   What would be use case for doing that? If you want to see private method from parent class, you should probably resolve that (and/or there should be a way to traverse override hierarchy).

   It is possible I am missing a use case here so would appreciate help.
3. meszibalu commented on Dec 8, 2017

   

   meszibalu

   on Dec 8, 2017

   Author

   More actions

   Because private methods do not override each other. Let me give you another example:

   public class A {
     private void a() {}
     private void x() {}
   }
   public class B extends A {
     private void b() {}
     private void x() {}
   }

   If I resolve B with MemberResolver, then it will return 3 methods. But why 3? B.x does not override A.x, because private methods are not virtual. In my opinion if we return A.a when resolving B, then we should also return A.x, not only B.x.
4. cowtowncoder commented on Dec 8, 2017

   

   cowtowncoder

   on Dec 8, 2017

   Member

   More actions

   But there is no real way to call masked base class variant. Except perhaps reflection does allow that.
   I do see that call dispatching is different from overriding case (which is bit surprising actually) so you are right regarding actual JVM operation.

   So I guess my question is really: what is the use case for this?

   The reason for my hesitation is that up until this point, uniqueness of signatures (name + arguments + return type) is guaranteed, and conceptually adding both private methods would complicate this part.
5. meszibalu commented on Dec 11, 2017

   

   meszibalu

   on Dec 11, 2017

   Author

   More actions

   Yes, you are right, reflection allows that, because they are not virtual. For virtual methods, nobody can call the super method.

   A possible use case for this:
   Let's assume that there some beans and bean inheritance is permitted. There are also some lifecycle events like @PostConstruct or @PreDestroy. In this case, we have to name those methods differently, like initializeParentClass(), initializeChildClass(), etc.

   I understand your concern, it is quite tricky to handle, and there is a workaround for that if we resolv the members of the base class, so this argument is a little bit theoretical :). This issue also exists for private fields. If you have two private fields with the same name in an inheritance hierarchy, MemberResolver will shadow the field of the parent implementation.