Code Models
openjdk.org
openjdk.org
This is part of "Project Babylon" and its mission is to: "extend the reach of Java to foreign programming models such as SQL, differentiable programming, machine learning models, and GPUs. Babylon will achieve this with an enhancement to reflective programming in Java, called code reflection."
It is what it is.
Currently, the problem with a Java program is that you have two two forms representations: Full-detail Syntax and low-level bytecode. However, other JDK projects find themselves wanting something in the middle. Or even better, be able to create a custom model of the program for a specific purpose.
Ventures into this space are not entirely new. Several years ago, there was some research into "lambda cracking". Aka removing all glue-code from how Java Streams work and turn them into efficient iterative code (think Rust Iterators). But this never came far. With this approach, you could have specialized models for spezialied features without forcing the whole ecosystem to adopt another general-purpose model that very likely ends up being opinionated.
This sounds interesting.
I remember that Swift for TensorFlow was similar.
Maybe you could also consider JAX to be similar.
Basically, can you do now sth similar as JAX but for Java? The article also talks about "the Babylon GPU work requires the transformation of code models to GPU kernels".
This is not an observation about this specific project, just about the organizational pressure to extend standards based systems beyond their core functionality, into territory where only few players can afford to roam.
The code model can be computed by the compiler, inserted in the classfile in a specific binary or text format and read at runtime using the reflection API.
I've not taken a look to the implementation so it's speculation but I do not think the JVM need to be changed.
Here is my technique.
Trace the control flow and regenerate the flow on target programming language.
In their's they have abstracted problem such as blocks and operation. But adding more condition to the philosophy is hard thing. The core principle needs simple
that's not a model of the code that's just a trace...
So instead of "only" finding that my choice of method names, class structure and presence or absence of ostensibly unused class members can change programs behaviour in arbitrary ways, now that property will extend to the implementation code itself?
Have fun getting reliable static analysis working on this stuff...
https://www.theregister.com/2024/06/20/oracle_java_licence_t...