Re: jdiff.sh (BETA)

[Eric Blake]

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