On Sun, 2006-03-19 at 19:58 -0500, Stuart Ballard wrote: > On 3/19/06, Andrew John Hughes <gnu_andrew@xxxxxxxxxxxxxx> wrote: > > I think the interface problem you mention is the most obvious, but I > > think this should be solvable by declaring the class abstract (which > > shows up in JAPI too). > > It's a shame that we can't use annotations on the trunk; it wouldn't > be hard to have Japi pick up an annotation which marked stub methods > and flag any such methods as errors. I agree. Of course, we also really need a command-line tool for them too. > > What's the status on the whole ecj-as-gcc-frontend thing? Since gcj > and ecj are pretty much the only maintained Free java compilers at > this point, seems to me that's the only blocker to making the generics > branch the primary development trunk and adopting the new language > features wholesale... > I'd be interested to know this, especially as to whether this can be done before GPLv3 becomes a reality. > I also remember hearing about some stub methods in Swing which are > currently defined as calling super.whatever(), which will eventually > need to be overridden but currently other features in the class do > work. If it's the one I'm thinking of, it's fixed in gcj 4 which we now require. > Declaring the class as abstract would break working > functionality; deleting the stub wouldn't have any effect on the japi > results because the inherited method would be picked up. > I'm only thinking about this for interfaces, where e.g. part of the interface is implemented, the rest is stubbed. You remove the stubs, and declare the rest abstract so it will at least compile (and be comparable). Yes, it will break functionality, but that's an incentive to fix the rest of it... Presumably, japi would pick that up as a concrete/abstract difference and for each of the missing methods. For anything else, they should be removed. > As far as I can figure out, an annotation is pretty much the only way > to get these kinds of methods to get flagged by Japi. > We could do this on generics. I already find 1.5 comparisons pretty useless for HEAD, because it will never be able to implement all the language features (and will have differences). > Stuart. > > -- > http://sab39.dev.netreach.com/ > -- Andrew :-) Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments. See http://www.fsf.org/philosophy/no-word-attachments.html If you use Microsoft Office, support movement towards the end of vendor lock-in: http://opendocumentfellowship.org/petition/ "Value your freedom, or you will lose it, teaches history. `Don't bother us with politics' respond those who don't want to learn." -- Richard Stallman Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html public class gcj extends Freedom implements Java { ... } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://developer.classpath.org/pipermail/classpath/attachments/20060320/9a32e11d/attachment.pgp
