Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8174440 | 10 | Rickard Backman | P3 | Resolved | Fixed | b01 |
Description
I tried to change compilation of SPEC benchmarks from using
-J-cp -J<lib1>:...:<libN> benchmark.jar to --classpath <lib1>:...:<libN> benchmark.jar
It was expected to work this way but it produces java.lang.InternalError because of class resolution. I see that JEP 295 text states the option as a "<path>" but it's really confusing when compared to javac.
jdk.tools.jaotc.collect.ClassCollector code threats options.classpath as a single entry which actually can be jar or directory. Seems to be not too complex to split the option by cp separator and threat it as a bunch of jars/dirs.
Besides that ClassCollector is supposed to report an error if the path is malformed but it doesn't.
Currently there are 3 variants for file arguments:
1. .jar file. --classpath is ignored.
Expected to be a valid classpath which helps to resolve external references.
2. .class file. Classpath is treated as a path, arg is treated as not fully qualified class name.
Expected real classpath for URLClassLoader to contain --classpath entries and the class to be loaded properly.
3. Class name. Classpath is treated as a path where .class file is searched with file name matching arg, which is treated as not fully qualified class name.
Expected valid classpath and fully qualified class name here, e.g. "jaotc --classpath . test.HelloWorld" instead of "jaotc --classpath . HelloWorld".
Note, there is also a modulepath.
-J-cp -J<lib1>:...:<libN> benchmark.jar to --classpath <lib1>:...:<libN> benchmark.jar
It was expected to work this way but it produces java.lang.InternalError because of class resolution. I see that JEP 295 text states the option as a "<path>" but it's really confusing when compared to javac.
jdk.tools.jaotc.collect.ClassCollector code threats options.classpath as a single entry which actually can be jar or directory. Seems to be not too complex to split the option by cp separator and threat it as a bunch of jars/dirs.
Besides that ClassCollector is supposed to report an error if the path is malformed but it doesn't.
Currently there are 3 variants for file arguments:
1. .jar file. --classpath is ignored.
Expected to be a valid classpath which helps to resolve external references.
2. .class file. Classpath is treated as a path, arg is treated as not fully qualified class name.
Expected real classpath for URLClassLoader to contain --classpath entries and the class to be loaded properly.
3. Class name. Classpath is treated as a path where .class file is searched with file name matching arg, which is treated as not fully qualified class name.
Expected valid classpath and fully qualified class name here, e.g. "jaotc --classpath . test.HelloWorld" instead of "jaotc --classpath . HelloWorld".
Note, there is also a modulepath.
Attachments
Issue Links
- backported by
-
JDK-8174440 [AOT] jaotc --classpath option is confusing
- Resolved
- relates to
-
JDK-8175336 [TESTBUG] aot junit tests added by 8169588 are not executed.
- Resolved
-
JDK-8175052 [AOT] jaotc does not accept file name with .class
- Closed
-
JDK-8177069 File separator mismatch on Win-64
- Resolved
-
JDK-8176010 [AOT] Three AOT jtreg tests fail on windows
- Closed