Looking over the new patches archive (thanks Mark!) I saw a thread between Wolfgang and Tom which betrayed a general incomplete understanding about Japi that I thought I'd address here since it's something of a Japi FAQ.
The specific question was about whether japi ought to have reported that javax.print.SimpleDoc wasn't final when it should have been. The answer is, it *does* report that, but not in the place you might expect. The normal japi results pages, h-jdk1x-classpath.html, consist only of problems that cause programs written against that jdk version to fail against classpath. That is to say, things that break binary *backward* compatibility with that jdk version. A detailed list is at http://www.kaffe.org/~stuart/japi/jcompat.txt (This list hasn't been updated with what's considered legal or illegal for the new 1.5 language features but it's a useful starting point at least, and you can probably use it as a basis for an educated guess as to what decision japi would make on any 1.5 features too) Note in particular that for classes, "final->nonfinal" is considered legal. Short of using reflection to inspect the class and *deliberately* failing, there's no code that could be written against a final class that would fail if that class became nonfinal. So the error doesn't show up in this report. But there's also another report: http://www.kaffe.org/~stuart/japi/htmlout/h-classpath-jdk15.html This report shows things that break compatibility in the *opposite* direction, and if you look at http://www.kaffe.org/~stuart/japi/htmlout/h-classpath-jdk15.html#err_bad_javax_print you'll see that SimpleDoc being inappropriately nonfinal *does* show up there (along with all its methods, since the methods of a final class are final by implication). This report indicates cases where code written against Classpath might break against the JDK. I think it's entirely appropriate that the majority of our effort goes into fixing japi problems in the jdk1x-classpath reports, because they're the ones that actually might break compatibility for applications that are out there (let's face it, it's unlikely that any application today is written against Classpath and never tested against any JDK, and if there *are* any apps like that, they probably explicitly don't care about running on a JDK). But for perfect compatibility, we should be aiming to get the classpath-jdk15 report down to zero errors too. Most of these errors are much easier to fix than the corresponding error in the other direction would be, too :) Hope this clarifies things for future reference. Stuart. -- http://sab39.dev.netreach.com/ _______________________________________________ Classpath mailing list Classpath@gnu.org http://developer.classpath.org/mailman/listinfo/classpath
