groovy
  1. groovy
  2. GROOVY-3831

Expecting to find object/array on stack

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.5, 1.6, 1.6.4, 1.6.5
    • Fix Version/s: 1.6.6, 1.7-rc-1
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      1

      Description

      Repro:
      Compile and run the following:

      class Test
      {
              String string
              URI[] uris
      
              public Test(String string, URI[] uris)
              {
                      this.string = string
                      this.uris = uris
              }
      
              public Test(String string, List uris)
              {
                      this(string, uris.collect { new URI(it) } as URI[])
              }
      
              public static void main(String[] args)
              {
                      def test = new Test('hello', ["world"])
                      println test.string
                      println test.strings
              }
      }

      Observed Result:

      $ groovyc Test.groovy
      $ groovy Test
      Caught: java.lang.VerifyError: (class: Test, method: <init> signature: (Ljava/lang/String;Ljava/util/List;)V) Expecting to find object/array on stack

      Expected Result:

      hello
      [world]
      

        Activity

        Hide
        Suk-Hyun Cho added a comment -

        Sorry, it should be "println test.uris" at the end of the main method, and the expected result is

        hello
        {world}
        

        A work-around is to refactor out

        uris.collect { new URI(it) } as URI[]

        as a method and call it:

        this(string, toUriArray(uris))
        Show
        Suk-Hyun Cho added a comment - Sorry, it should be "println test.uris" at the end of the main method, and the expected result is hello {world} A work-around is to refactor out uris.collect { new URI(it) } as URI[] as a method and call it: this (string, toUriArray(uris))
        Hide
        Roshan Dawrani added a comment -

        Trimmed and trimmed and here is the bare minimum snippet that is reproducing the issue:

        class Test
        {
            public Test(cl) {}
        
            public Test()
            {
                this({1})
            }
        }
        
        new Test()
        

        Haven't gone beyond shortening it yet, but issue may be related to "this" reference not being ready yet in ."this(

        {1}

        )" - just a guess at this point though.

        Show
        Roshan Dawrani added a comment - Trimmed and trimmed and here is the bare minimum snippet that is reproducing the issue: class Test { public Test(cl) {} public Test() { this ({1}) } } new Test() Haven't gone beyond shortening it yet, but issue may be related to "this" reference not being ready yet in ."this( {1} )" - just a guess at this point though.
        Hide
        Roshan Dawrani added a comment -

        I am wondering if the fix here may be to not allow in-line closure definition while invoking a constructor from another constructor.

        Groovy does not allow this(this), super(this), etc in constructorsGROOVY-3128 and doing this (

        {1}) or super ({1}

        ) is internally the same thing because of this references being passed to the closure constructor.

        Show
        Roshan Dawrani added a comment - I am wondering if the fix here may be to not allow in-line closure definition while invoking a constructor from another constructor. Groovy does not allow this(this), super(this), etc in constructors GROOVY-3128 and doing this ( {1}) or super ({1} ) is internally the same thing because of this references being passed to the closure constructor.
        Hide
        blackdrag blackdrag added a comment -

        in "this(

        {1}

        )" the Closure needs an owner. The rationale here is to use the class instead of this, because all that is inside this() is to be ahndled as a static context and closures are allowed in a static context. So the code should have worked.

        Show
        blackdrag blackdrag added a comment - in "this( {1} )" the Closure needs an owner. The rationale here is to use the class instead of this, because all that is inside this() is to be ahndled as a static context and closures are allowed in a static context. So the code should have worked.
        Hide
        Roshan Dawrani added a comment -

        Yes, I had noticed for non-closure usage within this() that it uses the static context. Thanks for extending that understanding to closure's owner.

        Currently the closure class instance is being created with "this" as the owner and not the class. I will look around that and see if I am able to change the owner to class object to see if that helps with this error.

        Once it goes inside class loading and verification by the JVM, it becomes difficult (for me) to pinpoint the exact spot where the issue is coming from. Wish I could have a peek inside class loading/verifier too.

        Show
        Roshan Dawrani added a comment - Yes, I had noticed for non-closure usage within this() that it uses the static context. Thanks for extending that understanding to closure's owner. Currently the closure class instance is being created with "this" as the owner and not the class. I will look around that and see if I am able to change the owner to class object to see if that helps with this error. Once it goes inside class loading and verification by the JVM, it becomes difficult (for me) to pinpoint the exact spot where the issue is coming from. Wish I could have a peek inside class loading/verifier too.
        Hide
        Roshan Dawrani added a comment -

        Fixed by extending the static context to closures defined in special calls within constructors.

        Thanks for the hint, Jochen.

        Show
        Roshan Dawrani added a comment - Fixed by extending the static context to closures defined in special calls within constructors. Thanks for the hint, Jochen.

          People

          • Assignee:
            Roshan Dawrani
            Reporter:
            Suk-Hyun Cho
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: