8361216: Do not fork javac in J2DBench ant build

[ericcaspole]

Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8361216: Do not fork javac in J2DBench ant build (Bug - P4)

Reviewers

• Phil Race (@prrace - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26077/head:pull/26077
$ git checkout pull/26077

Update a local copy of the PR:
$ git checkout pull/26077
$ git pull https://git.openjdk.org/jdk.git pull/26077/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26077

View PR using the GUI difftool:
$ git pr show -t 26077

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26077.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back ecaspole! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@ericcaspole This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8361216: Do not fork javac in J2DBench ant build

Reviewed-by: prr

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 66 new commits pushed to the master branch:

• ec3bb93: 8358623: Avoid unnecessary data copying in ICC_Profile
• 39c9de2: 8359958: Cleanup "local" debuggee references after JDK-8333117 removed support for non-local debuggees
• 05c9eec: 8361214: An anonymous class is erroneously being classify as an abstract class
• ... and 63 more: https://git.openjdk.org/jdk/compare/282ee40a56af46521b94fe6e4c90e78b8f513b29...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk]

@ericcaspole The following label will be automatically applied to this pull request:

• client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (a2ad30c8)

[mrserb]

Maybe we should drop the ant script and use only makefile which have a way to override default source/target?

[ericcaspole]

We only test back to 8 so we don't need to change it more often. But JDK 24/25 does not support source 7 so we should do something. I think JAVA_HOME with ant is simpler than specifying lots of vars to makefile but I don't have strong opinion.

[magicus]

Where, how and why are this antscript or the src/demo/share/java2d/J2DBench/Makefile used?

The JDK build system builds the demos using make/CompileDemos.gmk.

[ericcaspole]

I dont know the history of J2DBench or how its build was developed. It looks like J2DBench is not included in the JDK demos build. My goal here, if possible, is to make a build of it from the mainline repo that is JDK8 compatible, so we can use one jar for all perf testing from 8 onwards. Hopefully someone with some client history can comment.

[magicus]

The long-term goal is to remove demos from mainline. Most have already been removed. The few that remains was used for client testing, iirc. They have not been updated since jdk8 and are unlikely to be. Can't you just build the jar from JDK8? Or if you need the code for testing, create a copy alongside your other tests?

[ericcaspole]

Could we move J2DBench under test next to micro/ ? It's not a demo, it's a benchmark but somehow it ended up under demos. It should remain available to contributors.

[prrace]

It isn't a demo and it isn't a jtreg test.
Everything under src/share/demo is client related which may be why it is there.
But the right home for it is
test/jdk/performance/client
next to RenderPerfTest and SwingMark
But that location came along a long time after j2dbench

[prrace]

They have not been updated since jdk8 and are unlikely to be.

not true. They are updated regularly and I expect an enhancement to add some new feature testing some time in the next year.

[prrace]

I kind of wonder if
test/jdk/performance/client
should be
test/jdk/client/performance/
and then we could have
test/jdk/client/jfc
for SwingSet etc.

But all of that is for another day. This PR is about the ant build

[prrace]

and don't get confused about the ant and make stuff. The JDK build does not and is not expected to build j2dbench
It is built directly by a developer when they need to run it.
I think the ant build was for developers who use certain IDEs.
I tend to use the make option.

[prrace]

This would be inconsistent with the Make target. It doesn't seem right to update just the ant-based target.

[ericcaspole]

Yes I realized that yesterday, I never actually looked at or used the Makefile before. I will update the Makefile so it least this PR in its own right is consistent, regardless of these other discussion points.

[mrserb]

I think we can just drop ant and leave the makefile as it is. The source/target settings are set to that low level to indicate that the source code should be compatible with older versions of the JDK. Currently, JDK 1.4 compatibility is still maintained.

[prrace]

I think we can just drop ant and leave the makefile as it is. The source/target settings are set to that low level to indicate that the source code should be compatible with older versions of the JDK. Currently, JDK 1.4 compatibility is still maintained.

I have supposed that this PR exists because Eric wants to use ant. Eric ?

I think for today's mainline, not supporting jdk7 as an out of the box target isn't a huge problem.
Current javac doesn't support 7 as a target so it seems reasonable to me.

[mrserb]

Current javac doesn't support 7 as a target so it seems reasonable to me.

That's why the makefile was parameterized, to easily set the target and source options based on the currently used minimal supported version of javac. But we may change it with a comment that 1.4 still should be supported, or something like that.

[magicus]

and don't get confused about the ant and make stuff. The JDK build does not and is not expected to build j2dbench
It is built directly by a developer when they need to run it.

I don't like how there is a separate build system like this. The fact that a resource does not need to be built everytime, but only when it is needed, is not a reason for it to not be built like everything else in the JDK source tree. If J2DBench is needed by developers, then the normal build system should be able to handle building that.

Now this discussion is spinning away a bit from the original PR, but I'd like to better understand what purpose the remaining demos serve, and if they are really located in the right place.

From what I can see we have these demos:

• java2d/J2DBench
• jfc/CodePointIM
• jfc/FileChooserDemo
• jfc/Font2DTest
• jfc/J2Ddemo
• jfc/Metalworks
• jfc/Notepad
• jfc/SampleTree
• jfc/Stylepad
• jfc/SwingSet2
• jfc/TableExample
• jfc/TransparentRuler

All the jfc demos are built by the normal JDK build system. But some of them also have additional build.xml files, and J2DBench also have a separate Makefile.

[prrace]

The build.xml files are for people who use netbeans.
Very recently, I proposed deleting them, but someone from redhat stepped up to offer to maintain them.
https://mail.openjdk.org/pipermail/client-libs-dev/2025-June/029847.html

And people don't want to have to have to build JDK in order to use J2DBench, nor is there any reason for the JDK build to compile it, so I don't think you should sweat that the JDK build system doesn't build it.
Putting it somewhere miles away in a JDK build directory, even if it can be done independently of building a JDK you are making it harder, not easier.

[mrserb]

But from another point of view, nothing prevents us from additionally building it as part of the JDK image or JDK test-image build, just to ensure it is buildable, and perhaps it would be useful to include it in the sanity test group simply to touch that code.(and other perf tests as well).

Very recently, I proposed deleting them, but someone from redhat stepped up to offer to maintain them.
https://mail.openjdk.org/pipermail/client-libs-dev/2025-June/029847.html
That was about demos, so we still can drop it in J2DBench.