<Swing Dev> Review request: JDK-8005250 Downgrade normative references to ${java.home}/lib folder from Java client code.

[Alexey Utkin]

The bug description:
     http://bugs.sun.com/view_bug.do?bug_id=8005250

The suggested fix:
     http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8005250/webrev.01/

The specification change:
     
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8005250/specdiff.01/overview-summary.html

Problem:
     As part of the effort to prepare the platform for modules (see 
http://openjdk.java.net/jeps/162) we need to re-examine all normative 
references to files/resources in the ${java.home} directory as these may 
be candidates to be replaced or candidates to move to module-private 
locations in the future.
     The focus of this fix is various client APIs that specify that the 
default values of client properties are loaded from property files in 
${java.home}/lib directory. We need the flexibility to be able to 
re-locate the property files when we move to modules and a module image 
in jdk9.

Solution:
     Change the specification to downgrade normative references to 
${java.home}/lib directory to non-normative status. All references to 
this directory have been removed from external or private client APIs.

Compatibility risk:     minimal
     There is no compatibility risk as the implementation of the 
applicable APIs always call the specialized methods to retrieve the 
values of client properties, and that implementation will continue to 
pre-populate any properties that have been set in the properties files 
in ${java.home}/lib directory. Notes have been added to the class 
summaries of the java.awt.datatransfer.SystemFlavorMap, 
javax.swing.UIManager, javax.sound.midi.MidiSystem, 
javax.sound.sampled.AudioSystem, javax.imageio.spi.IIORegistry APIs to 
state that default values for client properties are read from an 
implementation-specific location, and the location is typically the 
${java.home}/lib directory.

Regards,
-uta