Hello, Anthony, Artem. >> 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. And we can add a system property to set an alternative flavormap.properties file later if someone would request such a feature.
> 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. And also about changing flavormap.properties format) The current fix is all the work in datatransfer modularization that needs a CCC. All changes seem related, so I would prefer no to split it further, because it would make it harder to track when all the peaces are integrated to jake repository to continue the work. And it would need more CCC requests which consume time. Thank you. With best regards. Petr. On 20 июня 2014 г., at 15:29, Artem Ananiev <artem.anan...@oracle.com> wrote: > > On 6/20/2014 3:19 PM, Anthony Petrov wrote: >> Hi Petr, >> >> 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. > > 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. > > 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.bate...@oracle.com >>> <mailto: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. 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. >>>
