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?
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 😂
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.
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.
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.
I'd also disagree that its hacking the language. Its a *part* of the language. Look at method handles and proxies, this is how they're implemented. As for why these tools "need" to, performance and lack of flexibility of other solutions. Generating bytecode and loading it is insanely fast. There are also cases where you do not know what you may need at compile time, so generation on the fly is required.
EDIT: This is a reply to a now deleted comment which doubled down on bytecode generation being a "hack", and labeling it "bad engineering" due to lack of observability. We're just gonna have to agree to disagree then on those semantics. I also find runtime generation to be immensely useful. Java and its ecosystem would be MUCH worse off without it.
@@mattcoley I think so as well. It also depends on which systems you are building. If you need to minimize outages and build for robustness, then any magic is contra productive, as it's literally outside of your sight. The only way to find out what code my program executes exactly (e.g., which proxies are in between the call, etc.), I need to throw on the debugger and run execution in slow motion, to understand what things are at play. I think this is a very bad practice that has become normal in Java. It's where engineering in Java got derailed. Throwing on the debugger is considered a last resort in other programming languages but in Java there is no debugging without a debugger. Happy debugging in production.
Definitely need a JEP Cafe episode on this topic!
I'd love to see a JEP Cafe about it.
Excellent content!
I agree, asm updates are one of the PITA for java updates
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?
woow this is great man!
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 😂
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.
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.
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.
You ask an important question but I disagree that it "inevitably leads to a mess".
I'd also disagree that its hacking the language. Its a *part* of the language. Look at method handles and proxies, this is how they're implemented.
As for why these tools "need" to, performance and lack of flexibility of other solutions. Generating bytecode and loading it is insanely fast. There are also cases where you do not know what you may need at compile time, so generation on the fly is required.
EDIT: This is a reply to a now deleted comment which doubled down on bytecode generation being a "hack", and labeling it "bad engineering" due to lack of observability.
We're just gonna have to agree to disagree then on those semantics.
I also find runtime generation to be immensely useful. Java and its ecosystem would be MUCH worse off without it.
@@mattcoley I think so as well. It also depends on which systems you are building. If you need to minimize outages and build for robustness, then any magic is contra productive, as it's literally outside of your sight. The only way to find out what code my program executes exactly (e.g., which proxies are in between the call, etc.), I need to throw on the debugger and run execution in slow motion, to understand what things are at play. I think this is a very bad practice that has become normal in Java. It's where engineering in Java got derailed. Throwing on the debugger is considered a last resort in other programming languages but in Java there is no debugging without a debugger. Happy debugging in production.
Metallicaaaaa 🤘