Code Models(openjdk.org)
openjdk.org
Code Models
https://openjdk.org/projects/babylon/articles/code-models
19 comments
How does reflection help with this? Is it by making it easier to write “compilers” from Java to whatever, using Java?
The answer is laid out in detail at the beginning (of this rather lengthy document). But short answer: yes.
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.
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.
Thanks, I was thinking LLMs
When okr from leaders drop to individuals, due to pretending-to-be-leader will change the intention causing deflection in the core principle.
It is what it is.
It is what it is.
Oh: Automatic differentiation of Java code using Code Reflection: https://openjdk.org/projects/babylon/articles/auto-diff
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 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".
It sounds cool but also like a remarkable level of scope creep for the JVM. I realize that Java ecosystem is far beyond simple these days. Nobody is spinning up a JVM implementation as a hobby project. But sad to see the deep entrenchment that is caused when an open standards platform is made so inconceivably complex that there is simply no opportunity to innovate on alternative implementations.
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.
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.
This is similar to the expression tree API of C# so no change in the JVM is required, only cooperation between the java compiler and the reflection API.
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.
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.
This looks like it's building on top of this prior JEP https://openjdk.org/jeps/457.
It looks complicated.
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
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
> Trace the control flow and regenerate the flow on target programming language.
that's not a model of the code that's just a trace...
that's not a model of the code that's just a trace...
Is this a runtime MIR?
Oh great, the one way to make reflection even more unpredictable than it already is...
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...
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...
[deleted]
epgui(1)
reminder: switch to openjdk if you haven't already
https://www.theregister.com/2024/06/20/oracle_java_licence_t...
https://www.theregister.com/2024/06/20/oracle_java_licence_t...
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."
See: https://openjdk.org/projects/babylon/