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 <[email protected]> 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.
