[
https://issues.apache.org/jira/browse/GROOVY-10894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Smith updated GROOVY-10894:
---------------------------------------
Description:
The latest nightly (included with GRECLIPSE 4.9.0.v202301012233-e2206) has
introduced a regression that appears to be the same bug as GROOVY-10553;
JSR-303 annotations applied to a trait property are listed twice in the
bytecode on both the field and the {{$get/$set}} methods, resulting in an
{{AnnotationFormatError}} at runtime. Compiling with groovyc 4.0.7 produces
clean bytecode, and rebuilding in Eclipse reintroduces the duplicate.
Sample:
{code}
trait LocationRelated {
@NotNull @Valid Location location
}
{code}
In {{FieldHelper}} disassembly:
{code}
public abstract com.example.Location
com_example_LocationRelated__location$set(com.example.Location);
descriptor: (Lcom/example/Location;)Lcom/example/Location;
flags: (0x0401) ACC_PUBLIC, ACC_ABSTRACT
RuntimeVisibleTypeAnnotations:
0: #11(): METHOD_RETURN
javax.validation.constraints.NotNull
1: #12(): METHOD_RETURN
javax.validation.Valid
2: #11(): METHOD_RETURN
javax.validation.constraints.NotNull
3: #12(): METHOD_RETURN
javax.validation.Valid
4: #11(): METHOD_FORMAL_PARAMETER, param_index=0
javax.validation.constraints.NotNull
5: #12(): METHOD_FORMAL_PARAMETER, param_index=0
javax.validation.Valid
6: #11(): METHOD_FORMAL_PARAMETER, param_index=0
javax.validation.constraints.NotNull
7: #12(): METHOD_FORMAL_PARAMETER, param_index=0
javax.validation.Valid
{code}
(As a side issue, is there a particular reason these methods aren't marked
synthetic? I'm not certain that would prevent the problem's actually surfacing
in this case, but based on my reading of the Hibernate Validator code it might
have. Not sure whether that's a positive or a negative, though.)
was:
The latest nightly (included with GRECLIPSE 4.9.0.v202301012233-e2206) has
introduced a regression that appears to be the same bug as GROOVY-10553;
JSR-303 annotations applied to a trait property are listed twice in the
bytecode on both the field and the {{$get/$set}} methods, resulting in an
{{AnnotationFormatError}} at runtime. Compiling with groovyc 4.0.7 produces
clean bytecode, and rebuilding in Eclipse reintroduces the duplicate.
Sample:
{code}
trait LocationRelated {
@NotNull @Valid Location location
}
{code}
In {{FieldHelper}} disassembly:
{code}
public abstract com.example.Location
com_example_LocationRelated__location$set(com.example.Location);
descriptor: (Lcom/example/Location;)Lcom/example/Location;
flags: (0x0401) ACC_PUBLIC, ACC_ABSTRACT
RuntimeVisibleTypeAnnotations:
0: #11(): METHOD_RETURN
javax.validation.constraints.NotNull
1: #12(): METHOD_RETURN
javax.validation.Valid
2: #11(): METHOD_RETURN
javax.validation.constraints.NotNull
3: #12(): METHOD_RETURN
javax.validation.Valid
4: #11(): METHOD_FORMAL_PARAMETER, param_index=0
javax.validation.constraints.NotNull
5: #12(): METHOD_FORMAL_PARAMETER, param_index=0
javax.validation.Valid
6: #11(): METHOD_FORMAL_PARAMETER, param_index=0
javax.validation.constraints.NotNull
7: #12(): METHOD_FORMAL_PARAMETER, param_index=0
javax.validation.Valid
{code}
> Duplicate annotations on trait FieldHelper
> ------------------------------------------
>
> Key: GROOVY-10894
> URL: https://issues.apache.org/jira/browse/GROOVY-10894
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
> Affects Versions: 4.0.8
> Reporter: Christopher Smith
> Priority: Major
> Labels: regression
>
> The latest nightly (included with GRECLIPSE 4.9.0.v202301012233-e2206) has
> introduced a regression that appears to be the same bug as GROOVY-10553;
> JSR-303 annotations applied to a trait property are listed twice in the
> bytecode on both the field and the {{$get/$set}} methods, resulting in an
> {{AnnotationFormatError}} at runtime. Compiling with groovyc 4.0.7 produces
> clean bytecode, and rebuilding in Eclipse reintroduces the duplicate.
> Sample:
> {code}
> trait LocationRelated {
> @NotNull @Valid Location location
> }
> {code}
> In {{FieldHelper}} disassembly:
> {code}
> public abstract com.example.Location
> com_example_LocationRelated__location$set(com.example.Location);
> descriptor: (Lcom/example/Location;)Lcom/example/Location;
> flags: (0x0401) ACC_PUBLIC, ACC_ABSTRACT
> RuntimeVisibleTypeAnnotations:
> 0: #11(): METHOD_RETURN
> javax.validation.constraints.NotNull
> 1: #12(): METHOD_RETURN
> javax.validation.Valid
> 2: #11(): METHOD_RETURN
> javax.validation.constraints.NotNull
> 3: #12(): METHOD_RETURN
> javax.validation.Valid
> 4: #11(): METHOD_FORMAL_PARAMETER, param_index=0
> javax.validation.constraints.NotNull
> 5: #12(): METHOD_FORMAL_PARAMETER, param_index=0
> javax.validation.Valid
> 6: #11(): METHOD_FORMAL_PARAMETER, param_index=0
> javax.validation.constraints.NotNull
> 7: #12(): METHOD_FORMAL_PARAMETER, param_index=0
> javax.validation.Valid
> {code}
> (As a side issue, is there a particular reason these methods aren't marked
> synthetic? I'm not certain that would prevent the problem's actually
> surfacing in this case, but based on my reading of the Hibernate Validator
> code it might have. Not sure whether that's a positive or a negative, though.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
