harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew John Hughes <gnu_and...@member.fsf.org>
Subject Re: Avoid reformatting third-party code?
Date Tue, 28 Jul 2009 16:19:00 GMT
2009/7/28 Jesse Wilson <jessewilson@google.com>:
> Harmony folks,
> I've started to watch the Harmony commit logs and I saw a commit that I
> disagree with! I figured that it was a good opportunity for a discussion...
>
> The commit fixed some style problems in the java.util.concurrent package. It
> fixed whitespace problems and Javadoc inconsistencies, replacing
> <tt>Object</tt> with {@code Object}. In general, such changes are
> improvements, but we should make an exception for third-party code. The
> unnecessary deltas will make merging and integrating future changes from
> upstream much more labor intensive. And if it's more difficult to integrate
> patches, we won't do so very frequently!
>
> This advice is from experience. I work on Android's Dalvik classlibraries,
> which is itself downstream of Harmony. We've made a broad exception to our
> project's style guide so we can avoid reformatting code. This saves me a
> significant amount of merging effort.
>
> Thanks!
> Jesse
>

I'd second that.  Merging work is tedious at best without making
things harder by introducing mechanical changes.  Especially with
whitespace changes, these have to be basically reapplied from scratch
to the new source file being merged in.

With GNU Classpath, we keep external sources such as the JSR166
sources physically separate (in external/*) to avoid such occurrences
as best we can.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Mime
View raw message