Hello, Alan. Thank you for the review.
> Do we know if anyone has been editing the file in ${java.home}/lib? I couldn't find any examples on the internet although I've done a very extensive search, so I we could add a property later if someone would request it. With best regards. Petr. On 19 июня 2014 г., at 16:13, Alan Bateman <alan.bate...@oracle.com> wrote: > On 19/06/2014 12:17, Petr Pchelko wrote: >> Hello, >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8047336 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/ >> >> This is another step in datatransfer modularization work. This part of the >> work needs a CCC, so I've moved it out to a separate fix. The CCC will be >> filed once the fix is settled. >> >> Multiple changes are happening here: >> 1. After http://ccc.us.oracle.com/8005250 the flavormap.properties and >> AWT.DnD.flavorMapFileURL Toolkit property was removed from the public API. >> However one mention was forgotten and I'm removing it now, see changes in >> Toolkit.java >> 2. For modules we need to move flavormap.properties out of the jre/lib. I'm >> not sure about the new location. Can I add properties to the >> java.awt.datatransfer package? Wouldn't they be considered public in this >> case? >> 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by the user >> and it's not used by us. So I'm removing it. >> 4. As flavormap.properties is not editable by the user any more, I'm >> changing it's format to get significant simplification of the parsing code. >> >> There's no way left to change the default mappings now, but we have public >> supported API to create new mappings in the Java code. System property could >> be added to provide alternative properties location, but I don't think it's >> required. >> > The dropping of the reference to flavormap.properties from java.awt.Toolkit > looks okay to me. > > I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap (not a > detailed review) and it looks okay. I cannot comment on the changes to format > as I don't know the history in this area to understand the issues around > duplicates. > > On your question about introducing a system property to allow the > configuration be picked up from some other (non-JDK) location then it doesn't > sound like there is a strong case. Do we know if anyone has been editing the > file in ${java.home}/lib? I assume that if there is a strong need then it > could be possible to introducing it in the future without conflicting with > anything that you are doing here. > > -Alan.