adopting OpenJDK's coding standard[?]?

adopting OpenJDK's coding standard[?]?

[Andrew Cagney]

Hi,

Since OpenJDK is going to subsume CLASSPATH as the Free Java library, 
and OpenJDK follows Sun/Java coding conventions (sort of mostly :-), I 
can't think of a reason for continuing with the GNU format.  In 
addition, its the format that EMACS already follows; and there should be 
good indentation tools around.  The only -ve is that Eclipse might still 
need to be, er, "tweaked".

Topic for todays meeting.

Would be grandparented until changed.
Re-indentation should be a separate commit.

Andrew

Re: adopting OpenJDK's coding standard[?]?

[Nurdin Premji]

Andrew Cagney wrote:
> Hi,
>
> Since OpenJDK is going to subsume CLASSPATH as the Free Java library, 
> and OpenJDK follows Sun/Java coding conventions (sort of mostly :-), I 
> can't think of a reason for continuing with the GNU format.  In 
> addition, its the format that EMACS already follows; and there should 
> be good indentation tools around.  The only -ve is that Eclipse might 
> still need to be, er, "tweaked".
>
> Topic for todays meeting.
>
> Would be grandparented until changed.
> Re-indentation should be a separate commit.
>
> Andrew
>
I'm all for it. I believe Eclipse's default formatting standard is the 
sun standard, so just deleting the custom formatter spec should work (if 
needed I'm sure there is a sun standard file for eclipse).
As for the "tweaking" the only issue I know about is a possible 
inconsistency between editor tab sizes and formatter tab sizes, so 
eclipse users should check  both these settings to keep them consistent.

<https://bugs.eclipse.org/bugs/show_bug.cgi?id=192511>

Re: adopting OpenJDK's coding standard[?]?

[Adam Jocksch]

Nurdin Premji wrote:
>
> As for the "tweaking" the only issue I know about is a possible 
> inconsistency between editor tab sizes and formatter tab sizes, so 
> eclipse users should check  both these settings to keep them consistent.
>
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=192511>
Hard tabs would avoid this issue, but I guess they aren't en vogue right 
now, are they :)

Adam

Re: adopting OpenJDK's coding standard[?]?

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

Hi,

On Wed, 2007-06-13 at 09:09 -0400, Andrew Cagney wrote:
> Since OpenJDK is going to subsume CLASSPATH as the Free Java library, 
> and OpenJDK follows Sun/Java coding conventions (sort of mostly :-), I 
> can't think of a reason for continuing with the GNU format.  In 
> addition, its the format that EMACS already follows; and there should be 
> good indentation tools around.  The only -ve is that Eclipse might still 
> need to be, er, "tweaked".
> 
> Topic for todays meeting.

As I said in the meeting, but I didn't see the minutes yet, I think
changing coding conventions is a bad idea. It is basically a bikeshed
discussion waiting to happen [1] and everybody can come up with good
arguments for or against any style. We have a Frysk style now and I
would like to just stick with it instead of randomly changing it every
so often.

Just to insert my own bikeshed arguments:

- I like the project to have one consistent style. Switching between
styles just because one part is written in C, C++ or Java doesn't make
sense to me.
- We aren't based on OpenJDK, we use gcj and will for a time unless
someone starts adding CNI support to OpenJDK or rewrite all our current
wrappers and native code to support JNI (which will require analysis of
performance impacts again since JNI and CNI have very different
performance characteristics). GCJ obviously also uses GNU style like we
do now.
- And finally I like GNU style a lot better because the start and end of
code blocks are so clear to find, something the proposed Sun coding
style guide completely misses.

Cheers,

Mark

[1] http://www.bikeshed.com/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: adopting OpenJDK's coding standard[?]?

[Andrew Cagney]

But I like my bike shed http://blue.bikeshed.com/