I recently installed jdk10. I was doing normal code and it is not working.
Am I doing something wrong here?
Please see the code and Exception stacktrace.
As far as I understand there should be no reason for such behaviour.
import com.bean.College;
public class Student {
interface Club {
<T> T get(College<T> key);
}
private Club club;
Student() {
Object obj = club.get(new College<>() {});
}
}
The imported College class is:
public class College<T> {
int id;
protected College() {
}
College(int id){
this.id=id;
}
}
On compiling this the javac compiler crashes with the following stacktrace:
java.lang.NullPointerException
at jdk.compiler/com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitApply(Flow.java:1233)
at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634)
at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:396)
at jdk.compiler/com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitVarDef(Flow.java:987)
at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:956)
at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:396)
at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
at jdk.compiler/com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitBlock(Flow.java:995)
at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1020)
at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:396)
at jdk.compiler/com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitMethodDef(Flow.java:962)
at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866)
at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:396)
at jdk.compiler/com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitClassDef(Flow.java:925)
at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774)
at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:396)
at jdk.compiler/com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1325)
at jdk.compiler/com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1315)
at jdk.compiler/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:216)
at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1393)
at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1367)
at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965)
at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306)
at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165)
at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
It is a reported unresolved bug. The bug is planned to be resolved in jdk 11.
JDK-8203195-Anonymous class type inference results in NPE
Type: Bug
Status: In Progress
Priority: P2
Resolution: Unresolved
Affects Version/s: 9, 10, 10.0.1, 11
Fix Version/s: 11
Component/s: tools
Labels: dcsfai reproducer-yes webbug
Subcomponent: javac
CPU: generic
OS: generic
https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8203195?filter=allopenissues
However, there is a work around mentioned in the bug description which states:
Interestingly, changing A.java to do the following:
Object baz => foo.foo(new B<Object>() {});
or changing foo/B.java to the
following:
package foo;
public class B<T> {
B(int baz) { }
protected B() { }
}
results in a successful compilation.
Even tho the bug reports status is still open using java 11 fixes that issue for me
I had exactly the same error and I couldn't find any solution. Even when I tried to build using java 11 (some say it is fixed there) it still failed with the same error.
But the error was just MISLEADING. After some changes in code and retries (I removed some code..), I found that the actual error was some missing libraries, which I added in the classpath and the build was successful!
Related
I have a simple project: https://github.com/MarcoLunar/native-pid-test
All what it is doing is calling getpid from C library. Project is as simple as:
public static void main(String[] args) throws Exception {
System.out.println("start");
C_lib cLib = Native.loadLibrary("c", C_lib.class);
int getpid = cLib.getpid();
System.out.println("pid = " + getpid);
System.out.println("end");
}
When launching from IDE everything works fine:
start
pid = 155080
end
When trying to build using native-image from GraalVM I got this error:
[simpletest:155323] compile: 2,597.81 ms, 2.05 GB
Fatal error:org.graalvm.compiler.graph.GraalGraphError: java.lang.NullPointerException
at node: 43|&
at method: Object com.oracle.svm.reflect.JNIGeneratedMethodSupport_getFieldOffsetFromId_5041c78d77a7b3d62103393b72fc35d80d2cc709.invoke(Object, Object[])
at org.graalvm.compiler.phases.common.CanonicalizerPhase$Instance.tryCanonicalize(CanonicalizerPhase.java:397)
at org.graalvm.compiler.phases.common.CanonicalizerPhase$Instance.processNode(CanonicalizerPhase.java:325)
at org.graalvm.compiler.phases.common.CanonicalizerPhase$Instance.processWorkSet(CanonicalizerPhase.java:302)
at org.graalvm.compiler.phases.common.CanonicalizerPhase$Instance.run(CanonicalizerPhase.java:264)
at org.graalvm.compiler.phases.common.CanonicalizerPhase.run(CanonicalizerPhase.java:177)
at org.graalvm.compiler.phases.common.CanonicalizerPhase.run(CanonicalizerPhase.java:73)
at org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:214)
at org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:147)
at com.oracle.svm.hosted.code.CompileQueue.doInlineTrivial(CompileQueue.java:587)
at com.oracle.svm.hosted.code.CompileQueue.access$000(CompileQueue.java:156)
at com.oracle.svm.hosted.code.CompileQueue$TrivialInlineTask.run(CompileQueue.java:284)
at com.oracle.graal.pointsto.util.CompletionExecutor.lambda$execute$0(CompletionExecutor.java:173)
at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
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)
Caused by: java.lang.NullPointerException
at org.graalvm.compiler.nodes.calc.BinaryArithmeticNode.tryConstantFold(BinaryArithmeticNode.java:120)
I have tried many times, many different solutions ... but for now I have no more to check.
I am asking for help in repairing the project. I think this is possible, because with some configurations I have the same error as in https: //github.com/oracle/graal/issues/2261 ... where someone fixed it ... but didn't write the solution: (
I think currently JNA doesn't work in native image. You can use JNI if that's possible. Or you can use another interface to native code that will work specifically in the native images. Some info can be found in the javadoc of org.graalvm.nativeimage.c and its subpackages: https://www.graalvm.org/sdk/javadoc/index.html?org/graalvm/nativeimage/c/package-summary.html
Here's an example of using it: https://www.praj.in/posts/2020/opengl-demo-using-graalvm/
When I call eval (in strict mode) on a nashorn engine with the following script I get an exception:
var yfunc = function () {
(null).apply(null, arguments);
};
yfunc();
I've truncated my personal situation heavily. The "(null)" on line 2 can be replaced with anything between parenthesis or a local variable, either way just something that shouldn't throw a compile error, and it will yield the same result.
The issue seems to be explicitly that "arguments" is passed directly as the second argument of calling a method called "apply". Any of the following changes will undo the thrown exception:
Putting "arguments" in a variable first (but simply wrapping it in parenthesis doesn't work!)
Calling something other than apply
Passing "arguments" in a different argument slot when calling apply
Calling print() (with or without passing any arguments) as a preceding line of code inside yfunc() (weird huh?)
Defining more than 0 parameters for yfunc()
Binding yfunc first and then calling the bound method
Calling yfunc via Function.apply (not so much with Function.call!)
The Exception thrown is this:
Exception in thread "main" java.lang.ClassCastException: Cannot cast jdk.nashorn.internal.runtime.Undefined to jdk.nashorn.internal.runtime.ScriptFunction
at java.lang.invoke.MethodHandleImpl.newClassCastException(MethodHandleImpl.java:361)
at java.lang.invoke.MethodHandleImpl.castReference(MethodHandleImpl.java:356)
at jdk.nashorn.internal.scripts.Script$\^eval\_.:program(<eval>:4)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:637)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:449)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:406)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:402)
at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:155)
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
When I call this method with an owner, the exception thrown changes. Example code:
var yfunc = {
method: function () {
(null).apply(null, arguments);
}
};
var x = yfunc.method();
Then the thrown exception looks like this:
Exception in thread "main" java.lang.ClassCastException: Cannot cast jdk.nashorn.internal.scripts.JO4 to jdk.nashorn.internal.runtime.ScriptFunction
at java.lang.invoke.MethodHandleImpl.newClassCastException(MethodHandleImpl.java:361)
at java.lang.invoke.MethodHandleImpl.castReference(MethodHandleImpl.java:356)
at jdk.nashorn.internal.scripts.Script$\^eval\_.:program(<eval>:5)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:637)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:449)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:406)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:402)
at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:155)
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
I've reproduced the issue so far on specifically these environments:
windows 7 64bit -> jdk 1.8.0_60 64bit
windows 8 64bit -> jdk 1.8.0_131 64bit
I can't seem to find anything on the internet about similar issues. Do I need to report this to Oracle/OpenJDK?
Minor update
Added items 6 and 7 to list of "following changes will undo the thrown exception".
Final update
Bug filed: JDK-8184720
Yes, it appears to be a bug. Please file a bug.
I'm trying to build an uberjar using lein uberjar. During compiling, the following gets thrown:
Exception in thread "main" java.lang.NullPointerException, compiling:(/tmp/form-init8223412427040046857.clj:1:73)
at clojure.lang.Compiler.load(Compiler.java:7391)
at clojure.lang.Compiler.loadFile(Compiler.java:7317)
at clojure.main$load_script.invokeStatic(main.clj:275)
at clojure.main$init_opt.invokeStatic(main.clj:277)
at clojure.main$init_opt.invoke(main.clj:277)
at clojure.main$initialize.invokeStatic(main.clj:308)
at clojure.main$null_opt.invokeStatic(main.clj:342)
at clojure.main$null_opt.invoke(main.clj:339)
at clojure.main$main.invokeStatic(main.clj:421)
at clojure.main$main.doInvoke(main.clj:384)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.NullPointerException
at clojure.string$lower_case.invokeStatic(string.clj:217)
at clojure.string$lower_case.invoke(string.clj:213)
at kappa.joke_classifier$is_jokable_QMARK_.invokeStatic(joke_classifier.clj:32)
at kappa.joke_classifier$is_jokable_QMARK_.invoke(joke_classifier.clj:29)
at kappa.core$maybe_joke.invokeStatic(core.clj:47)
at kappa.core$maybe_joke.invoke(core.clj:45)
at clojure.core$run_BANG_$fn__7276.invoke(core.clj:7393)
at clojure.lang.PersistentVector.reduce(PersistentVector.java:341)
at clojure.core$reduce.invokeStatic(core.clj:6544)
at clojure.core$run_BANG_.invokeStatic(core.clj:7388)
at clojure.core$run_BANG_.invoke(core.clj:7388)
at kappa.core$run.invokeStatic(core.clj:58)
at kappa.core$run.invoke(core.clj:53)
at kappa.core$_main.invokeStatic(core.clj:66)
at kappa.core$_main.doInvoke(core.clj:61)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.Var.invoke(Var.java:375)
at user$eval5.invokeStatic(form-init8223412427040046857.clj:1)
at user$eval5.invoke(form-init8223412427040046857.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6927)
at clojure.lang.Compiler.eval(Compiler.java:6917)
at clojure.lang.Compiler.load(Compiler.java:7379)
... 14 more
The code using string/lower-case looks as follows:
(defn is-jokable? [msg]
(and
(> 30 (count msg))
(= :positive (.classify classifier (str/lower-case msg)))
(< 1 (:positive (.probabilities classifier (str/lower-case msg))))))
As can be seen from the stack trace, my -main function calls a function that eventually calls is-jokable, and str/lower-case seems to be called with nil. If I understand correctly this is because of the AOT compilation happening for uberjars, but I'm not quite sure why exactly this problem occurs... I've already tried to read up on AOT, but didn't find anything helpful. Can you explain the inner workings of AOT to me?
I'm almost embarrassed I have posted this, it must have been too late in the night... ;)
I got completely distracted by the compiling and invokeStatic hints in the stacktrace, and just now found that this was indeed an everyday bug where I expected a map to contain a key/value pair that wasn't existent, leading to nil being passed to the function in question.
Thanks for the helpful comments!
While I've tried to use the following code snippet with the Groovy in-operator explanation the VerifyError has occured. Have you guys any idea about?
The code and console output is below.
class Hello extends ArrayList {
boolean isCase(Object val) {
return val == 66
}
static void main(args) {
def myList = new Hello()
myList << 55
assert 66 in myList
assert !myList.contains(66)
}
}
The error log:
Exception in thread "main" java.lang.VerifyError: (class: Hello, method: super$1$stream signature: ()Ljava/util/stream/Stream;) Illegal use of nonvirtual function call
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:259)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:116)
The code origin from the topic How does the Groovy in operator work?.
Update:
Groovy Version: 1.8.6 JVM: 1.6.0_45 Vendor: Sun Microsystems Inc. OS: Linux
Check this out.
It's for Java, but generally problem is, that you are using wrong library versions. The class is there, but different version than expected.
http://craftingjava.blogspot.co.uk/2012/08/3-reasons-for-javalangverfiyerror.html
Probably you have messed up Groovy or Java SDK installations.
After learning Lambda Expressions in Java, I tried to practice some simple examples. But in my first example only I am getting the following error.
Exception in thread "main" java.lang.IncompatibleClassChangeError
at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:384)
at com.example.lambda.HelloLambda.main(HelloLambda.java:15)
Caused by: java.lang.NoSuchMethodException: no such method: java.lang.invoke.LambdaMetafactory.metaFactory(Lookup,String,MethodType,MethodHandle,MethodHandle,MethodType)CallSite/invokeStatic
at java.lang.invoke.MemberName.makeAccessException(MemberName.java:763)
at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:880)
at java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:1019)
at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1284)
at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:382)
... 1 more
Caused by: java.lang.NoSuchMethodError: java.lang.invoke.LambdaMetafactory.metaFactory(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
at java.lang.invoke.MethodHandleNatives.resolve(Native Method)
at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:852)
at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:877)
... 4 more
The error seems an error because of backward compatibility issue. But don't know how to fix this. Many answers in StackOverFlow suggested Recompilation could fix this issue. But still I am getting this error.
My code
package com.example.lambda;
public class HelloLambda {
static String firstname = "ChanSek";
static String lastname = "Nayak";
interface HelloService {
String hello();
}
public static void main(String[] args) {
HelloService helloService =
() -> {String hello="Hello " + firstname + " " + lastname;
return hello;};
System.out.println(helloService.hello());
}
}
The code compiles fine. But running gives the above mentioned error.
I am using JDK1.8.0 snapshot.
Is it possibly because of this?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8019635
The way lambdas have been done in Java 8 has changed, very recently (07/2013), in a not backwards compatible way.
If you've somehow managed to compile with a compiler which talks PRE beta 103 lambdas, but are running with a JRE of POST 103 lambdas, you'll have problems.
(The hint for me here is that the metafactory name used to be mixed case, but in java 1.8.0 beta 103 appears to be lower case - you're searching for mixed case, but not finding it.)