![](https://squidex.jugru.team/api/assets/srm/3FoIqWuW0LPock3TpgDwB8/102425-947849468-andrew-dinn-static-java-graalvm-native-and-openjdk.jpg?cache=3600&width=74&height=74&mode=CropUpsize)
Andrew Dinn
Company: Red Hat
Talk type: Talk
Java is specified as an extensible, dynamic language with an extensible, dynamic runtime. However, GraalVM Native has demonstrated that it is possible to deliver many Java apps as static deployments, with most application and runtime choices pre-configured at build time. This shift in behavior enables performance trade-offs that suit current trends in containerization, most notably the ultra-fast startup and low memory footprint demanded micro-service and serverless deployments. It also risks opening up a gap between language and runtime specification vs implementation, with build-time choices forcing runtime and application code down different execution paths in static vs dynamic deployments.
This talk will explain why such divergence arises, both of necessity and by virtue of how the JDK runtime and some Java apps are currently implemented. To ground this problem in experience Andrew will describe how GraalVM Native implements a static model that diverges from dynamic behavior while still managing to retain compatibility for most programs. Speaker will provide examples to highlight some of the potential risks this entails, while also explaining how GraalVM Native manages to achieve fast startup and low footprint.
Andrew will move on to discuss the OpenJDK project Leyden, whose most important goal is to scope, minimize and sanction by specification legitimate opportunities for divergence between static and dynamic deployments of the same app. He will briefly introduce the different project outputs needed to achieve this goal: an extended Java language and runtime specification, a comprehensive validation suite, and fully functional and, perhaps, performant reference implementation. In conclusion, there will be reporting on some preliminary experiments Red Hat has undertaken as a step toward implementing the last of these three outputs.
Company: Red Hat