Hi all, The talk may be interesting considering deprecation of -Xverify:none in JDK 13 (https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8214719) - people should know why "-Xverify:none" is so dangerous. Title: Java bytecode verification. When, how, or turn it off maybe? Abstract: Today's Java developers are increasingly relying on libraries that generate Java bytecode at run time to effectively implement various tricks that are hard or impossible to do in pure Java. However, while the javac compiler is guaranteed to produce correct Java bytecode, shifting down to the bytecode level requires that you keep track of its correctness yourself. Otherwise, there is a chance to get a j.l.VerifyError at run time upon the loading of a generated class, because the JVM passes all classes through the Java bytecode verifier to enforce strict correctness requirements. Therefore, knowing just the semantics of Java bytecode instructions is often not enough to properly synthesize classes - you also need to know how the Java bytecode verifier works, what bytecode it deems correct, and what it does not. In this talk, we will learn what mission the Java bytecode verifier carries out in the JVM, when and how it works, whether it may affect the performance of your application, and why turning it off is so dangerous. Recording: ok Bio: Nikita works for Huawei on JVMs, compilers and new programming languages. Before Huawei, Nikita had been the key figure in the Excelsior JET project for over twenty years. Excelsior JET was a complete Java SE implementation (JVM) with an AOT compiler, and Nikita took part in almost all activities pertaining to that project, from core JVM development to product management and support. In particular, he is the author of OSGi support at the JVM level, the Java Runtime Slim-down technology - Java SE modularization implemented in Excelsior JET since 2007, both Java bytecode verifiers, Spring Boot support, and many other features. Nikita