Re: [Japi] RuntimeException on the latest japitools against BEA JRockit1.5

[Stuart Ballard]

On 11/8/06, Jeroen Frijters <address@hidden> wrote:
> Now the question is how do we handle this. Obviously we don't really
> care about such problems in proprietary runtimes, but if either
> Classpath or Harmony would have this type of "bug", I'd like to know so
> that we can fix the compiler or class file post processor that caused
> it.

I wonder if there's a way in ClassFile.forName() to recognize a
corrupt class and set a flag indicating that it's corrupt, but still
return an object representing whatever info *could* be obtained. In
practice we *know* we don't care about Finalizer$1 because it's an
anonymous class and can't possibly be public - as soon as Japize got a
result back from forName() it'd be thrown away when the modifiers
indicated it isn't public or protected anyway.

Alternatively could ClassFile be made to load information lazily
perhaps? That might improve memory usage and performance also, if
nonpublic classes could be discarded without trying to determine
anything about their methods or fields. I'm not sure that would help
in this case though as I'm not sure whether the enclosing class is
needed to get even the modifiers correct. But if the throw could be
deferred to after the point when Japize has already decided it doesn't
care, that doesn't do any harm at all and avoids this kind of error.

Stuart.
--
http://sab39.dev.netreach.com/