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

[Doug Simon]

On Fri, 20 Oct 2023 15:32:55 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:
> 
>   fix copyright dates and @since tags to reflect history

Ok, thanks for the clarification. What about the copyright dates on the `module-info.java` files?

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

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