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

Anthony Petrov anthony.petrov at oracle.com
Tue Jul 1 18:53:39 UTC 2014

Hi Petr,

The fix looks fine to me. Only one question:

>  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,

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.

More information about the awt-dev mailing list