[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: jdiff.sh (BETA)
From: |
Eric Blake |
Subject: |
Re: jdiff.sh (BETA) |
Date: |
Sat, 21 Sep 2002 10:16:26 -0600 |
User-agent: |
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 |
Giannis Georgalis wrote:
Hello again,
After some useful comments and a bug report by Michael Koch, jdiff.sh
0.0.1 (BETA) now works in the following ways:
* Handles interfaces correctly ... Give me some help here; When you
have a public interface do all the methods-fields default to "public"?
I always explicitly declare them "public", but that's not the case in
eg. java.net.SocketOptions (is that a valid declaration?)
(Thanks Michael)
Yes, ALL interface members (fields and abstract methods) are public,
whether the user marked them that way or not, and whether the interface
is public or not.
* Extracts the exceptions (from the source code of eg. GNU classpath)
from javadoc comments and _not_ from the methods (or constructors)
signature. Doing the same for the api documentation, makes it
report (correctly?) both checked and unchecked exceptions.
Unchecked exceptions do not need to be reported. There are several
places where Classpath purposefully omits mentioning unchecked
exceptions in the throws clause, because it is just a waste of .class
file size.
For example, these two declarations are equivalent, but the second
compiles to less space:
void m() throws RuntimeException {}
void m() {}
* It still doesn't handle declarations (in .java source) of the type
"type ID[]", and I did it on purpose because I think declaring it like
this is a bad style as ID is *not* an array of type "type" (like C/C++
arrays,for example), but a *reference* to an array object of type "type".
But If you are *not* in any way willing to declare them as "type[] ID",
I will fix it ...
Yes, it may be bad style, and even worse style is "int m()[]" instead of
"int[] m()", but you should still check it, because it will help us
clean up our bad style.
* It ignores the "native" keyword from the source code.
Good point - whether a method is implemented in Java or natively does
not affect whether the method exists.
Likewise, your code should not worry about the "synchronized" keyword,
on classes or on methods, because different implementations can
successfully synchronize without marking everything in the same manner.
--
This signature intentionally left boring.
Eric Blake address@hidden
BYU student, free software programmer