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

[Jeroen Frijters]

Stuart Ballard wrote:
> 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.

This doesn't really address my main issue though. I *like* the fact that
Japize also acts as a validator of the structure of the class files (and
I also sort of rely on that with ikvm). Now you could certainly argue
that that isn't japize's job (it isn't), but it's a darn nice side
effect.

Regards,
Jeroen