[native-image] Error: could not find target method: public static jline.Terminal com.oracle.svm.jline.subst.Target_jline_TerminalFactory.create(java.lang.String)

[neomatrix369]

When trying to build a native image from a jar, I get the below message, I have generated the needed (I hope it is sufficient) config (in META-INF) file needed, using the tracing agent as per @christianwimmer's blog.

Command:

native-image -jar ${JARFILE} --no-fallback -H:+ReportExceptionStackTraces

Output:

Build on Server(pid: 29, port: 43201)*
['':29]    classlist: 185,068.89 ms
['':29]        setup:   1,993.96 ms
Error: could not find target method: public static jline.Terminal com.oracle.svm.jline.subst.Target_jline_TerminalFactory.create(java.lang.String)
com.oracle.svm.core.util.UserError$UserException: could not find target method: public static jline.Terminal com.oracle.svm.jline.subst.Target_jline_TerminalFactory.create(java.lang.String)
	at com.oracle.svm.core.util.UserError.abort(UserError.java:65)
	at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.findOriginalMethod(AnnotationSubstitutionProcessor.java:633)
	at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.handleMethodInAliasClass(AnnotationSubstitutionProcessor.java:326)
	at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.handleAliasClass(AnnotationSubstitutionProcessor.java:298)
	at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.handleClass(AnnotationSubstitutionProcessor.java:274)
	at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.init(AnnotationSubstitutionProcessor.java:230)
	at com.oracle.svm.hosted.NativeImageGenerator.createDeclarativeSubstitutionProcessor(NativeImageGenerator.java:863)
	at com.oracle.svm.hosted.NativeImageGenerator.setupNativeImage(NativeImageGenerator.java:817)
	at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:520)
	at com.oracle.svm.hosted.NativeImageGenerator.lambda$run$0(NativeImageGenerator.java:440)
	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)
Error: Image build request failed with exit status 1

Environment:

Linux 9697aacf62ce 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64 GNU/Linux (Docker container)

java -version
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-b10)
OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)

GraalVM version: graalvm-ce-19.1.1

Is this a known issue? What am I not doing or doing wrong?

[neomatrix369]

Is it correct that either of these are valid:

native-image ${OPTIONS} -jar ${JARFILE} ${IMAGE_NAME} 

or

native-image -jar ${JARFILE} ${IMAGE_NAME} ${OPTIONS} 

I have had both of the above work for me (same for class file?).

As help usage text says:

Usage: native-image [options] class [imagename]
           (to build an image for a class)
   or  native-image [options] -jar jarfile [imagename]
           (to build an image for a jar file)

[olpaw]

Yes, that's correct. Options are even recognized when given after -jar ${JARFILE}. Also: Order is significant. E.g. if a jar file (either on -cp or given as -jar) contains native-image properties you can override them when you pass the option after the -cp/-jar argument that adds that jar.

[olpaw]

What am I not doing or doing wrong?

Does the jar file contain jline? I.e. did you build an uber-jar that contains all your dependencies?

[christianwimmer]

We are shipping Native Image with support (= substitutions) for JLine. The substitutions are activated when JLine is detected on the class path. Unfortunately, JLine changes over time and it seems like you are using a different version than what we are using: 2.14.6

If you can upgrade/downgrade to exactly that version (or a version close enough to that version), the substitution should work.

And it seems like we need to make our JLine support more version-independent so that this problem does not occur again.

[neomatrix369]

Yes, that's correct. Options are even recognized when given after -jar ${JARFILE}. Also: Order is significant. E.g. if a jar file (either on -cp or given as -jar) contains native-image properties you can override them when you pass the option after the -cp/-jar argument that adds that jar.

I have created a PR to add this info to the help usage text, see #1535 - hope this is okay and helps.

[neomatrix369]

We are shipping Native Image with support (= substitutions) for JLine. The substitutions are activated when JLine is detected on the class path. Unfortunately, JLine changes over time and it seems like you are using a different version than what we are using: 2.14.6

If you can upgrade/downgrade to exactly that version (or a version close enough to that version), the substitution should work.

And it seems like we need to make our JLine support more version-independent so that this problem does not occur again.

Thanks for sharing the reason for the issue, I will have to check and see if this is possible, I don't currently have full control over dependency versions. But its good to know jline is sensitive to versions other than 2.14.6.

If you could also make it less dependent on these kinds of things, would be great. Thanks,

[neomatrix369]

After I build the svm via mx build, where can I find native-image binary? I have only managed to find .tar files.

Or is there another process that converts the jar into a native image of native-image itself?

[olpaw]

It will only be created on demand. E.g. after running mx native-image --help in the graal/substratevm folder. And even then you will run the native image driver (what users usually recognize as native-image) not as an image but on JVM (just look into svmbuild/vm/bin/native-image after running mx native-image --help - it's a bash script).
If you want to have a "real" native-image binary you need to build it explicitly. Use:

graal/substratevm> mx native-image -jar svmbuild/vm/jre/lib/graalvm/svm-driver.jar native-image.real -H:Path=svmbuild/vm/bin
[native-image.real:15546]    classlist:   1,879.55 ms
[native-image.real:15546]        (cap):     852.03 ms
[native-image.real:15546]        setup:   2,036.61 ms
[native-image.real:15546]   (typeflow):   6,668.72 ms
[native-image.real:15546]    (objects):   4,468.58 ms
[native-image.real:15546]   (features):     310.15 ms
[native-image.real:15546]     analysis:  11,723.20 ms
[native-image.real:15546]     (clinit):     205.28 ms
[native-image.real:15546]     universe:     685.76 ms
[native-image.real:15546]      (parse):   1,227.38 ms
[native-image.real:15546]     (inline):   1,893.46 ms
[native-image.real:15546]    (compile):  11,697.23 ms
[native-image.real:15546]      compile:  15,563.07 ms
[native-image.real:15546]        image:   1,279.89 ms
[native-image.real:15546]        write:     157.05 ms
[native-image.real:15546]      [total]:  33,493.52 ms
graal/substratevm> file svmbuild/vm/bin/native-image.real 
svmbuild/vm/bin/native-image.real: ELF 64-bit LSB executable, ...

Only GraalVM releases (after installing the native-image component) provide a native-image binary out of the box.

[neomatrix369]

@olpaw Just done it! Thanks!

./svmbuild/vm/bin/native-image --help

GraalVM native-image building tool

This tool can be used to generate an image that contains ahead-of-time compiled Java code.

Usage: native-image [options] class [imagename]
   or  native-image class [imagename] [options]
           (to build an image for a class)
                        or
       native-image [options] -jar jarfile [imagename]
   or  native-image -jar jarfile [imagename] [options]
           (to build an image for a jar file)

[snipped]

[neomatrix369]

We are shipping Native Image with support (= substitutions) for JLine. The substitutions are activated when JLine is detected on the class path. Unfortunately, JLine changes over time and it seems like you are using a different version than what we are using: 2.14.6

If you can upgrade/downgrade to exactly that version (or a version close enough to that version), the substitution should work.

And it seems like we need to make our JLine support more version-independent so that this problem does not occur again.

I did an upgrade and I still get the message, maybe have to wait for your fix.

[neomatrix369]

@christianwimmer we are through with the jline error to land to this error (see attached logs)
build.logs.txt:

Starts off a bit like:

Build on Server(pid: 1447, port: 44897)
[server-binary_deploy:1447]    classlist: 567,496.65 ms
[server-binary_deploy:1447]        (cap):  17,790.34 ms
[server-binary_deploy:1447]        setup:  26,573.06 ms
[server-binary_deploy:1447]     analysis: 328,167.85 ms
Error: Unsupported features in 6 methods
Detailed message:
Error: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: Invoke with MethodHandle argument could not be reduced to at most a single call: java.lang.invoke.MethodHandle.bindTo(Object)
Trace: 
	at parsing java.lang.invoke.MethodHandleImpl.makePairwiseConvertByEditor(MethodHandleImpl.java:221)
Call path from entry point to java.lang.invoke.MethodHandleImpl.makePairwiseConvertByEditor(MethodHandle, MethodType, boolean, boolean): 
	at java.lang.invoke.MethodHandleImpl.makePairwiseConvertByEditor(MethodHandleImpl.java:207)
	at java.lang.invoke.MethodHandleImpl.makePairwiseConvert(MethodHandleImpl.java:194)
	at java.lang.invoke.MethodHandleImpl.makePairwiseConvert(MethodHandleImpl.java:380)
	at java.lang.invoke.MethodHandle.asTypeUncached(MethodHandle.java:776)
	at java.lang.invoke.MethodHandle.asType(MethodHandle.java:761)
	at java.lang.invoke.MethodHandleImpl.makeVarargsCollector(MethodHandleImpl.java:443)
	at java.lang.invoke.MethodHandle.setVarargs(MethodHandle.java:1325)
	at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1670)
	at java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:1605)
	at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:781)
	at java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:818)
	at java.lang.invoke.BoundMethodHandle$Factory.makeCtors(BoundMethodHandle.java:763)
	at java.lang.invoke.BoundMethodHandle$SpeciesData.<init>(BoundMethodHandle.java:349)
	at java.lang.invoke.BoundMethodHandle$SpeciesData$1.apply(BoundMethodHandle.java:389)
	at java.lang.invoke.BoundMethodHandle$SpeciesData$1.apply(BoundMethodHandle.java:383)
	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
	at java.util.stream.SpinedBuffer.forEach(SpinedBuffer.java:246)
	at java.util.stream.Nodes$SpinedNodeBuilder.forEach(Nodes.java:1262)
	at java.util.stream.SpinedBuffer.toString(SpinedBuffer.java:269)
	at java.lang.String.valueOf(String.java:2994)
	at java.lang.StringBuilder.append(StringBuilder.java:131)
	at com.oracle.svm.core.amd64.AMD64CPUFeatureAccess.verifyHostSupportsArchitecture(AMD64CPUFeatureAccess.java:179)
	at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:125)
	at com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b(generated:0)
[snipped]

[neomatrix369]

Is this similar to #1711, if so, it would be great if one fix sweeps both these types of issues?

[christianwimmer]

This is a different problem, but also on the list to be fixed for the 19.3 release.

[christianwimmer]

Fix merged for 19.3 release

[neomatrix369]

Thanks @christianwimmer for the update, look forward to the new release, will give it a whirl!