harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: Avoid reformatting third-party code?
Date Tue, 28 Jul 2009 17:56:31 GMT

In message <a43fbc6a0907280853p51dc62acieaafdc833b8be074@mail.gmail.com>,
Jesse Wilson writes:
> Harmony folks,
> I've started to watch the Harmony commit logs and I saw a commit that
> I disagree with!

Cool.  The more people that do this the better.  Please feel free to
just reply to the commit messsages with your comments (since they have
the dev@ list as the reply-to address).

> I figured that it was a good opportunity for a discussion...

Which commit?  (Are you mistakenly referring to the recent trunk ->
java6 branch merge commit?)

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


If they are genuine improvements, I'm sure the upstream would be happy
to take them.

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

Indeed.  Incidentally, I recently merged the trunk (java5) to the java6
branch.  In doing so, I merge your updated backported code to the java6
branch.  It is my intention to revert the backporting to get the java6
code to have minimal changes from the upstream source over the next
week or two.


View raw message