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

Petr Pchelko petr.pchelko at oracle.com
Mon Jul 14 14:23:55 UTC 2014

Hello, AWT Team.

My apologies, but I've found a problem in the AWT part of this fix and so I need one more review iteration.

The new version is located here: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.02/
The only changes comparing to the previous approved version are in SystemFlavorMap.

I've realized that we cannot use Properties to load the flavormap.properties file because Properties doesn't preserve the original order of keys. 
And it's important, because natives that are found in the file first are treated as more important than natives in the end of the file. 
So I've implemented a custom parser for the properties file (see lines 233-243)

Thank you.
With best regards. Petr.

On 10 июля 2014 г., at 20:22, Mike Duigou <mike.duigou at oracle.com> wrote:

> The makefile changes look fine to me. (The use of OPENJDK as part of the variable names seems excessive but that's not something your patch adds or changes)
> Mike
> On Jul 9 2014, at 23:55 , Petr Pchelko <petr.pchelko at oracle.com> wrote:
>> Hello, Build Team.
>> This is a reminder. Could you please review the build part of the following fix:
>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>> Thank you.
>> With best regards. Petr.
>> On 02 июля 2014 г., at 15:13, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>> Thanks. Note that your email editor messed up the HTML part of the email (see below a text-only quote), so here's the correct link to the webrev:
>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>> The fix looks fine to me.
>>> --
>>> best regards,
>>> Anthony
>>> On 7/2/2014 3:10 PM, Petr Pchelko wrote:
>>>> Hello, Anthony, Alan.
>>>> Thank you for the review, the new version is located here:
>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>>>> I've changed the code to throw an InternalError if we cannot read
>>>> properties.
>>>> Once I get feedback from the build team - I'll push this fix.
>>>> With best regards. Petr.
>>>> On 02 июля 2014 г., at 13:52, Alan Bateman <Alan.Bateman at oracle.com
>>>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>>>> On 01/07/2014 09:35, 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/
>>>>>> <http://cr.openjdk.java.net/%7Epchelko/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?)
>>>>> I think this looks okay. I see Anthony's mail asking about the warning
>>>>> message and whether it should the print stack trace. I just wonder if
>>>>> it might be saner to just throw InternalError here. It throws
>>>>> InternalError if flavormap.properties is missing and it might be
>>>>> consistent to do the same when the file is corrupt or can't be parsed
>>>>> as a properties file.
>>>>> -Alan.

More information about the awt-dev mailing list