(oops, forgot to CC the list first try - thanks for catching that, Jeroen) On 10/5/05, Jeroen Frijters <[EMAIL PROTECTED]> wrote: > Mark Wielaard wrote: > > This looks like something the compiler should warn against > > "public/protected field/return with package/private type" > > (inner classes could be private).
I absolutely agree it should be a compiler warning (and as Jeroen's said before, it really should never have been permitted by the language in the first place). Is there a Java equivalent to C#'s FxCop tool? > > I think japi should also warn against it not hide it, except when > > explicitly told to. I'm wondering exactly how to do this. You'd want to warn when this happens in Classpath, I think, but not when it happens in the JDK (unless you're actually testing the JDK for compatibility with something). (Currently I believe Classpath only does it for GridBagLayout, but the zip I was testing against was old). Actually, I think an "API lint" like this is kind of outside the scope of Japitools, or rather, outside the scope of japicompat. Perhaps "japilint" should be a separate tool sharing a lot of code with Japize... any volunteers to write it? :) Obvious things to catch: - This one: accessibility of class / method / field greater than accessibility of its type or arguments or thrown exceptions or type parameter bounds - Blank final serialVersionUID fields - serialVersionUID fields in non-serializable classes - serialVersionUID that's not static final - serialVersionUID in an interface - RCS keywords in public constants :) Anything else? > I agree. We're never going to get a 100% score on Japi anyway [1], so > hiding this stuff doesn't do any good in my opinion. > [1] One example I can think of is the non-constant serialVersionUID > fields in some classes (that compute their serialVersionUID based on > some runtime setting or such) Why would we get japi failures here? As long as we do the same thing the JDK does, japi won't report any errors. This is already the way it works (although I'm thinking about making the error message more accurate; right now it will say "serialVersionUID=0" which isn't quite true). Honestly, I don't see any reason why we shouldn't get to zero japi errors; having a bunch of false positive results just makes it harder to find what the real errors are that need to be fixed, especially once we get to the point where the false positives outnumber the real errors. I honestly believe that's part of why it took so long to get to zero errors against 1.1 - until relatively recently the very few remaining real errors were dwarfed by the false positives caused by later JDK versions being incompatible with 1.1 themselves. The japi report against 1.1 was all but useless until the false positives were removed. If you guys still feel differently then feel free to try to persuade me :) Stuart. -- http://sab39.dev.netreach.com/ -- http://sab39.dev.netreach.com/ _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
