Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-44183

Shared Library child class no such field exception

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • workflow-cps-plugin
    • None
    • Jenkins 2.46.2
      Pipeline: Shared Groovy Libraries 2.8
      Pipeline: API 2.3

      In a shared library, I have a super class with one field and a getter/setter for it.  I then have a child class which extends the super class and does nothing else.  If I instantiate an instance of the child class in the pipeline and then call the setter/getter method from the super class I get a "groovy.lang.MissingFieldException: No such field: field" error.

      If I compile and test this with gradle, it compiles and runs just fine.  Either I missed something in how the pipeline compiler works or it's a bug.  Please let me know if there's another method I should use in this scenario.

       

      Parent Class

      class B implements Serializable {

      def field;

      def getField() {
        return field
      }

      def setField(value) {
        field = value
      }

      }

       

      Child Class

      class A extends B {

      }

       

      Pipeline

      def b = new B()
      def a = new A()

      b.setField('test b')

      // Error occurs when pipeline calls a.setField because it can't find the field in its super class
      a.setField('test a')

      echo b.getField()
      echo a.getField()

          [JENKINS-44183] Shared Library child class no such field exception

          Jesse Glick added a comment -

          Not sure if this is a bug or not. def field looks wrong. To declare a field, you would either state a type (String field) or use @groovy.transform.Field field. What def field—declaring a local variable—does when in the body of a class I have no idea.

          Jesse Glick added a comment - Not sure if this is a bug or not. def field looks wrong. To declare a field, you would either state a type ( String field ) or use @groovy.transform.Field field . What def field —declaring a local variable—does when in the body of a class I have no idea.

          Corey Mead added a comment -

          Groovy doesn't have to be typed, hence the use of "def".  Perhaps pipeline is expecting to interpret it with typed variables?

          Corey Mead added a comment - Groovy doesn't have to be typed, hence the use of "def".  Perhaps pipeline is expecting to interpret it with typed variables?

          Jesse Glick added a comment -

          Hence @Field with no type, or private field with no type. Language reference I am not sure what def field does in this context. Probably a bug somewhere in groovy-cps in any event, just wondering whether the obvious workarounds (defining a real field) help.

          Jesse Glick added a comment - Hence @Field with no type, or private field with no type. Language reference  I am not sure what def field does in this context. Probably a bug somewhere in groovy-cps in any event, just wondering whether the obvious workarounds (defining a real field) help.

          Jesse Glick added a comment -

          Note that according to my reading of this the def variant is not supposed to work even in the absence of subclassing. At least in Groovy 2.2.1 it does seem to, so I am not sure what it means.

          Jesse Glick added a comment - Note that according to my reading of this  the def variant is not supposed to work even in the absence of subclassing. At least in Groovy 2.2.1 it does seem to, so I am not sure what it means.

          Corey Mead added a comment -

          I'm using groovy 2.4.7, and if I run a junit test with native groovy it compiles and passes without any issue.  There are other features that don't seem to be available in pipeline that are available in groovy so it could just be a limitation I'm not aware of.

          For this issue though, I will try giving those properties a declared type and let you know if it still has trouble.  Thanks!

          Corey Mead added a comment - I'm using groovy 2.4.7, and if I run a junit test with native groovy it compiles and passes without any issue.  There are other features that don't seem to be available in pipeline that are available in groovy so it could just be a limitation I'm not aware of. For this issue though, I will try giving those properties a declared type and let you know if it still has trouble.  Thanks!

          Alexander Tolstikov added a comment - - edited

          Funny thing is that you can create 2 similar classes (the only difference is a Class name) from the same base class, and you can inherited properties from one class, but not from another.

          But it works when you define access modifier as said in language specs:

          a mandatory access modifier (publicprotected, or private)

          Alexander Tolstikov added a comment - - edited Funny thing is that you can create 2 similar classes (the only difference is a Class name) from the same base class, and you can inherited properties from one class, but not from another. But it works when you define access modifier as said in language specs: a mandatory  access modifier  ( public ,  protected , or  private )

            Unassigned Unassigned
            cjmead Corey Mead
            Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: