[
https://issues.apache.org/jira/browse/GROOVY-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14972508#comment-14972508
]
ASF GitHub Bot commented on GROOVY-7644:
----------------------------------------
Github user asfgit closed the pull request at:
https://github.com/apache/incubator-groovy/pull/157
> ExternalizeMethods generates incorrect bytecode for statically compiled
> nested classes
> --------------------------------------------------------------------------------------
>
> Key: GROOVY-7644
> URL: https://issues.apache.org/jira/browse/GROOVY-7644
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
> Affects Versions: 2.4.5
> Environment: OSX 10.10, JDK 1.8
> Reporter: Shil Sinha
> Assignee: Cédric Champeau
>
> When @AutoExternalize and @CompileStatic are both applied to a nested
> (static) class, the generated writeExternal and readExternal methods call
> writeObject/readObject on 'this' rather than on their arguments. This results
> in IncompatibleClassChange errors at runtime. Example:
> {code}
> class Person {
> @groovy.transform.ToString(includePackage=false)
> @groovy.transform.AutoExternalize
> @groovy.transform.CompileStatic
> static class AddressCS {
> String street, town
> }
> }
> {code}
> The bytecode generated for the Person.AddressCS.writeExternal method is:
> {code}
> public writeExternal(Ljava/io/ObjectOutput;)V throws java/io/IOException
> L0
> ALOAD 0
> ALOAD 0
> GETFIELD Person$AddressCS.street : Ljava/lang/String;
> INVOKEINTERFACE java/io/ObjectOutput.writeObject (Ljava/lang/Object;)V
> ACONST_NULL
> POP
> ALOAD 0
> ALOAD 0
> GETFIELD Person$AddressCS.town : Ljava/lang/String;
> INVOKEINTERFACE java/io/ObjectOutput.writeObject (Ljava/lang/Object;)V
> ACONST_NULL
> POP
> L1
> RETURN
> LOCALVARIABLE this LPerson$AddressCS; L0 L1 0
> LOCALVARIABLE out Ljava/io/ObjectOutput; L0 L1 1
> MAXSTACK = 2
> MAXLOCALS = 2
> {code}
> This seems to occur because the writeObject method call expressions within
> writeExternal have implicitThis set to true.
> The problem is essentially the same for generated readExternal methods.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
