eclipse-openj9
Proposal to format the OpenJ9 Compiler component with `clang-format`
As many in this community are no doubt aware, the Eclipse OMR project recently formatted its compiler component using clang-format [1]; furthermore, the project defines a linter that requires that all changes satisfy the format defined by the .clang-format file [2] as interpreted by clang-format version 18.1.8.
Since OpenJ9 extends OMR, and since the OpenJ9 compiler component is very strongly tied to the OMR compiler component, I am proposing that OpenJ9
- Format its compiler component with
clang-formatusing the same config file and version as OMR - Define a linter to (automatically) enforce maintenance of the format
This ensures consistency between the compiler components between the two projects, and unifies the development experience. It also acts as a pilot for the OpenJ9 project, should the project decide to generalize this effort at some point in the future to encompass more than just the compiler component.
To get a sense of what the formatted code looks like, I've formatted a relatively recent branch [3]. This branch contains two main changes.
Namespace Merging, which is done via
#!/bin/bash
files=$(find ./runtime/compiler -iname '*.h' -o -iname '*.c' -o -iname '*.hpp' -o -iname '*.cpp')
echo $files | xargs perl -0777 -i -pe 's/(([ \t]*namespace J9 {[\S \t]+}\n)+)/namespace J9 {\n$1}\n/g'
echo $files | xargs perl -0777 -i -pe 's/(([ \t]*namespace TR {[\S \t]+}\n)+)/namespace TR {\n$1}\n/g'
echo $files | xargs perl -i -pe 's/namespace (J9|TR) {[ \t]*([\S ]*\S)[ \t]*}/$2/g'
and the actual Code Formatting, which is done via
#!/bin/bash
files=$(find ./runtime/compiler -iname '*.h' -o -iname '*.c' -o -iname '*.hpp' -o -iname '*.cpp')
echo $files | xargs ~/bin/clang/bin/clang-format -style=file:<path to omr rep>/compiler/.clang-format -i
Realistically speaking, the OMR project is still in the process of letting the new workflow bake in, and developers are still in the process of settling into the new development process. However, I wanted to open this issue to allow developers in the OpenJ9 project to
- Have time to think about this proposal
- Look at the OMR project and how development, specifically that of the compiler component, is progressing post code format
- Explore the formatted branch to provide comments and/or feedback
Ideally OpenJ9 would reuse as much of what's already defined in OMR as possible, but it would be good get community consensus on this matter. Furthermore, considering [4], it would good to look at some of the post code format tasks that OMR undertakes so as to pre-emptively address them in OpenJ9 should the community agree to move forward with this proposal.
See also [5], [6], [7], [8] as points of interest for this effort.
[1] https://github.com/eclipse-omr/omr/issues/7434 [2] https://github.com/eclipse-omr/omr/blob/master/compiler/.clang-format [3] https://github.com/dsouzai/openj9/tree/codeformat_test/runtime/compiler [4] https://github.com/eclipse-omr/omr/issues/7883 [5] https://github.com/eclipse-omr/omr/pull/7846 [6] https://github.com/eclipse-omr/omr/blob/master/doc/compiler/CodingStandard.md [7] https://github.com/eclipse-omr/omr/issues/7885 [8] https://github.com/eclipse-omr/omr/pull/7939
I support this proposal, but I don't think we should be in a hurry. There are some kinks to be worked out with the docker image containing clang_format (for example, it doesn't work as is on Fedora Core 41).
A retrospective on how this source formatting experience has been in the Eclipse OMR project was discussed at the Nov 6, 2025 OMR Architecture Meeting. Replay link can be found in the agenda for anyone interested -> https://github.com/eclipse-omr/omr/issues/8003
