-
Bug
-
Resolution: Fixed
-
P4
-
None
-
None
Basically if a make variable expands to contain a filename for a nested class (ie one with $ in it) then you need to escape the $ so that make doesn't treat it as a meta-character. And because $ is also the shell meta-character you end up needing a double escape of the form \$$$$, depending on how that variables gets used in targets/pre-reqs/recipes.
Prior to the nashorn change ListPathsSafely didn't do any $ escaping and any explicit reference to a nested class file, such as:
sun/awt/motif/X11GB2312\$$$$Decoder.class
in the makefile, had to use the \$$$$. And everything worked fine.
What nashorn introduced was .java files with $ in their name:
> dir ../nashorn/src/jdk/nashorn/internal/scripts/
total 16
drwxr-xr-x 2 daholme uucp 4096 Feb 26 01:26 .
drwxr-xr-x 8 daholme uucp 4096 Feb 26 01:26 ..
-rw-r--r-- 1 daholme uucp 2027 Feb 26 01:26 JO$.java
-rw-r--r-- 1 daholme uucp 1322 Feb 26 01:26 JS$.java
so when ListPathsSafely was used together with a src directory to expand into a set of source files, there was no $ escaping and so the $ got dropped from the name, and so the nashorn build failed.
So the escaping was added to ListPathsSafely. But not the full \$$$$ as the need for that depends upon exactly how the make variable is used. For Java compilation commands ListPathSafely only had to do a simpler $ -> $$ escape sequence.
But this means that anything explicitly escaped with \$$$$ and passed to ListPathsSafely was now broken as there were too many escapes. This is what broke the profiles builds. So to fix that we had to reduce the number of escapes in the explicitly named files ie:
sun/awt/motif/X11GB2312\$$Decoder.class
so that after processing by ListPathsSafely it was back to the full \$$$$ form.
That would have been the end of it, except not all uses of nested class file names get passed through ListPathsSafely. Those that do not still need the \$$$$ escape, while those that do need only \$$. Hence we have the problem that when writing the name of such a file you have to know how it is going to be used - which is not a very maintainable solution.
Solution:
------------
It was determined that the use of $ in .java file names was not necessary in nashorn and that usage has now been removed -JDK-8009379. Consequently we can revert the change introduced by nashorn in:
http://hg.openjdk.java.net/jdk8/tl/diff/5b0b6ef58dbf/common/makefiles/MakeBase.gmk
and revert the subsequent fix-ups done under
http://hg.openjdk.java.net/jdk8/tl/jdk/diff/022cd5adc0fa/makefiles/profile-rtjar-includes.txt
http://hg.openjdk.java.net/jdk8/tl/jdk/diff/ecd33c6ab12f/makefiles/CreateJars.gmk
Prior to the nashorn change ListPathsSafely didn't do any $ escaping and any explicit reference to a nested class file, such as:
sun/awt/motif/X11GB2312\$$$$Decoder.class
in the makefile, had to use the \$$$$. And everything worked fine.
What nashorn introduced was .java files with $ in their name:
> dir ../nashorn/src/jdk/nashorn/internal/scripts/
total 16
drwxr-xr-x 2 daholme uucp 4096 Feb 26 01:26 .
drwxr-xr-x 8 daholme uucp 4096 Feb 26 01:26 ..
-rw-r--r-- 1 daholme uucp 2027 Feb 26 01:26 JO$.java
-rw-r--r-- 1 daholme uucp 1322 Feb 26 01:26 JS$.java
so when ListPathsSafely was used together with a src directory to expand into a set of source files, there was no $ escaping and so the $ got dropped from the name, and so the nashorn build failed.
So the escaping was added to ListPathsSafely. But not the full \$$$$ as the need for that depends upon exactly how the make variable is used. For Java compilation commands ListPathSafely only had to do a simpler $ -> $$ escape sequence.
But this means that anything explicitly escaped with \$$$$ and passed to ListPathsSafely was now broken as there were too many escapes. This is what broke the profiles builds. So to fix that we had to reduce the number of escapes in the explicitly named files ie:
sun/awt/motif/X11GB2312\$$Decoder.class
so that after processing by ListPathsSafely it was back to the full \$$$$ form.
That would have been the end of it, except not all uses of nested class file names get passed through ListPathsSafely. Those that do not still need the \$$$$ escape, while those that do need only \$$. Hence we have the problem that when writing the name of such a file you have to know how it is going to be used - which is not a very maintainable solution.
Solution:
------------
It was determined that the use of $ in .java file names was not necessary in nashorn and that usage has now been removed -
http://hg.openjdk.java.net/jdk8/tl/diff/5b0b6ef58dbf/common/makefiles/MakeBase.gmk
and revert the subsequent fix-ups done under
http://hg.openjdk.java.net/jdk8/tl/jdk/diff/022cd5adc0fa/makefiles/profile-rtjar-includes.txt
http://hg.openjdk.java.net/jdk8/tl/jdk/diff/ecd33c6ab12f/makefiles/CreateJars.gmk
- relates to
-
JDK-8008977 profiles build broken by Nashorn build changes
-
- Closed
-
-
JDK-8009029 SunEC provider classes ending up in rt.jar after Nashorn build changes
-
- Closed
-
-
JDK-8009379 Remove $ from generated class names.
-
- Closed
-
-
JDK-8008914 Add nashorn to the tl build
-
- Resolved
-