Re: Coding style etc
Bryce McKinlay ([EMAIL PROTECTED]) wrote: gcj cannot yet compile classpath from source code, because it cannot handle inner or anonymous classes. Work on these and other "JDK-1.1" features is in progress. In the mean time, gcj should be able to compile most of classpath with the aid of an intermediate bytecode compiler (ie Jikes). This is interesting. When does gjc plan to support inner classes? These are absolutely needed to implement parts of the API. 1. We need to change classpath code that use anonymous classes (eg some of the Collections Iterators) in order to integrate it with gcj. 2. We need to wait until gcj supports the required 1.1 features at the source level. 3. We need to modify the libgcj build process to use an intermediate bytecode compiler. Probibly 3 is the most attractive option, at least as an interim solution. I agree. It might be nice to be able to specify a compiler to use when building the Java parts of gjc anyway. BTW - Will I need to sign another copyright assignment form in order to contribute to classpath? I have already done an FSF one for gcc stuff, and a Cygnus one for libgcj. Paul Fisher ([EMAIL PROTECTED]) is the one to contact about this. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
Re: Coding style etc
Aaron wrote: This is interesting. When does gjc plan to support inner classes? These are absolutely needed to implement parts of the API. The work is going on right now. It won't be too much longer. AG -- Anthony Green Cygnus Solutions Sunnyvale, California
Re: Coding style etc
[ Resending this because it got lost last time? ] Jochen Hoenicke wrote: If there is a code-formatting tool I don't see a reason why we shouldn't convert. We should make sure that nobody has pending changes to that class before converting them, though. Great - I will experiment with the various code formatting tools and report back what I come up with. There is currently no document describing the libgcj coding style, but I think it would be good to have one. If I get time I'll see if I cant put something together. Another thing to consider are the copyright notices at the beginning of the file. We should probably make a template of how they should look now and use that for all files. Currently classpath has several different styles of copyright headers. Personally those huge page-long GPL copyright headers also bug me a bit. Its a safety issue, they put stress on my mouse-wheel finger ;-). It would be great if we could just stick to something like: /* Copyright (C) 1999, 2000 Free Software Foundation, Inc. This file is part of Classpath. This software is copyrighted work licensed under the terms of the Classpath License. Please consult the file "CLASSPATH_LICENSE" for details. */ (this is modelled on the Cygnus libgcj header). I don't think that the comments make the code more difficult to read! The only case comments might disturb you, is for simple methods, where the implementation consists of a single line. But if you want to get a overview of the whole class, its much nicer to look at the javadoc generated documentation, than to look at the code. Thats true, but from my perspective when I'm looking at source code I usually want to know HOW something is implemented, or to establish why I'm seeing a particular erronous behaviour. Its easier and quicker to get a nice overview of how a class is implemented by not having to wade through a few screens of javadoc that is only a reproduction of what I already have open in Netscape in a different window, or in a java book in front of me. Javadoc comments also draw my attention away from the *important* comments - those which document particular implementation details, known problems, etc. AFAIK, Classpath wants to generate its own documentation. The comments are also useful to document special things (e.g, that the Vector.copyInto() can throw an ArrayIndexOutOfBoundsException, even if that isn't made explicit in the code). It's of course a lot of work to write comments, and so they sometimes were omitted. Yes - while I *do* see the value in having such documentation (so it can be distributed wherever classpath is distributed without requiring end users to obtain the API documentation from elsewhere), I for one would rather spend my time writing quality code than rehashing API documentation which already exists in five zillion java books and endless free-as-in-beer html documentation. There is also a copyright issue here - how can we write clean-room javadoc comments when the original javadoc was what we based out implentation on in the first place?? regards [ bryce ]
Re: Coding style etc
Mark Wielaard [EMAIL PROTECTED] writes: Yes I would very much like to see one coding style use. It would be nice if old code could be automatically reformatted. And it would probably help the coders if there where syntax files for this style for popular editors. If no one else does, Paul can probably write a lisp reformatter which works within emacs in batch mode to automatically reformat everything. Unless there is a mode in emacs to automatically format my code that way I probably won't do it while writing code but I'll gladly run a program to do it for me when I'm done. This is a much more flexible approach than enforcing any arbitrary, no matter how good, coding style on another person. Brian -- Brian Jones [EMAIL PROTECTED]
Re: Coding style etc
"Bryce" == Bryce McKinlay [EMAIL PROTECTED] writes: If there is a code-formatting tool I don't see a reason why we shouldn't convert. We should make sure that nobody has pending changes to that class before converting them, though. Bryce Great - I will experiment with the various code formatting Bryce tools and report back what I come up with. There is currently Bryce no document describing the libgcj coding style, but I think it Bryce would be good to have one. If I get time I'll see if I cant put Bryce something together. It is basically the GNU C style, extended for C++ and Java, with one exception (there is no space before an open paren for a method call; I personally still don't like this exception, but whatever). FWIW I like the GNU-ish style, but then I've used it for years. I don't feel too strongly about it. What I do feel strongly about is using a relatively small indent step, and not an 8-column tab. I find deeply indented code very hard to read, and write. Bryce There is also a copyright issue here - how can we write Bryce clean-room javadoc comments when the original javadoc was what Bryce we based out implentation on in the first place?? I agree. This might have been our rationale for not writing javadoc comments (I don't know for sure). You might try writing the docs based on the code, but then you run into problems if there are bugs. Ideally the doc comments would follow a specification, but there is no real spec... Tom
Re: Coding style etc
On Dec 22, Bryce McKinlay wrote: One issue I'd like to raise is that of coding style. A nice feature of libgcj is that the code is written fairly consistently, where as classpath varies widely between classes and packages that were written by different authors. Although there is no official GNU coding standard for Java, libgcj is written according to what we think such a standard would look like if it existed. There was a discussion on this list about coding style, some time ago. We decided to use GNU coding style (before both GNU and SUN coding style were allowed), but unfortunately many classes were already written with a different coding style at that time. Should classpath's (and libgcj's?) code should be reformatted to adhere to a common style? This could, of course, be easily done using code-formatting tools, and in most cases the changes would be relatively minor. I do think that it would be a significant advantage to achieve some level of consistency before any serious merging work begins. What are the opinions of the classpath developers on this? If there is a code-formatting tool I don't see a reason why we shouldn't convert. We should make sure that nobody has pending changes to that class before converting them, though. Another thing to consider are the copyright notices at the beginning of the file. We should probably make a template of how they should look now and use that for all files. Currently classpath has several different styles of copyright headers. Also, I notice that many parts of classpath are documented with javadoc-style comments while other parts (and libgcj) leave them out or just have minimal comments. The Java APIs are already extensively documented from a variety of sources, so it can be argued that such API documentation is redundant. Personally I think that large comments make the code a bit harder to read and maintain, but I guess that modern editors can be configured to hide javadoc comments so that perhaps isn't a real issue. It is also good to have a free (as in speech) documentation set. Anyway, this is another style difference between the libgcj and some of the classpath code. I don't think that the comments make the code more difficult to read! The only case comments might disturb you, is for simple methods, where the implementation consists of a single line. But if you want to get a overview of the whole class, its much nicer to look at the javadoc generated documentation, than to look at the code. AFAIK, Classpath wants to generate its own documentation. The comments are also useful to document special things (e.g, that the Vector.copyInto() can throw an ArrayIndexOutOfBoundsException, even if that isn't made explicit in the code). It's of course a lot of work to write comments, and so they sometimes were omitted. Jochen
