[
https://issues.apache.org/jira/browse/GROOVY-12557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18134513#comment-18134513
]
ASF GitHub Bot commented on GROOVY-12557:
-----------------------------------------
jdaugherty commented on PR #3085:
URL: https://github.com/apache/groovy/pull/3085#issuecomment-6511288732
Confirmed: a cast site never selects `asType` through the metaclass, before
or after this change. The `CastSelector` chain is `asBoolean` (through the
metaclass, still guarded), then the null, instance-of, collection and SAM
checks, then `DefaultTypeTransformation.castToType`, which is decided by the
value's class; classic call sites reach the same method via
`ScriptBytecodeAdapter.castToType`. So a custom `asType` was never honoured by
`Target t = value` or `(Target) value`, with or without indy.
The `as` operator is a different site: `InvokeDynamicWriter.coerce` emits an
ordinary indy method call named `asType`, linked by `MethodSelector`, whose
`guardsReceiverMetaClass()` is unchanged. An ExpandoMetaClass, per-instance or
category `asType` is selected and guarded there exactly as before.
I checked with a script against master before the change (5b077f9dcf) and
with it (1c5c941f4d); the output is identical. `value as Target` honours a
class-level EMC `asType`, two per-instance `asType` closures alternating
through the same site (it relinks on the receiver metaclass guard), and a
category `asType` inside `use`, then falls back to the EMC one after the
category exits. `Target t = value` and `(Target) value` throw
`GroovyCastException` in every case on both builds. With
`-Dgroovy.indy.logging=true` the `asType` site logs "added meta class equality
check" and the cast site logs only the class switch point and same-class
argument guards. The 6.0.x and 5.1.x `CastSelector`s have the same chain ending
in `DTT_CAST_TO_TYPE`, so this holds for the backports.
Noted on GROOVY-12557 as well.
> Indy: casting a GroovyObject calls getMetaClass() on the value being cast
> -------------------------------------------------------------------------
>
> Key: GROOVY-12557
> URL: https://issues.apache.org/jira/browse/GROOVY-12557
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.33, 5.1.3, 6.0.0
> Reporter: James Daugherty
> Priority: Major
>
> With invokedynamic, a cast of a {{GroovyObject}} that already has the target
> type, such as {{Widget widget = value}}, calls {{value.getMetaClass()}}: once
> to build the call site's guard and again on each call through it. With
> classic call sites the same cast calls nothing on the value.
> That is observable whenever {{getMetaClass()}} is not a plain field read. A
> Spring class-based (CGLIB) proxy of a Groovy class forwards every public
> method, {{getMetaClass()}} included, to its target. For a step-, job-,
> request- or session-scoped bean the target exists only while the scope is
> active, so merely assigning the proxy to a typed variable outside the scope
> fails:
> {noformat}
> org.springframework.beans.factory.support.ScopeNotActiveException: Error
> creating bean with name 'scopedTarget.widget': Scope 'step' is not active for
> the current thread
> at
> org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:35)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:698)
> at Widget$$SpringCGLIB$$0.getMetaClass
> at org.codehaus.groovy.vmplugin.v8.Selector$MethodSelector.setGuards
> at org.codehaus.groovy.vmplugin.v8.Selector$CastSelector.castAndSetGuards
> at org.codehaus.groovy.vmplugin.v8.Selector$CastSelector.setCallSiteTarget
> at org.codehaus.groovy.vmplugin.v8.IndyInterface.fallback
> {noformat}
> A Grails application moving from classic call sites to invokedynamic (the
> Grails 9 default) meets this in code that handles scoped proxies dynamically.
> *Reproducer:*
> https://github.com/jdaugherty/groovy-indy-cast-getmetaclass-reproducer
> ({{./run.sh 4.0.33 5.1.3 6.0.0}}). With indy the cast {{Watched typed =
> value}} makes 2 {{getMetaClass()}} calls on the value and fails when
> {{getMetaClass()}} throws; with classic call sites it makes none. Reproduced
> on 4.0.33, 5.1.3 and 6.0.0.
> *Cause:* {{Selector.CastSelector.castAndSetGuards()}} reuses
> {{MethodSelector.setGuards(args[0])}}, which calls {{getMetaClass()}} on a
> {{GroovyObject}} receiver to bind a {{SAME_MC}} guard. Only a cast to boolean
> selects a method ({{asBoolean}}) through the metaclass; every other cast is
> decided by the class of the value, which the argument guards and the class
> SwitchPoint already cover.
> *Proposed fix:* keep the receiver metaclass guard for the {{asBoolean}} path
> only, so a cast decided by the value's class never calls into the value, as
> with classic call sites. A patch with tests follows as a pull request against
> master, with backports for the 6.0.x and 5.1.x lines.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
