<AWT Dev> [9] Review Request: 8047336 Read flavormap.properties as resource

Anthony Petrov anthony.petrov at oracle.com
Fri Jun 20 11:37:16 UTC 2014

On 6/20/2014 3:29 PM, Artem Ananiev wrote:
> On 6/20/2014 3:19 PM, Anthony Petrov wrote:
>> I ran the following query:
>> https://www.google.com/#q=custom+flavormap.properties
>> and the search yielded the following forum thread:
>> https://community.oracle.com/thread/1293314?start=0&tstart=0
>> where developers seem to suggest they do edit the
>> $JDKHOME/jre/lib/flavormap.properties file sometimes.
>> Do we officially declare that we drop support for this possibility?
> This possibility will be dropped regardless of the current Petr's fix,
> since there will be no single "jre" folder in jigsaw world. Probably,
> some other mechanism to customize files like flavormap.properties or
> logging.properties will be introduced.

Can we file an RFE for this feature now please?

> BTW, the current fix is not about flavormap.properties on its own, but
> about removing AWT.DnD.flavorMapFileURL toolkit property. I would
> suggest to push this change as a separate bug fix, not as a part of
> 8047336.


best regards,

> Thanks,
> Artem
>> --
>> best regards,
>> Anthony
>> On 6/19/2014 4:24 PM, Petr Pchelko wrote:
>>> 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.Bateman at oracle.com
>>> <mailto:Alan.Bateman at 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. Afterhttp://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.

More information about the awt-dev mailing list