2009/7/28 Jesse Wilson <jessewil...@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
