👋
Nearly 1 year without a release, but today we are happy to share with you version 3.3.0 of Eclipse Golo!
This release is mainly about fixing bugs, internal gardening and improvements. The most notable feature is the introduction of tail-call elimination.
Many thanks to Yannick Loiseau who has been the main driving force in the recent months!
👍 Fully compatible with JDK 8
This release has been fully tested against OpenJDK 8u192. While Java 8 support by Oracle is ending soon, you have many free of charge long-term support options with OpenJDK builds from AdoptOpenJdk, Red Hat and Azul Systems.
😢 JDK 9 broke everything
You can run Golo on Java 11 and in most cases it will be just fine. You will likely get the typical warnings on illegal reflective access, but this is only a warning in the current JDK versions (9, 10, 11 and 12-ea).
Golo is however not supported on Java 11.
Oracle introduced Java modules in Java 9, and along the way made changes to the reflective access permissions.
About 20 years of assumptions on how reflection and class loading works on the JVM have been put aside to make way for a more restrictive (and supposedly “more secure”…) set of rules.
A full compatibility report with possible solutions is available at https://github.com/eclipse/golo-lang/issues/504.
In a nutshell:
- We use some deprecated reflection methods, leading to compilation warnings.
- Class loading needs to use another mechanism based on
MethodHandles.Lookuprather than using good-old custom class loaders. - Reflection at runtime yields warnings, we shall see how to mitigate them, possibly using JVM module-related flags.
- 1 test fails because of what is likely a JDK bug.
⚙️ Using non-traditional runtimes
The traditional JDK runtime is that of OpenJDK + the Hotspot compiler.
You may be interested in trying alternative runtimes, and if so here is what you need to know.
OpenJDK + Graal
You can replace the Hotspot JIT compiler (C2) with Graal.
Peak performance is excellent compared to Hotspot, especially as the escape analysis in Graal plays well with invokedynamic.
Still, it takes lots of runs before Graal starts emitting efficient code.
Substrate VM (Graal)
You may be tempted to generate a native executable from SVM, but since invokedynamic is on the list of unsupported features this will just not work.
OpenJ9
Golo works very well on this memory-efficient runtime. invokedynamic does not get the same boost as with Graal as a JIT compiler, but OpenJ9 + Golo remains an interesting combination when you consider memory and boot time.
💫 Where are we going?
We will continue to support Golo as it is now on Java 8, especially as there will be free supported builds of OpenJDK for many more years.
Our team is looking for enthusiasts to join and help us migrate the code base to Java 11 and beyond!
The technical challenges are fantastic, and Golo remains a small and approachable code base, so why not try if you have time? 😉 Feel-free to get in touch with us by email or Gitter and we will do our best to help you.
