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

[Anthony Petrov]

Hi Petr,

The fix looks fine to me. Only one question:

src/share/classes/java/awt/datatransfer/SystemFlavorMap.java
>  234         } catch (IOException e) {
>  235             System.err.println("Warning reading flavor mapping: " + e.getMessage());

Is there a reason to hide the stack trace of the exception? Why wouldn't 
a simple call to e.printStackTrace() work? Or why not to throw an 
InternalError(e) in this case? We already throw it at line 228 if the 
resource cannot be open.

--
best regards,
Anthony

On 7/1/2014 12:35 PM, Petr Pchelko wrote:
> Hello,
>
> The changes in the public API have been approved, so let me continue the
> review process.
>
> For your convenience:
> The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
> The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>
> Until now we've been discussing an abstract question of moving the
> properties to a different location and agreed that it's possible.
> Now it's time for an official code review. Could someone please make one?
>
> Also some feedback from the build team is still required. Could someone
> from the build team review this fix please?
> (The question is that I've made a separate explicit rule for
> flavormap.properties file. If I add it to COPY_PATTERNS than the solaris
> version get's copied on Mac. Is that a bug in the build system? Is my
> current solution good enough?)
>
> Thank you.
> With best regards. Petr.
>
> On 20 июня 2014 г., at 15:50, Alan Bateman <Alan.Bateman at oracle.com
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>> On 20/06/2014 12:41, Petr Pchelko wrote:
>>> 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.
>>>
>> The forum post looks like is from 2001. If there doesn't appear that
>> many developers have resorted to editing that file then I would
>> suggest just going with what you have. If it really becomes necessary
>> to support having configuration elsewhere (not in the JDK image) then
>> I don't think anything that you have now precludes that.
>>
>> -Alan.
>