Synchronize the spelling of class path, module path, and other compounds

Author: olyagpl

docs/graalvm-as-a-platform/implement-language.md

@@ -227,7 +227,7 @@ Apply the `--upgrade-module-path` option together with `-Dgraalvm.locatorDisable
 A sample POM using `--upgrade-module-path` to export Language API packages can be found in the [Simple Language POM.xml](https://github.com/graalvm/simplelanguage/blob/master/language/pom.xml#L58) file.
 
 > Note: Disabling the locator effectively removes all installed languages from the module path as the locator also creates the class loader for the languages.
-To still use the builtin languages add them to the module-path by pointing the module-path to all needed language homes (for example, `$GRAALVM/languages/js`).
+To still use the built-in languages, add them to the module path by updating the module path to include the paths of all the languages you need (for example, `$GRAALVM/languages/js`).
 
 ### Other JVM Implementations
 

docs/introduction.md

@@ -28,7 +28,7 @@ Subject to the conditions in the license, including the License for Early Adopte
 Oracle GraalVM is also free to use on Oracle Cloud Infrastructure.
 For more information about Oracle GraalVM licensing, see the [Oracle Java SE Licensing FAQ](https://www.oracle.com/java/technologies/javase/jdk-faqs.html#GraalVM-licensing).
 
-GraalVM Community Edition is open-source software built from the sources available on [GitHub](https://github.com/oracle/graal) and distributed under [version 2 of the GNU General Public License with the “Classpath” Exception](https://github.com/oracle/graal/blob/master/LICENSE), which are the same terms as for Java.
+GraalVM Community Edition is open-source project built from the sources available on [GitHub](https://github.com/oracle/graal) and distributed under [version 2 of the GNU General Public License with the “Classpath” Exception](https://github.com/oracle/graal/blob/master/LICENSE), which are the same terms as for Java.
 Check the [licenses](https://github.com/oracle/graal#license) of individual GraalVM components which are generally derivative of the license of a particular language and may differ.
 
 ## What to Read Next

docs/reference-manual/embedding/embed-languages.md

@@ -84,16 +84,16 @@ module com.mycompany.app {
 Whether your configuration can run with a Truffle runtime optimization depends on the GraalVM JDK you use.
 For further details, refer to the [Runtime Compilation section](#runtime-optimization-support).
 
-We recommend configuring polyglot embeddings using modules and the module-path whenever possible. 
-Be aware that using polyglot from the class-path instead will enable access to unsafe APIs for all libraries on the class-path.
-If the application is not yet modularized, hybrid use of the class and module-path is possible.
+We recommend configuring polyglot embeddings using modules and the module path whenever possible. 
+Be aware that using `org.graalvm.polyglot` from the class path instead will enable access to unsafe APIs for all libraries on the class path.
+If the application is not yet modularized, hybrid use of the class path and module path is possible.
 For example:
 ```
 $JAVA_HOME/bin/java -classpath=lib --module-path=lib/polyglot --add-modules=org.graalvm.polyglot ...
 ```
 In this example, `lib/polyglot` directory should contain all polyglot and language JAR files.
-In order to access polyglot classes from the class-path you also need to specify the `--add-modules=org.graalvm.polyglot` JVM option.
-If you are using [native-image](https://www.graalvm.org/latest/reference-manual/embed-languages/#build-native-executables-from-polyglot-applications) polyglot modules on the class-path will be automatically upgraded to the module-path.
+To access polyglot classes from the class path, you must also specify the `--add-modules=org.graalvm.polyglot` JVM option.
+If you are using [native-image](https://www.graalvm.org/latest/reference-manual/embed-languages/#build-native-executables-from-polyglot-applications), polyglot modules on the class path will be automatically upgraded to the module path.
 
 While we do support creating single uber JAR files from polyglot libraries, for example using the Maven Assembly plugin, we do not recommend it.
 Also note that uber JAR files are not supported in combination with creating native-images.
@@ -499,7 +499,7 @@ If the runtime was excluded successfully, you should see the following log messa
 ```
 [engine] WARNING: The polyglot engine uses a fallback runtime that does not support runtime compilation to native code.
 Execution without runtime compilation will negatively impact the guest application performance.
-The following cause was found: No optimizing Truffle runtime found on the module or class-path.
+The following cause was found: No optimizing Truffle runtime found on the module or class path.
 For more information see: https://www.graalvm.org/latest/reference-manual/embed-languages/.
 To disable this warning use the '--engine.WarnInterpreterOnly=false' option or the '-Dpolyglot.engine.WarnInterpreterOnly=false' system property.
 ```

docs/reference-manual/java-on-truffle/Interoperability.md

@@ -142,7 +142,7 @@ class Embedding {
 
 A number of useful context option can be set with `contextBuilder.option(key, value)`:
 * Java properties can be added by settings `java.Properties.property.name` to the desired value (in this case this would set the `property.name`).
-* `java.Properties.java.class.path` can be used to set the classpath of the Java on Truffle context.
+* `java.Properties.java.class.path` can be used to set the class path of the Java on Truffle context.
 * `java.Properties.java.library.path` can be used to set the native library path of the Java on Truffle context.
 * `java.EnableAssertions` can be set to `true` to enable assertions.
 * `java.EnableSystemAssertions` can be set to `true` to enable assertions in the Java standard library.

docs/reference-manual/java-on-truffle/README.md

@@ -14,7 +14,7 @@ See the [Implementation Details](ImplementationDetails.md) for more information.
 The project name behind this implementation is "Espresso".
 Its open source version is available on [GitHub](https://github.com/oracle/graal/tree/master/espresso).
 
-The Java on Truffle execution mode runs Java via a Java bytecode interpreter, implemented with the [Truffle framework](../../../truffle/docs/README.md) – an open-source library for writing interpreters for programming languages.
+The Java on Truffle execution mode runs Java via a Java bytecode interpreter, implemented with the [Truffle framework](../../../truffle/docs/README.md) – an open source library for writing interpreters for programming languages.
 Now Java can be executed by the same principle as other languages in the GraalVM ecosystem (JavaScript, Ruby, Python, R), directly interoperate with those languages, and pass data back and forth in the same memory space.
 Besides complete language interoperability, with Java on Truffle you can:
 

docs/reference-manual/native-image/BuildConfiguration.md

@@ -144,15 +144,15 @@ However, you can prevent unwanted linking errors by specifying which classes are
 For that, use the `--link-at-build-time` option. 
 If the option is used in the right context (see below), you can specify required classes to link at build time without explicitly listing classes and packages.
 It is designed in a way that libraries can only configure their own classes, to avoid any side effects on other libraries.
-You can pass the option to the `native-image` tool on the command line, embed it in a `native-image.properties` file on the module-path or the classpath.
+You can pass the option to the `native-image` tool on the command line, embed it in a _native-image.properties_ file on the module path or the class path.
 
 Depending on how and where the option is used it behaves differently:
 
-* If you use `--link-at-build-time` without arguments, all classes in the scope are required to be fully defined. If used without arguments on command line, all classes will be treated as "link-at-build-time" classes. If used without arguments embedded in a `native-image.properties` file on the module-path, all classes of the module will be treated as "link-at-build-time" classes. If you use `--link-at-build-time` embedded in a `native-image.properties` file on the classpath, the following error will be thrown:
+* If you use `--link-at-build-time` without arguments, all classes in the scope are required to be fully defined. If used without arguments on command line, all classes will be treated as "link-at-build-time" classes. If used without arguments embedded in a _native-image.properties_ file on the module path, all classes of the module will be treated as "link-at-build-time" classes. If you use `--link-at-build-time` embedded in a _native-image.properties_ file on the class path, the following error will be thrown:
     ```
-    Error: Using '--link-at-build-time' without args only allowed on module-path. 'META-INF/native-image/org.mylibrary/native-image.properties' in 'file:///home/test/myapp/MyLibrary.jar' not part of module-path.
+    Error: Using '--link-at-build-time' without args only allowed on module path. 'META-INF/native-image/org.mylibrary/native-image.properties' in 'file:///home/test/myapp/MyLibrary.jar' not part of module path.
     ```
-* If you use the  `--link-at-build-time` option with arguments, for example, `--link-at-build-time=foo.bar.Foobar,demo.myLibrary.Name,...`, the arguments should be fully qualified class names or package names. When used on the module-path or classpath (embedded in `native-image.properties` files), only classes and packages defined in the same JAR file can be specified. Packages for libraries used on the classpath need to be listed explicitly. To make this process easy, use the `@<prop-values-file>` syntax to generate a package list (or a class list) in a separate file automatically.
+* If you use the  `--link-at-build-time` option with arguments, for example, `--link-at-build-time=foo.bar.Foobar,demo.myLibrary.Name,...`, the arguments should be fully qualified class names or package names. When used on the module path or class path (embedded in `native-image.properties` files), only classes and packages defined in the same JAR file can be specified. Packages for libraries used on the class path need to be listed explicitly. To make this process easy, use the `@<prop-values-file>` syntax to generate a package list (or a class list) in a separate file automatically.
 
 Another handy option is `--link-at-build-time-paths` which allows to specify which classes are required to be fully defined at build time by other means.
 This variant requires arguments that are of the same type as the arguments passed via `-p` (`--module-path`) or `-cp` (`--class-path`):

docs/reference-manual/native-image/BuildOptions.md

@@ -89,7 +89,7 @@ Run `native-image --help` for help on build options.
 
 Run `native-image --help-extra` for help on additional options.
 
-* `--exclude-config`: exclude configuration for a comma-separated pair of classpath/modulepath pattern and resource pattern. For example: `--exclude-config foo.jar,META-INF\/native-image\/.*.properties` ignores all properties files in _META-INF/native-image_ in all JAR files named _foo.jar_.
+* `--exclude-config`: exclude configuration for a comma-separated pair of class path/module path pattern and resource pattern. For example: `--exclude-config foo.jar,META-INF\/native-image\/.*.properties` ignores all properties files in _META-INF/native-image_ in all JAR files named _foo.jar_.
 * `--expert-options`: list image build options for experts
 * `--expert-options-all`: list all image build options for experts (use at your own risk). Options marked with _Extra help available_ contain help that can be shown with `--expert-options-detail`
 * `--expert-options-detail`: display all available help for a comma-separated list of option names. Pass `*` to show extra help for all options that contain it.

docs/reference-manual/native-image/BuildOverview.md

@@ -10,7 +10,7 @@ redirect_from: /reference-manual/native-image/Build-Overview/
 
 The syntax of the `native-image` command is:
 
-- `native-image [options] <mainclass> [imagename] [options]` to build a native binary from the main class in the current working directory. The classpath may optionally be provided with the `-cp <classpath>` option where `<classpath>` is a colon-separated (on Windows, semicolon-separated) list of paths to directories and JAR files.
+- `native-image [options] <mainclass> [imagename] [options]` to build a native binary from the main class in the current working directory. The class path may optionally be provided with the `-cp <classpath>` option where `<classpath>` is a colon-separated (on Windows, semicolon-separated) list of paths to directories and JAR files.
 - `native-image [options] -jar jarfile [imagename] [options]` to build a native binary from a JAR file.
 - `native-image [options] -m <module>/<mainClass> [imagename] [options]` to build a native binary from a Java module.
 

docs/reference-manual/native-image/Bundles.md

@@ -175,7 +175,7 @@ The full option help of `--bundle-apply` shows a more advanced use case that wil
 ### Building in a Container
 
 Another addition to the `--bundle-create` and `--bundle-apply` options is to perform image building inside a container image.
-This ensures that during the image build `native-image` can not access any resources that were not explicitly specified via the classpath or module path.
+This ensures that during the image build `native-image` can not access any resources that were not explicitly specified via the class path or module path.
 
 Modify the `--bundle-create` argument in the Maven / Gradle Native Image plugin configuration above to `<buildArg>--bundle-create,container<buildArg>`.
 This still creates the same bundle as before. 
@@ -322,7 +322,7 @@ native-image --bundle-apply=application-pgo-optimized.nib
 
 As described later in [Bundle File Format](#bundle-file-format), a bundle file is a JAR file with a contained launcher for launching the bundled application.
 This means you can use a native image bundle with any JDK and execute it as a JAR file with `<jdk>/bin/java -jar [bundle-file.nib]`.
-The launcher uses the command line arguments stored in _run.json_ and adds all JAR files and folders in _input/classes/cp_ and _input/classes/p_ to the classpath and module path respectively.
+The launcher uses the command line arguments stored in _run.json_ and adds all JAR files and directories in _input/classes/cp/_ and _input/classes/p/_ to the class path and module path, respectively.
 
 The launcher also comes with a separate command-line interface described in its help text:
 ```
@@ -334,7 +334,7 @@ where options include:
 
     --with-native-image-agent[,update-bundle[=<new-bundle-name>]]
                 runs the application with a native-image-agent attached
-                'update-bundle' adds the agents output to the bundle-files classpath.
+                'update-bundle' adds the agents output to the bundle-files class path.
                 '=<new-bundle-name>' creates a new bundle with the agent output instead.
                 Note 'update-bundle' requires native-image to be installed
 
@@ -395,7 +395,7 @@ Inside a bundle you can find the following inner structure:
 │       ├── path_substitutions.json          <- Record of path-substitutions that happened
 │       │                                       during bundle creation for the input files                                        
 │       └── run.json            <- Full command line for executing the bundled application
-│                                                        (minus classpath and module path)
+│                                                        (minus class path and module path)
 └── output
     ├── default
     │   ├── myimage         <- Created image and other output created by the image builder