Paul Krill
Editor at Large

Java plan would support GPUs and other foreign programming models

Project Babylon would extend the reach of Java to foreign programming models such as machine learning models, GPUs, SQL, and differential programming.

CIO | Middle East  >  Iraq  >  Hillah  >  Panorama of Babylon ruins
Credit: HomoCosmicos / Getty Images

Java would be extended to foreign programming models such as machine learning models, GPUs, SQL, and differential programming, through an OpenJDK proposal called Project Babylon.

Posted in an openjdk.org mailing list on September 6 by Paul Sandoz, an architect at Oracle, Babylon would extend Java’s reach to foreign programming models with an enhancement to reflective programming in Java, known as code reflection. This would enable standard access, analysis, and transformation of Java code in a suitable form, the proposal states. Support for a foreign programming model could then be more easily implemented as a Java library.

Babylon would ensure that code reflection is suitable for the purpose by creating a GPU programming model for Java that leverages code reflection and is implemented as a Java library. To reduce bias risk, the project also would explore or encourage exploration of other programming models such as SQL and differential programming.

Code reflection consist of three parts:

  • Modeling of Java programs as code models, suitable for access, analysis, and transformation.
  • Enhancements to Java reflection, enabling access to code models at compile time and run time.
  • APIs to build, analyze, and transform code models.

Elaborating on what Babylon would address, Sandoz cited an example in which a developer wants to write a GPU kernel in Java and execute it on a GPU. The developer’s code must be analyzed and transformed into an executable GPU kernel. While a Java library could do that, it requires access to the Java code in symbolic form. Such access currently is limited to the use of non-standard APIs or to conventions at different points in the program’s life cycle, i.e. compile time or run time. Further, the symbolic forms available (abstract syntax trees or bytecodes) often are ill-suited to analysis and transformation.

Plans call for Babylon to be delivered over time, in a series of JDK Enhancement Proposals (JEP) likely to span multiple feature releases. Code reflection would start with a clone of the mainline release of JDK 22, which is due in March 2024, and track mainline releases moving forward.

For the GPU programming model, the project would create a separate repository dependent on code reflection features as they are developed. There currently is no plan to deliver the GPU programming model into the JDK, but work on that model could identify JDK features and enhancements of general utility that could be addressed in the future.

Paul Krill

Paul Krill is editor at large at InfoWorld. Paul has been covering computer technology as a news and feature reporter for more than 35 years, including 30 years at InfoWorld. He has specialized in coverage of software development tools and technologies since the 1990s, and he continues to lead InfoWorldโ€™s news coverage of software development platforms including Java and .NET and programming languages including JavaScript, TypeScript, PHP, Python, Ruby, Rust, and Go. Long trusted as a reporter who prioritizes accuracy, integrity, and the best interests of readers, Paul is sought out by technology companies and industry organizations who want to reach InfoWorldโ€™s audience of software developers and other information technology professionals. Paul has won a โ€œBest Technology News Coverageโ€ award from IDG.

More from this author