RFR: 8318027: Support alternative name to jdk.internal.vm.compiler [v3]

[Jonathan Gibbons]

On Fri, 20 Oct 2023 15:45:50 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-fix since tags to reflect current JDK release

The proposed name `jdk.compiler.graal` makes it seem like the module is strongly related to the `jdk.compiler` module, which contains `javac` and related tools, whereas these modules are completely unrelated.

Is there not a better name that can be used?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16189#issuecomment-1773211363