Use Class.forName to prevent IllegalAccessError #5385
Conversation
We need to do this as the class may be package private. Fixes quarkusio#5326
| if (Kind.CLASS.equals(type.kind())) { | ||
| return creator.loadClass(type.asClassType().name().toString()); | ||
| String className = type.asClassType().name().toString(); | ||
| return doLoadClass(creator, className); |
There was a problem hiding this comment.
Hm, we use BytecodeCreator.loadClass() in many places. Why do we actually get an IAE when trying to use Hello.class in the MorningGreeting bean? I mean it works with javac so why is it a problem for gizmo?
There was a problem hiding this comment.
The interface is not actually accessible from the bean, so LDC does not work. It's a bit of a corner case but it's just how the JVM works
There was a problem hiding this comment.
Ok, I see. I've verified this again and it's indeed not possible ;-). So the only thing I'm not sure about is that we do add the TCCL and Class.forName() for every bean type. Which means that the constructor will grow for a bean with large number of bean types.
Also I wonder if should verify all those places where we use BytecodeCreator.loadClass()...
There was a problem hiding this comment.
The recorders already use the TCCL because this problem popped up a while ago. In general though this code should not be slower (even thought it is a few more bytecodes), and the number of types should never be large enough that the method size limit becomes a problem.
There was a problem hiding this comment.
should never be large enough that the method size limit becomes a problem.
We do a lot more stuff in the constructor but you're right that we should not hit the limit for common use cases.
I'm going to approve this PR but create a follow-up issue to verify all other occurences of BytecodeCreator.loadClass() in arc.
4 participants
Fixes #5326
Thanks @jaikiran for your excellent analysis and test case