This approach offers advantages over the traditional approach of one language, one VM. For example, any program that is compiled for GraalVM can share libraries with other programs that is likewise compiled. Developers can write in different languages but still maintain interoperability and code reuse across them all. This also allows developers to continue to use code written in “older languages” while migrating to a new one. Similarly, it allows the continued used of majority language, such as Java, while leveraging languages that are built for specific purposes, such as R. Another advantage of GraalVM is ubiquity. One VM for multiple needs means fewer VMs to provision and update across IT servers and containers. That can be a serious time saver and makes maintaining large and complex systems a bit easier.
GraalVM is also embeddable. The ability to build plugins using GraalVM was one of the reasons that Oracle started the Graal project. By creating GraalVM compatible code that can be embedded in an Oracle Database opens the door to customers extending their Oracle databases. This is clearly better than writing code outside the database for common query-related processing.
GraalVM has serious potential. It can simplify a complex VM landscape and allow choice in programming languages without proliferation of VMs and libraries. At the moment, it’s mostly potential, especially given the limited range of supported programming languages. That potential, however, is the reason why GraalVM is worth keeping an eye on.