[
https://issues.apache.org/jira/browse/GROOVY-12553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136214#comment-18136214
]
ASF GitHub Bot commented on GROOVY-12553:
-----------------------------------------
paulk-asert commented on PR #3082:
URL: https://github.com/apache/groovy/pull/3082#issuecomment-6564277121
@jdaugherty thanks, this looks good to me, and your reasoning on the type
check makes sense: the class's own logger field is always added before
`addGuard` runs, and re-scoping binds the reference to it afterwards.
Could you add a test that pins that reasoning? The current test has `@Log`
on both classes, so the field types match. A superclass with a private `log`
field of another type covers the "whatever its type" argument and the
mixed-strategy case together, without needing a second logging library:
```groovy
@Test
void testLogGuardWithNonLoggerPrivateFieldInSuperclass() {
def texts = compileBothWays([
'p/Base.groovy': 'package p; abstract class Base { private static
final String log = "not a logger" }',
'p/Sub.groovy': 'package p; @groovy.util.logging.Log class Sub
extends Base { void run(Object o) { log.info("value: " + o) } }'
], ['p/Sub.groovy'])
def (together, separate) = texts['p.Sub']
assert together == separate
assert separate.contains('IFEQ')
}
```
If the guard ever bound to the superclass's field, this would fail, since
`String` has no `isLoggable`.
I also checked a superclass `log` *property* (`def log`, `static log`,
`String log`): with your change the guard is added in both compilations and the
call uses `Sub.log`, since the reference binds to the property's private
backing field. Not needed as a test, but it could go in the same parameterized
test if you like.
Interestingly, on master the guard is also dropped when the superclass
declares its own `log` and both classes are compiled *together*, so the fix is
a bit wider than the incremental-build case in the description.
A minor, non-blocking point: yes please to widening the javadoc on
`refersToLogField` as you offered. It currently says the superclass is "read
from bytecode" and its field is "not accessible here", but the same binding
happens for a private `log` declared in a superclass compiled in the same run.
> @Log: a log call in a subclass is not guarded when the superclass with its
> own @Log is already compiled
> -------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12553
> URL: https://issues.apache.org/jira/browse/GROOVY-12553
> Project: Groovy
> Issue Type: Bug
> Components: AST Transforms
> Affects Versions: 4.0.33, 5.1.3
> Reporter: James Daugherty
> Priority: Major
>
> {{@Log}}, {{@Slf4j}} and the other logging annotations wrap a log call whose
> arguments are not trivial in a level check, so {{log.fine('value: ' +
> value)}} compiles as {{if (log.isLoggable(Level.FINE)) log.fine('value: ' +
> value)}}. When the class extends another class with a logging annotation, the
> guard is only added while the superclass is compiled together with it. When
> the superclass is already compiled, the call is left unguarded, so its
> arguments are evaluated whatever the level, and the same source compiles to a
> different class file depending on what else is compiled.
> {code:groovy}
> @groovy.util.logging.Log
> abstract class Base {
> void start() { log.info('starting ' + getClass().simpleName) }
> }
> @groovy.util.logging.Log
> class Sub extends Base {
> void run(Object value) {
> log.fine('value: ' + value) // not guarded when Base is already
> compiled
> }
> }
> {code}
> Reproduced with 4.0.33, 5.1.3 and master. A reproducer with a groovyc script
> and an incremental Gradle build:
> https://github.com/jdaugherty/groovy-log-guard-precompiled-superclass
> *Cause*
> {{LogASTTransformation}} adds the guard only when the {{log}} variable of the
> call is still a {{DynamicVariable}}, unbound because the log field is added
> by the transformation itself. With the superclass read from bytecode, the
> reference has already been bound to the superclass's own private {{log}}
> field, so the call is left unguarded. The transformation already accepts such
> a private field when it adds the subclass's log field.
> *Proposed fix*
> Treat a reference bound to a private field of another class the same as an
> unbound one.
> Found while making incremental builds of a Grails application produce the
> same classes as a full build; see also GROOVY-12550 and GROOVY-12544.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
