1

For those who know jaotc, I have a simple question for you.

After you do

javac HelloWorld.java
jaotc --output HelloWorld.so HelloWorld.class

You can run

java -XX:AOTLibrary=./HelloWorld.so HelloWorld

without any problem. This is what has been shown on the internet everywhere. Fine with me.

However, if you move your HelloWorld.class somewhere else that is not in your classpath, and run

java -XX:AOTLibrary=./HelloWorld.so HelloWorld

again, then you will get a class not found error.

So the original .class file is still needed? Then what's the point of doing the AOT?

Joe
  • 53
  • 6
  • The point is faster JVM startup. – Stephen C Jul 25 '18 at 05:03
  • @StephenC, yes, but it _is_ easily confused with "Native Compilation", which is what I too thought it was at first. This AOT compilation is still highly useful in that the runtime class loading is out of the way---so you're not hassled with the phantom slowdowns that Java routinely strikes on first-runs, but it's not producing, say, a `HelloWorld.exe` (or similar) for you to ship. Anywhere you send it still needs the full hoopla of a JSE installed, and your classes. This seems to be as of JDK-15 anyway. Someone _please_ let me know if there's a true native compiler on the horizon. – alife Sep 28 '22 at 19:42
  • @alife - Try this: https://www.graalvm.org/22.1/reference-manual/native-image/ – Stephen C Sep 29 '22 at 10:37
  • @StephenC, that _is_ interesting, thanks. I suppose the "Substrate VM" (their term) is as close to bare wires as they can get without inventing a new language altogether. – alife Oct 06 '22 at 15:34

2 Answers2

0

Yes, at least so far. You may refer to http://openjdk.java.net/jeps/295 :

Since class bytecodes can change over time, either through changes to the source code or via class transformation and redefinition, the JVM needs to detect such changes and reject AOT-compiled code if the bytecode doesn't match. This is achieved with class fingerprinting. During AOT compilation a fingerprint for each class is generated and stored in the data section of the shared library. Later, when a class is loaded and AOT-compiled code is found for this class, the fingerprint for the current bytecode is compared to the one stored in the shared library. If there is a mismatch then the AOT code for that particular class is not used.

craigcaulfield
  • 3,381
  • 10
  • 32
  • 40
Yanhui Xie
  • 1
  • 1
0

I suspect this when I found out that the only Java Native Image that ever gets loaded in my native version of Minecraft is that the one of java.base. I don't know why until I read this.

AOT images are just alternative images to use if possible. They are NOT a replacement of the original Java bytecode.

This is done just in case the JVM args are different and/or running on a different platform. I believe that IKVM.NET fit your purpose better if you are trying to make a Java Native Application.

Jessie Lesbian
  • 1,273
  • 10
  • 14