New Class-File API will make Java Updates easier - Inside Java Newscast #56

Java bytecode is created by the compiler and interpreted by the JVM, but that is just a part of the truth. It is also generated, analyzed, manipulated, and instrumented during build and run time by various tools, frameworks, and libraries. That plays well into Java's dynamism but also has downsides, a big one being that manipulating bytecode can only be done reliably by libraries that were released after the Java version, for which the bytecode was compiled. As a consequence a Java update often requires updating a considerable portion of the a project's dependencies.

The new class-file API that Brian Goetz presented at JVMLS in august 2023 will improve that situation greatly by shipping an always up-to-date bytecode anlysis and manipulation API with the JDK.

~~ Links ~~

~~ Chapters ~~

0:00 Intro
0:39 Bytecode Basics
1:41 Bytecode Manipulation Basics
2:54 Migration Pains
4:39 Class-File API
6:34 Alleviating Migration Pains
7:35 Timeline
8:37 Outro

Tags: #Java #OpenJDK #InsideJava

[kostiapereguda]

Definitely need a JEP Cafe episode on this topic!

[VerhoevenSimon]

I'd love to see a JEP Cafe about it.

[berndeckenfels]

I agree, asm updates are one of the PITA for java updates

[LordPankake]

How will the API handle edge cases like unused attributes with invalid constant pool indices? Or attributes of the wrong type in unexpected locations?

Currently if you make a class and give it a local variable attribute (on the class, not on the method) the JVM ignores it and loads the class fine. This is fine and dandy but because its ignored you can have the code attribute filled with junk data, like a local variable entry with types referencing pool entries beyond the max size of the pool, or of the wrong type. The runtime ignores this attribute but a class file parser like ASM attempts to give you the full model of the class. When it tries to resolve these invalid indices it crashes.

This is obviously a niche case, but is employed by a number of commercial obfuscators. If the runtime adopts usage of this API, will these applications break or will there be stricter guidelines in the JVMS spec to disallow this, such that the class file api does not need to support this case?

[xichenliu-wr]

Is there any possibility that the API might be scheduled ahead? I noticed that the Classfile API is going to preview in JDK22, it's a really fascinating features that I would like to use in my library.

[ThreeDots]

you can tell how long it took to record this 9 min video by the shadow progression and those guys on the grass going from shirtless sunbathing to having shirt on and leaving 😂

[AbdullahAlMamun-fhgs]

Can you please make a session on JVM full architecture according to Java-9. I think there have a lot of changes in class loader subsystem for module system.

[LexComments]

I'd rather ask why these tools even need to hack the language and generate bytecode behind the scenes rather than using language capabilities. This can only mean that there is magic injected that is implicit and hidden in the normal code reading flow of any developer. This inevitably leads to a mess that nobody actually would put his or her hand into the fire if asked if they fully understand what their code is actually doing (or they just believe to know by reading the docs). Being explicit is key - hiding away code that literally changes how my code operates - is problematic.