JDK-8310310 : Migrate CreateSymbols tool in make/langtools to Classfile API
  • Type: Sub-task
  • Component: tools
  • Sub-Component: javac
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-06-19
  • Updated: 2025-04-14
  • Resolved: 2025-04-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25
25 b18Fixed
Related Reports
Blocks :  
JDK-8352748 - Remove com.sun.tools.classfile from the JDK
Causes :  
JDK-8354497 - Build fails by jdk24: ClassEntry is a preview API and is disabled by default
Relates :  
JDK-8332109 - Convert remaining tests using com.sun.tools.classfile to ClassFile API
Description
The CreateSymbols tool uses jdk.jdeps class file parser library to read bytecode, in CreateSymbols::loadVersionClasses. It should be converted to use the Classfile API in long run.

Also to be migrated:
test/langtools/tools/javac/platform/CanHandleClassFilesTest.java
test/langtools/tools/javac/platform/CreateSymbolsTest.java
Comments
Changeset: 4dc9e589 Branch: master Author: Chen Liang <liach@openjdk.org> Date: 2025-04-09 14:51:15 +0000 URL: https://git.openjdk.org/jdk/commit/4dc9e58906772bf8ee444cb1618aa43f66593d79
09-04-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24212 Date: 2025-03-25 00:39:17 +0000
07-04-2025
While the buildtools resides in the "make" directory, they are really the responsibilities of the respective component teams.
22-09-2023
Note that a challenge here is that CreateSymbols has to run on the BOOT_JDK (which is by definition of version JDK N-1). It looks like the tool is currently compiled together with the bytecode parser from the current (JDK N) source for jdk.jdeps, but targeting the BOOT_JDK version, instead of using the bytecode parser in jdk.jdeps in the BOOT_JDK itself. The reason for this is likely that the bytecode parser needs to be able to handle JDK N bytecode. If CreateSymbols is to use the new classfile API, then that API needs to be built for and runnable on the BOOT_JDK as well. Is that part of the design for the new API?
28-08-2023