Our great sponsors
-
Graal
GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
graalvm-reachability-metadata
Repository which contains community-driven collection of GraalVM reachability metadata for open-source libraries.
-
cheerpj-meta
Run Java 8 applications, libraries, applets, Java Web Start, and Oracle Forms on the web without legacy plugins.
-
Not being facetious - but it works exactly like any other GC. There's nothing magic about writing code in Java instead of C that makes a huge difference.
But you might find this interesting - this is where it actually obtains memory from the OS.
https://github.com/oracle/graal/blob/44e68777b130c8ee781c72b...
Note the @Uninterruptible annotation - that's saying that this code is safe to use within the GC itself. Notice how the file doesn't contain even a single 'new! (Outside of PosixVirtualMemoryProviderFeature, which is something else.)
GraalVM is truly great stuff.
GraalVM native compilation helps Java in the data center to avoid being a cost sink and to reduce start-up latency. Oracle needs Java to sell enterprise software.
Oracle contributing to OpenJDK may be required for Amazon cooperation (since Amazon is pushing its own JDK build) and probably helps the library ecosystem work towards native compatibility.
Native support for reflection (used in many libraries) requires "reachability metadata), maps of reflective API usage, at build time. Anyone can do it, but enterprise requires authoritative sources. Until authoritative reachability metadata covers the transitive graph of library+version dependencies in enterprise software, GraalVM builds are a PITA.
- https://github.com/oracle/graalvm-reachability-metadata
- latest release: https://medium.com/graalvm/graalvm-22-3-is-here-jdk-19-build...
- graalvm "community" roadmap: https://github.com/orgs/oracle/projects/6
(As a side note: Mark Reinhold has run the JDK team since 1997: is there any comparable example of such stellar leadership for broadly-adopted software across multiple technical and organizational eras?)
>> It's not like you can take a random JAR and convert it to WASM.
Maybe you can:
TeaVM is an ahead-of-time compiler for Java bytecode that emits JavaScript and WebAssembly that runs in a browser. Its close relative is the well-known GWT. The main difference is that TeaVM does not require source code, only compiled class files. Moreover, the source code is not required to be Java, so TeaVM successfully compiles Kotlin and Scala.
https://teavm.org/
I have never had an opportunity to try out TeaVM, but it seems promising.
- https://github.com/leaningtech/cheerpj-meta
>> That wouldn't be of use in any existing Java project though. The only reason you'd ever want to do that is because browsers offer nothing else, even though they could and at that point why not compile to JS, at least that way your GC isn't being interpreted too. If you're not constrained by the WHATWG's decisions though it doesn't offer anything.
It is very use case and "what is the future of your Java application" dependent. Some organizations are looking into migrating off of Java due to a variety of reasons. These kind of "Java conversion" tools help to keep legacy Java applications running until the legacy Java applications can be replaced.
Here are some nice examples: https://www.graalvm.org/22.2/reference-manual/python/Interop...
This may be more readable: https://github.com/oracle/graalpython/blob/master/docs/user/...