Re: japi and public references to non-public types

[Stuart Ballard]

(oops, forgot to CC the list first try - thanks for catching that, Jeroen)

On 10/5/05, Jeroen Frijters <address@hidden> 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/