Details

    • Type: Task Task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.0
    • Component/s: groovy-runtime
    • Labels:
      None

      Description

      this task collects all the issues related to a privae field being visible, when it should not be visible

        Issue Links

          Activity

          Hide
          George Politis added a comment -

          I can't unfortunately because I was never able to access private fields at runtime in my non-scientific experiments. I just assumed that it was possible based on the comments in this and other related bugs.

          Show
          George Politis added a comment - I can't unfortunately because I was never able to access private fields at runtime in my non-scientific experiments. I just assumed that it was possible based on the comments in this and other related bugs.
          Hide
          Jochen Theodorou added a comment -

          can you show me a short code snippet in which Groovy fails at runtime to access a private field in a way that worked before?

          Show
          Jochen Theodorou added a comment - can you show me a short code snippet in which Groovy fails at runtime to access a private field in a way that worked before?
          Hide
          George Politis added a comment -

          It seems that private field access has been "fixed" in recent versions of Groovy; Groovy no longer allows access to private fields. But this fix cripples peoples code, including mine.

          You can't disagree with Michael Kebe, if one wants to access a private field or method, and the language doesn't allow it, then reflection is the way to go and it's going to be ugly.

          So, as malbery has already suggested, why not have a private field access operator that allows access to private fields, much like the direct field access operator, only more powerful.

          If we let the percent symbol "%" to be that special operator, then it could be used like this:

          println obj.%privateField
          

          This could be a contribution from the community, as long as the development team agrees with the approach.

          Show
          George Politis added a comment - It seems that private field access has been "fixed" in recent versions of Groovy; Groovy no longer allows access to private fields. But this fix cripples peoples code, including mine. You can't disagree with Michael Kebe , if one wants to access a private field or method, and the language doesn't allow it, then reflection is the way to go and it's going to be ugly. So, as malbery has already suggested, why not have a private field access operator that allows access to private fields, much like the direct field access operator, only more powerful. If we let the percent symbol "%" to be that special operator, then it could be used like this: println obj.%privateField This could be a contribution from the community, as long as the development team agrees with the approach.
          Hide
          Marcus Olk added a comment -

          I don't know whether it makes any sense to add another vote, but I just ran into the following issue:

          public class JavaClass {
              public static final A B = new B();
          
              public static abstract class A {  }
          
              private static class B extends A {
                  private B() {}
              }
          }
          

          The public field JavaClass.B is simply not accessible for Groovy code: JavaClass.B gives you the private inner class B extending A.

          Sure, this is bad design having a field with the same name as an inner class, but it just happend to me, that I had to create a Java class as a proxy for my Groovy code because a Java library used this (anti-) pattern.

          Sorry, but that simply sucks, doesn't it?

          Show
          Marcus Olk added a comment - I don't know whether it makes any sense to add another vote, but I just ran into the following issue: public class JavaClass { public static final A B = new B(); public static abstract class A { } private static class B extends A { private B() {} } } The public field JavaClass.B is simply not accessible for Groovy code: JavaClass.B gives you the private inner class B extending A. Sure, this is bad design having a field with the same name as an inner class, but it just happend to me, that I had to create a Java class as a proxy for my Groovy code because a Java library used this (anti-) pattern. Sorry, but that simply sucks, doesn't it?
          Sam Gleske made changes -
          Link This issue duplicates GROOVY-1875 [ GROOVY-1875 ]
          Mark Thomas made changes -
          Workflow jira [ 12967486 ] Default workflow, editable Closed status [ 12975219 ]
          Mark Thomas made changes -
          Project Import Mon Apr 06 02:11:23 UTC 2015 [ 1428286283443 ]
          Mark Thomas made changes -
          Workflow jira [ 12732020 ] Default workflow, editable Closed status [ 12743852 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 13:32:57 UTC 2015 [ 1428240777691 ]
          Jochen Theodorou made changes -
          Component/s groovy-runtime [ 16250 ]
          Hide
          Antoine added a comment -

          Private is definitely something missing. Sometimes I really to protect some field or method. Today, I encountered a piece of code that was calling a private method of a another class. It went unnoticed during years, until someone started working on it again. Luckily, he saw this error before changing anything.

          My point of view is that event tests should not access private members. But this is only me. A good alternative would be to have a special operator to indicate that you want to access a member without applying the rights. That would at the same time preserve this "feature" for people who need it while making it clear to everyone that the code is doing something special.

          I'd rather spend time one my code finding all the places where an illegal access to private members is done than keep this bug that allows such an dangerous behaviour.

          Show
          Antoine added a comment - Private is definitely something missing. Sometimes I really to protect some field or method. Today, I encountered a piece of code that was calling a private method of a another class. It went unnoticed during years, until someone started working on it again. Luckily, he saw this error before changing anything. My point of view is that event tests should not access private members. But this is only me. A good alternative would be to have a special operator to indicate that you want to access a member without applying the rights. That would at the same time preserve this "feature" for people who need it while making it clear to everyone that the code is doing something special. I'd rather spend time one my code finding all the places where an illegal access to private members is done than keep this bug that allows such an dangerous behaviour.
          Hide
          Serg Lifinsky added a comment -

          If class already have private method which work with private property, do not generate default getter/setter for this private property. Hot fix

          Show
          Serg Lifinsky added a comment - If class already have private method which work with private property, do not generate default getter/setter for this private property. Hot fix
          Hide
          Serg Lifinsky added a comment -

          Using closure as wrap method in example and control call to private method. Only in wrapers for protected and public methods we set caller as current class, and in wrapper for private method validate that caller is current class

          Show
          Serg Lifinsky added a comment - Using closure as wrap method in example and control call to private method. Only in wrapers for protected and public methods we set caller as current class, and in wrapper for private method validate that caller is current class
          Hide
          Paul King added a comment -

          @Serg: your example is nice but how is it related to the issue in Groovy.

          Show
          Paul King added a comment - @Serg: your example is nice but how is it related to the issue in Groovy.
          Serg Lifinsky made changes -
          Attachment privateInJsUseWrapMethodExample.js [ 62665 ]
          Serg Lifinsky made changes -
          Attachment privateInJsUseWrapMethodExample.js [ 62665 ]
          Serg Lifinsky made changes -
          Attachment privateInJsUseWrapMethodExample.js [ 62664 ]
          Hide
          Serg Lifinsky added a comment -

          Example hoto implement private methods and properties in javasxript using wrap method

          Show
          Serg Lifinsky added a comment - Example hoto implement private methods and properties in javasxript using wrap method
          Hide
          donal zang added a comment -

          I might be wrong but I thought @ was for accessing (from within a class) a private field 'foo' when the class also has a public property named 'foo', i.e. it provides a way to disambiguate between a private field and public property of the same name.

          I disagree with the statement from Neal Ford's book. While this bug is useful if you only want to use Groovy to test or script Java apps, if you want to build robust production apps in Groovy, this bug makes it impossible to protect a class' invariants.

          Show
          donal zang added a comment - I might be wrong but I thought @ was for accessing (from within a class) a private field 'foo' when the class also has a public property named 'foo', i.e. it provides a way to disambiguate between a private field and public property of the same name. I disagree with the statement from Neal Ford's book. While this bug is useful if you only want to use Groovy to test or script Java apps, if you want to build robust production apps in Groovy, this bug makes it impossible to protect a class' invariants.
          Guillaume Delcroix made changes -
          Link This issue relates to GROOVY-2433 [ GROOVY-2433 ]
          Guillaume Delcroix made changes -
          Link This issue is depended upon by GROOVY-3073 [ GROOVY-3073 ]
          Hide
          malbery added a comment -

          Maybe there is a way to give the testing community an option to allow the access of private methods/fields in testcases?

          It'd be easy enough to provide a declarative-style way of suppressing access checks while executing a closure.

          Personally, I think that the @ convention for bypassing access protection is in line with other features Groovy offers such as redefining the methods of other classes.

          Show
          malbery added a comment - Maybe there is a way to give the testing community an option to allow the access of private methods/fields in testcases? It'd be easy enough to provide a declarative-style way of suppressing access checks while executing a closure. Personally, I think that the @ convention for bypassing access protection is in line with other features Groovy offers such as redefining the methods of other classes.
          Hide
          Michael Kebe added a comment -

          I just read Neal Ford's book "The Productive Programmer". And in chapter 12 "Meta-Programming" he just picked this bug to show testing a private method of Java with Groovy. Here is a quote:

          Technically, this is a bug in Groovy (that has been there since day one), but it's so insanely useful, no one has bothered to fix it. And I hope they never do. In any language with strong reflection capabilities, the private keyword is not much more than documentation anyway: I can always use reflection to get to it if the need arises.

          Maybe there is a way to give the testing community an option to allow the access of private methods/fields in testcases?

          Show
          Michael Kebe added a comment - I just read Neal Ford's book "The Productive Programmer". And in chapter 12 "Meta-Programming" he just picked this bug to show testing a private method of Java with Groovy. Here is a quote: Technically, this is a bug in Groovy (that has been there since day one), but it's so insanely useful, no one has bothered to fix it. And I hope they never do. In any language with strong reflection capabilities, the private keyword is not much more than documentation anyway: I can always use reflection to get to it if the need arises. Maybe there is a way to give the testing community an option to allow the access of private methods/fields in testcases?
          Jochen Theodorou made changes -
          Link This issue is related to GROOVY-3142 [ GROOVY-3142 ]
          Jochen Theodorou made changes -
          Field Original Value New Value
          Link This issue is depended upon by GROOVY-2503 [ GROOVY-2503 ]
          Jochen Theodorou created issue -

            People

            • Assignee:
              Unassigned
              Reporter:
              Jochen Theodorou
            • Votes:
              25 Vote for this issue
              Watchers:
              31 Start watching this issue

              Dates

              • Created:
                Updated:

                Development