Sanne commented on issue #4148: URL: https://github.com/apache/camel-quarkus/issues/4148#issuecomment-1270143356
thanks for the explanation - tricky. Yes I can see how my previous optimisation would break this - but there's also the case for `useTccl` being set to `false`: what if rather than invoking `io.quarkus.gizmo.BytecodeCreatorImpl#loadClassFromTCCL(String)` one was using `loadClass(String)` ? Especially when loading JDK types I would expect both invocations to be valid, and yet only `loadClassFromTCCL` would have used reflection. Plus I'd expect that when registering for Reflection/Serialization, it shouldn't matter which classloader is being used. So rather than reverting I think gizmo should be fixed to handle private types correctly whatever the choice of classloader. -- 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: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
