quarkus: field injection of package-private fields for subclasses in dependent modules fails with IllegalAccessError
Describe the bug
When a project extends classes in another jar, field injection on those subclasses with package-private or protected accessibility is failing with IllegalAccessError
.
Expected behavior Should be able to extend subclasses in a dependent JAR and have field injection of base classes work normally.
Actual behavior
Caused by: java.lang.IllegalAccessError: tried to access field org.acme.quickstart.MyBaseService.configStoreEndpoint from class org.acme.quickstart.MyService_Bean
at org.acme.quickstart.MyService_Bean.create(MyService_Bean.zig:685)
at org.acme.quickstart.MyService_Bean.create(MyService_Bean.zig:579)
at io.quarkus.arc.impl.AbstractSharedContext.createInstanceHandle(AbstractSharedContext.java:80)
at io.quarkus.arc.impl.ComputingCache$CacheFunction.lambda$apply$0(ComputingCache.java:99)
at io.quarkus.arc.impl.LazyValue.get(LazyValue.java:26)
at io.quarkus.arc.impl.ComputingCache.getValue(ComputingCache.java:41)
at io.quarkus.arc.impl.AbstractSharedContext.get(AbstractSharedContext.java:25)
at org.acme.quickstart.MyService_ClientProxy.arc$delegate(MyService_ClientProxy.zig:124)
at org.acme.quickstart.MyService_ClientProxy.getKeyPrefix(MyService_ClientProxy.zig:275)
at org.acme.quickstart.GreetingResource.hello(GreetingResource.java:25)
at org.acme.quickstart.GreetingResource_ClientProxy.hello(GreetingResource_ClientProxy.zig:190)
To Reproduce Steps to reproduce the behavior:
- Build trivial “common” module: https://github.com/jordanglassman/quarkus-cdi-bug-common
- Run quarkus app that depends on “common”: https://github.com/jordanglassman/quarkus-cdi-bug-app
- cause class to be loaded with
curl http://localhost:8080/hello
- observe
Caused by: java.lang.IllegalAccessError: tried to access field...
when class is loaded
Environment (please complete the following information):
- Output of
uname -a
orver
:
$ uname -a
Darwin ip-192-168-1-137.ec2.internal 18.2.0 Darwin Kernel Version 18.2.0: Mon Nov 12 20:24:46 PST 2018; root:xnu-4903.231.4~2/RELEASE_X86_64 x86_64
- Output of
java -version
:
$ java -version
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
- GraalVM version (if different from Java): N/A
- Quarkus version or git rev: 1.2.1Final
Additional context I noticed that the problem does not occur if the “common” module is part of the quarkus app project (ie. a standalone maven module in the quarkus app project).
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 23 (17 by maintainers)
I would be tempted to just say that we don’t support split packages (the same package split between multiple jars).
This is just a bad practice generally, and when you have them loaded by different class loaders it will just cause confusion, in dev and test, even though it would work in production mode.
Thanks for checking @jordanglassman !
I don’t think it’s a CDI-specific problem… Maybe we should test a package-private method access first?