Details
-
Bug
-
Resolution: Unresolved
-
P3
-
None
-
None
-
None
Description
ICC_Profile is a very old API.
getInstance is specified as searching every element of java.class.path for the location of a profile file.
https://docs.oracle.com/javase/9/docs/api/java/awt/color/ICC_Profile.html#getInstance-java.lang.String-
This API was never migrated for java.nio filesystems or jdk9 modules.
It's not clear why it looks in java.class.path elements when they are directories, but not when they are jar files. Changing the packaging of code (directory -> jar file -> module) should not affect its behavior.
We care about this at Google because we use very long classpaths with slow FUSE filesystems, causing almost-always-failing ICC_Profile lookup to be a significant part of Java program startup (while providing very little value). We have a local patch to search instead using
ClassLoader.getSystemClassLoader().getResources(fileName)
which allows our custom system classloader to optimize searching in large classpaths.
getInstance is specified as searching every element of java.class.path for the location of a profile file.
https://docs.oracle.com/javase/9/docs/api/java/awt/color/ICC_Profile.html#getInstance-java.lang.String-
This API was never migrated for java.nio filesystems or jdk9 modules.
It's not clear why it looks in java.class.path elements when they are directories, but not when they are jar files. Changing the packaging of code (directory -> jar file -> module) should not affect its behavior.
We care about this at Google because we use very long classpaths with slow FUSE filesystems, causing almost-always-failing ICC_Profile lookup to be a significant part of Java program startup (while providing very little value). We have a local patch to search instead using
ClassLoader.getSystemClassLoader().getResources(fileName)
which allows our custom system classloader to optimize searching in large classpaths.