RFR: 7141675 Fix jcheck issues in .m sources

Weijun Wang weijun.wang at oracle.com
Wed Feb 1 18:13:01 PST 2012

Maybe each rule inside jcheck can have a startdate, only changsets after 
that need to be checked. Nobody will try to fake the date, right?


On 02/01/2012 11:17 PM, Daniel D. Daugherty wrote:
> That will be a problem. If jcheck is changed in such a way that
> an already committed changeset would be rejected, then it has
> to be added to the whitelist. Otherwise, a fresh clone will fail
> when jcheck processes the now offending changeset...
> Yes, this implies that jcheck has a scaling problem. As more
> changesets are added to a repo, the more work jcheck has to
> do... eventually all compute cycles will be consumed by
> jcheck... :-)
> Dan
> On 2/1/12 7:44 AM, Michael McMahon wrote:
>> Yes, that could be a problem. I think they will have to be added to
>> the whitelist.
>> - Michael
>> On 01/02/12 13:32, Weijun Wang wrote:
>>> I'm wondering if jcheck is updated to include these .m files, will it
>>> reject the old changesets where the .m files contain trailing
>>> whitespaces? Or, should those changesets be added into the whitelist?
>>> Thanks
>>> Max
>>> On 02/01/2012 08:25 PM, Anthony Petrov wrote:
>>>> Hi Michael,
>>>> The patch looks fine to me. It would be great to update jcheck as well
>>>> so that the formatting requirements be enforced for further putbacks.
>>>> --
>>>> best regards,
>>>> Anthony
>>>> On 2/1/2012 3:56 PM, Michael McMahon wrote:
>>>>> This change is just to fix some white-space/tab problems that crept
>>>>> into
>>>>> some objective C files whose filename (extension .m) is not currently
>>>>> known to jcheck.
>>>>> http://cr.openjdk.java.net/~michaelm/7141675/webrev.1/
>>>>> There is nothing to see in the webrev as white-space diferences are
>>>>> ignored.
>>>>> But the patch shows the actual changes.
>>>>> Thanks
>>>>> Michael.

More information about the macosx-port-dev mailing list