gnodet commented on code in PR #950:
URL: https://github.com/apache/maven/pull/950#discussion_r1387639811
##########
maven-core/pom.xml:
##########
@@ -144,6 +144,12 @@ under the License.
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</dependency>
+ <dependency>
Review Comment:
> the new interceptor is a new proxy basically high level i'd like to ensure
we don't depend on java version as much as we can cause it starts to hurt all
the ecosystem and at maven there is no reason we do depend on asm so no new
usage should be added and ultimately we should drop them all from maven 4.0.0
IMHO
Due to the way scoping works in guice, the interception is built by wrapping
the injected bean, not by wrapping the injection point. The key method is the
following:
https://google.github.io/guice/api-docs/4.2/javadoc/index.html?com/google/inject/Scope.html
```
public <T> Provider<T> scope(Key<T> key, Provider<T> unscoped);
```
So we do wrap the `Provider<T>`, but `T` is the actual bean class, because
that happens irrespective of where the bean will be injected (the injection
point).
So even if the bean is injected into a field which refers to an interface
the bean implementation provider will be _scope_.
Basically, we can't use JDK proxies here.
I do understand your concerns about avoiding the use of ASM. We need to
investigate, but it's actually used by sisu to discover beans. That sounds
duplicate work as we usually generate the META-INF files so that discovery
should not have to scan all classes.
That said, problems happen only when the following combination happens:
* the JDK in use is not supported by the ASM version embedded
* we scan a class file which targets a JDK newer that the one supported by
ASM
That's why I've extracted ASM out of guice / sisu, so that we (or even the
user) can easily upgrade the asm version in the distribution and get rid of
those problems.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
