[14] RFR(M): 8211723: AppCDS: referring to a jar file in any way other than exactly how it was done during dumping doesn't work

[Calvin Cheung]

RFE: https://bugs.openjdk.java.net/browse/JDK-8211723

webrev: http://cr.openjdk.java.net/~ccheung/8211723/webrev.00/

Currently, the class paths comparison between AppCDS dump time and 
runtime is done via the os::file_name_strncmp() function. It works well 
only for absolute paths. This RFE enhances it by allowing relative path 
and sym link.

Highlight of changes:
- the os::file_name_strncmp() and its usages have been removed;

- a _from_class_path_attr field of type bool has been added to the 
ClassPathZipEntry to indicate if the entry is from the “Class-path” 
attribute of a jar file;

- FileMapInfo::same_files() has been separated into posix (os_posix.cpp) 
and windows (os_windows.cpp) versions.

- checking of the boot and the app class paths have been moved from 
SharedPathsMiscInfo::check() to FileMapInfo::validate_shared_path_table();

- for checking the runtime app class paths against the dump time, 
Arguments::get_appclasspath() is used for getting the runtime app class 
paths and are stored into an array. The array of runtime app class paths 
will be checked against the shared_path from the shared archive one by 
one. If a shared_path is from the “Class-path” attribute of a jar file, 
it will be skipped. The same is being done currently; i.e. we don’t 
expand the class paths obtained from Arguments::get_appclasspath() if 
any of the jar refers to other jars by means of the “Class-path” 
attribute. Some sanity checks including file size and modification time 
is being done currently for all the jars in the shared_path. This 
remains the same with this change.

- boot class paths are being checked in a similar way to app class 
paths. Some specifics such as the notion of “relaxed_check” remains 
unchanged;

- test utilities and new tests.

Testing: tier1 through tier3 on linux, windows, macosx, solaris.

thanks,
Calvin