Andrew John Hughes wrote: > On 21 Mar 2006 17:36:52 -0700 > Tom Tromey <tromey@xxxxxxxxxx> wrote: > > >>>>>>>"Tom" == Tom Tromey <tromey@xxxxxxxxxx> writes: >> >>>>>>>"Stuart" == Stuart Ballard <stuart.a.ballard@xxxxxxxxx> writes: >> >>Stuart> I believe Classpath already has an unchecked NotImplementedException >>Stuart> so that's what I used. Any method marked as "throws >>Stuart> NotImplementedException" will be reported by Japi as "not implemented >>Stuart> in Classpath", in the same category as "missing" errors. >> >>Tom> This is a nice hack, I like it. >> >>I started implementing this. >> >>The appended patch just scratches the surface. I got a bit depressed >>writing this patch -- there are that many stubs. Ugh :-( >> > > Are all of these appropriate for an exception flag? Maybe some should > be ripped out all together... As it stands, methods with just the exception > still have the bigger problem in that they will silently fail (I see lots > of 'return null's) and for someone who knows nothing about JAPI, this won't > help. It is not really possible to decide what to rip out. Distributions already might depend on several stubs for compilation of libraries. Keep in mind that programs running on free runtimes using these libraries may not call these stub methods. But without getting the library compiled with free runtimes we cannot distribute it and hence not the program. So lets flag them and start work on getting them implemented. Thats my point of view as a debian java packager. Everything else might require to remove packages from the distribution or move them back to contrib section without a real (functionality) reason. Wolfgang
