This is due to the ConscryptAlpnSslEngine class which depends on the optional conscrypt lib, and graal got better at finding optional libs. I can remove that option and force the JDK engine, but then users lose that choice of using that optional lib.
Is there any option to keep on allowing that optional lib to exist with graal, @Sanne @dmlloyd @stuartwdouglas ?
Generally speaking on Graal allowing optional dependency require to disable strict mode; We really prefer having all extensions support the stricter mode as it provide with far better validation and error messages - and also this flag is a global flag so it would make chasing other problems much harder.
Typically "optional libs" would need a separate extension; you could try using a substitution which removes the code depending on the optional lib with a conditional expression based on the dependent lib being available.
When doing so we need to make sure the "dead code" produces a good warning if the configuration expects it to be used.
Yeah, I don't want to enable --incomplete-classpath but I wonder if I can write a substitution that depends on a predicate that would check if the optional lib is there or not.
Ah, like this:
@TargetClass(value = InfinispanClientProducer.class, onlyWith = Selector.class)
final class SubstituteInfinispanClientProducer {
@Substitute
private void injectProtoMarshallers(Object marshallerInstance) {
// Don't even attempt proto stream updates
}
}
final class Selector implements BooleanSupplier {
@Override
public boolean getAsBoolean() {
try {
Class.forName(InfinispanClientProducer.PROTOBUF_MARSHALLER_CLASS_NAME);
return false;
} catch (ClassNotFoundException | NoClassDefFoundError e) {
// If the classes aren't found we have to remove the places that reference it
return true;
}
}
}
In this case I don't think we want to ever support the specific library, as our minimum will change to Java 11 as soon as it is possible to do so; Java 11's JSSE includes ALPN support.
Well, sounds fine, because if I try to be smart about it, I get this shit:
Caused by: java.lang.NullPointerException
at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.findOriginalField(AnnotationSubstitutionProcessor.java:650)
at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.handleFieldInAliasClass(AnnotationSubstitutionProcessor.java:386)
at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.handleAliasClass(AnnotationSubstitutionProcessor.java:303)
at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.handleClass(AnnotationSubstitutionProcessor.java:273)
at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.init(AnnotationSubstitutionProcessor.java:229)
at com.oracle.svm.hosted.NativeImageGenerator.setupDeclarativeSubstitutionProcessor(NativeImageGenerator.java:817)
at com.oracle.svm.hosted.NativeImageGenerator.setupNativeImage(NativeImageGenerator.java:786)
at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:490)
at com.oracle.svm.hosted.NativeImageGenerator.lambda$run$0(NativeImageGenerator.java:410)
at java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1386)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
So…
I don't think it's worth wasting time on it for now. Let's delete the class with a substitution. We can revisit that later when we have more time or if a user complains.
Yes, I'll do that.
Done.
so, I'm still not understanding gh issues. Should this be closed manually now?
This is actually causing #4248
Most helpful comment
Ah, like this: