There's more to Java than just the language. Let's learn about the special way in which Java code is run, and what else this platform is capable of.

1. Java
And the Java Virtual Machine

2. What is Java?
• Language
• Platform

3. What’s a Java Platform?
• Enables you to develop and run code on varied hardware and OSes
• API specification
• Runtime environment (JRE)
• Libraries (which implement the platform API)
• Execution engine (VM)
• Development kit (JDK)
• Includes JRE (above)
• Compiler, debugger, profiler, disassembler…

4. Show me some Java Platforms
• Java SE (Standard Edition)
• Jakarta EE (Enterprise Edition)
• Open-sourced to the Eclipse Foundation
• Oracle is keeping the Java EE trademark
• Java ME (Micro Edition)
• Mobile devices
• Java Card
• Embedded devices, IoT
• Security-sensitive applications

5. Diagram of the Java SE Platform
• (Next slide)

7. What’s Jakarta EE?
• Java SE + specs and APIs for “enterprise” features
• Servlet (handle a client request, frequently HTTP)
• JPA (map JVM classes to database tables)
• JTA (transactions)
• JAX-RS (describe a RESTful web service)
• JAXB (un)marshalling of JSON, XML
• A Jakarta EE application server provides libraries fulfilling these APIs
• Only a handful of servers are certified as complete implementations
• There’s a (smaller) “Web Profile” with the bits people actually use

8. Do I need Jakarta EE?
• You could try your luck with a server that’s not certified as compatible
• TomCat remains popular, and was once certified
• You can cherry-pick the bits you want
• If you like JPA, you can have it (e.g. via Hibernate)
• You can disagree on some design points (see Spring)
• Building to a standard may protect you from vendor lock-in
• Beware drama: Oracle has restricted Eclipse’s use of trademarks
• Jakarta EE will be forced to make a big breaking change to rename packages

9. What’s the deal with Spring?
• Application framework
• Frequently served via an application server (e.g. TomCat)
• Spring integrates with some Jakarta EE specs
• Servlet, Bean Validation, JPA
• Differs philosophically in some places
• Spring MVC instead of JAX-RS for describing REST APIs
• “Controllers” rather than “Resources”
• You can still use JAX-RS if you want
• Jackson/Gson for (un)marshalling
• You can still use JAX-B if desired

10. Concerning .NET

11. Breaking news (May 2019)
• .NET Core now has most capabilities of .NET Framework 4.8
• .NET Framework is now deprecated
• .NET Core is rebranded as .NET
• Skips version 4
• So now we’re on .NET 5
• The upcoming slides were once correct

12. In case any of this sounds familiar…
Java SE .NET
Bytecode format Java bytecode CIL (e.g. MSIL)
Execution engine JVM VES (e.g. CLR)
Standard library Java SE APIs .NET Standard
Extended library Java EE APIs Additional APIs within .NET Core / .NET
Framework

13. Differences between .NET and Java Platform
• Bytecode-compatibility
• Old Java bytecode will run on new JVMs
• .NET bytecode breaks forward-compatibility to enable new features
• Linking
• Java “links” via an execution engine option (classpath)
• .NET libraries are dynamically linked, and can also load assemblies at runtime
• Execution
• Java has no executable; main class is an argument to execution engine
• .NET executables are libraries plus metadata

14. Differences between .NET and Java Platform
• Generics
• Java bytecode has no concept of generics (compilers “erase” them)
• Generics exist at runtime in .NET bytecode, and can be reified
• Special features supported in .NET bytecode
• Value types, stackalloc, pointers
• Move program counter / time-travel debugging
• JIT
• JVM JIT implementations use ambitious and complex optimizations
• .NET JIT is simpler. Performance through language features instead

15. Aside: .NET Framework vs .NET Core
• Original .NET specification was coupled to Windows and IIS
• Same GC and JIT (RyuJIT), same base class libraries (.NET Standard)
• Core is refactored to be modular and with fewer dependencies
• Core provides .NET Native; ahead-of-time compile CIL to native code
• Core Lacks features like Application Domains, Code Access Security
• Both implement Microsoft’s Common Language Infrastructure
• Program structure
• CIL bytecode format (e.g. MSIL)
• Virtual Execution System (e.g. CLR)

16. Aside: Mono
• An open-source implementation of .NET Framework
• Cross-platform
• Microsoft-sponsored non-Microsoft project
• Supported by Xamarin… who were bought by Microsoft
• Implements Microsoft’s specifications for C# and the CIL
(standardized by ECMA and ISO)
• Pretty cool until .NET Core was announced

17. Java is a poor man’s Docker
• Application servers (e.g. Tomcat) are basically k8s worker nodes
• JRE is basically a Container OS
• JVM is basically runc
• Java SE APIs are basically system libraries
• EAR/WAR artefacts are basically Container Images
• Compile your application once, deploy anywhere

18. Method signatures
• These impossible classes are possible in JVM bytecode, but not Java
• Overload method on return type
• Two fields with same name (but different types)
class C {
void a(String s) {}
int a(String s) { return 0; }
}
class C {
int a;
String a;
}

19. JVM for ultra low-latency computing
• Industry will pay $150k/month for a 3ms edge on the competition
• JVM GC pauses are frequently bigger than this
• Consider a Direct Market Access application
• Parse, validate, serialize message, check risk, read market data, serialize, send
• JVM can do this in ~10 microsecs, just as fast as C/C++
• Admittedly you have to write very non-idiomatic code, and complete warmup
• FPGA ~1 microsec
• ASIC ~400 nanosecs
• Python 50x slower

20. Should I run Java on the JVM?
1. Should I run Java on the JVM?
2. Should I run Java on the JVM?

21. Sun/Oracle Hotspot JVM JIT
• Method inlining, loop unrolling
• On-stack replacement
• Jump from interpreted code to JIT’d equivalent whenever code becomes hot
• Escape analysis
• Object fields are replaced with scalar values, avoiding heap allocation
• Monomorphic dispatch (avoid vtable lookup)
• Intrinsics (replace method with something more native)
• Dynamic deoptimization
• As access patterns change or new classes loaded: undo and try again

22. Sun/Oracle Hotspot JVM JIT
• Two compilers, tiered compilation (as of Java 7)
• C1 (Client)
• Fast startup
• Emits simple native code
• Still faster than executing bytecode in an interpreter
• C2 (Server)
• Generates better native code
• Decides how best to optimize based on execution profiles
• May frequently de-optimize
• Old, complex C++ codebase (needs replacing – more on this later)

23. Sun/Oracle Hotspot JVM JIT
• Tiered compilation
• Level 0 – interpreted code
• Level 1 – simple C1 compiled code (with no profiling)
• Level 2 – limited C1 compiled code (with light profiling)
• Level 3 – full C1 compiled code (with full profiling)
• Level 4 – C2 compiled code (uses profiling data from previous steps)
• Usually 0 -> 3 -> 4
• More complex code warrants more profiling, compilation

24. Sun/Oracle Hotspot JVM GC
• G1 (Java 8)
• Specify your latency requirements (“20 ms is the longest I’d wait for GC”)
• ZGC (Java 11)
• Low (<10ms) pause times even on multi-terabyte heaps
• Future support: multi-tiered heaps (hot objects in DRAM, cold in NVMe flash)
• Heap compression
• Pointer colouring (sell more SPARC machines)
• Shenandoah (Java 12)
• Low, constant pause time
• Most work done concurrently

25. Dalvik
• Google’s implementation of JVM for Android
• Caused Oracle to sue Google for 9 years (so far)
• Uses registers as primarily unit of data-storage instead of stack
• Avoid instruction dispatch, unnecessary memory access
• Higher semantic density per instruction
• 30% fewer instructions, 35% fewer code units
• 35% more bytes in instruction stream (but we consume two at a time)
• Combines .class files into .dex (Dalvik Executables)
• De-dupes any repeated information, saving 50% space

26. OpenJDK vs Oracle JDK
• Around Java SE 7, various JVMs converged.
• Oracle provided some extra ”commercial features”
• Incident analysis
• Font rendering
• Class sharing (for faster startup, smaller footprint)
• ZGC garbage collector
• For Java 11, Oracle upstreamed these. Basically the same now.
• Oracle JDK is (now) commercial
• OpenJDK is (now) provided by Red Hat (previously Oracle)

27. Hipster JVMs
• Amazon Corretto
• Zero-cost LTS
• Azul Zing
• Faster startup (saves previously-used JIT profile for re-use)
• Falcon JIT (high-performance server JIT based on LLVM)
• C4 garbage collector (concurrent, compacting, no GC pause)
• TeaVM
• AoT compiles JVM bytecode to JS or WebAssembly
• GraalVM (more on this later)

28. Hipster JVMs
• Or use the CLR
• Not standards-compliant
• Due to native interface

29. Should I run Java on the JVM?
1. Should I run Java on the JVM?
2. Should I run Java on the JVM?

30. JavaScript on the JVM
• Rhino; Java 1.4/1997 – part of an all-Java Netscape Navigator
• JVM JIT outperformed C++, but memory leaky and slow startup
• Interpreted mode was
• Nashorn; Java 8/2011
• “Several orders of magnitude” faster
• Deprecated in Java 11 because JavaScript was changing too fast to keep up
• GraalVM
• Suggested as a way to replace Nashorn
• More on this later

31. Other JVM languages
• Scala
• Has a “criticism” section on Wikipedia
• Kotlin
• Made by JetBrains (i.e. IntelliJ, Resharper)
• Coroutines, generators, safe navigation, elvis ?:, reification, data classes, FP
• Fast compilation (aiming to be as fast as Java, and not slow like Scala)
• Compiles to JS and native code
• Clojure
• Lisp, REPL
• Compiles to JS too

32. Other JVM languages
• Groovy
• Used for DSLs (for example data engineering)
• Used for Gradle config (now being replaced by Kotlin)
• JRuby
• Contributed invokedynamic instruction to JVM (not used by Java!)
• Dynamically changes classes and methods at runtime
• Outperforms real Ruby, especially in concurrent code (thanks to JVM threads)
• Jython
• Sounds like it’s for people who concede JVM has good libraries, but hate Java

33. GraalVM
• Oracle Labs research project based on JDK 8
• Universal Virtual Machine
• JVM-based languages
• LLVM-based languages
• Node.js, Python, Ruby, R
• JIT and AoT compiler (Graal)
• Language AST interpreter (Truffle)
• Enables language-agnostic debugger, profiler, heap viewer
• Compilation to native images, with minimal runtime (SubstrateVM)

34. GraalVM – JIT Compiler (Graal)
• Written in Java
• Compile Java using Java, rather than C++ (“Java-on-Java”)
• Generates native code (like LLVM/Clang does)
• Integrates into any JDK that supports JVM CI (Compiler Interface)
• JVM CI lets a JVM use as its dynamic compiler: any compiler written in Java
• Oracle Labs has backported JVM CI to JDK 8
• JVM CI ships with JDK 11 proper
• Replace Hotspot JIT’s C2 compiler
• Optimized performance for Truffle-based languages running on JVM

35. GraalVM – Ahead-of-time compilation
• Uses Graal compiler too
• Includes minimal runtime, SubstrateVM
• Smaller memory footprint
• Zero-dependency native image
• Tiny filesize (Spring web application + runtime in 36MB)
• Instant startup (deploy Spring web application in about 50ms)
• Produce native libraries (for your other native code to link to)
• Optionally include Graal compiler to complement AoT with JIT
• Build image with profile-guided optimizations from previous runs

36. GraalVM – Truffle
• Library for building programming language implementations
• Describe language as an interpreter for a self-modifying Abstract Syntax Tree
• Low-overhead language interop
• Performance matches or exceeds other language runtimes
• General instrumentation framework
• Multi-language debugging (via Chrome DevTools!)
• Profiling
• Heap view

37. GraalVM – Truffle

38. GraalVM – LLVM
• GraalVM implements LLVM’s LLI tool
• Directly execute programs from LLVM bitcode
• First you must compile any program (e.g. C, C++, Rust) to LLVM IR
• Note: platform-dependent
• LLI interprets the IR, then dynamically compiles hot parts using Graal
• Enables seamless interop with other dynamic languages in GraalVM

39. GraalVM – Database embed
• Oracle Database, MySQL
• Use GraalVM languages and modules… inside a SQL statement
• Write SELECT statements that:
• Classify whether a string is an email address
• Detect credit card brand

40. GraalVM – Performance
• Twitter cut their CPU usage by 13% by switching to GraalVM
• Across thousands of machines running thousands of JVMs
• See “Twitter’s Quest for a Wholly Graal Runtime”
• Better inlining, and across language boundaries
• Partial escape analysis
• Remove costly object allocations in more scenarios
• More aggressive speculative optimizations
• Full set of optimizations only available with Enterprise license!

41. Advantages compared to standard runtime
• Run Node.js with large-heap configuration and JVM’s GC
• V8 is tuned for browsers and small-heap scenarios
• Re-use libraries from Java, R, or Python… in Node.js
• Use Python for data science
• Use R for plotting graphs
• Use Java for Spark or Flink

42. That’s all
• Alex Birch