RFR: 7141675 Fix jcheck issues in .m sources

Daniel D. Daugherty daniel.daugherty at oracle.com
Wed Feb 1 07:17:46 PST 2012

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... :-)


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