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

[Stefano Mazzocchi]

Jeroen Frijters wrote:
> 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.

I kind of agree with Jeroen: class format validation is a very useful
feature.

On the other hand, what is not nice is that japize doesn't signal the
error but it just signals that the method is not there.

So, if we want japi to act as a bytecode validator, we should allow
errors to be treated (and shown) differently.

thoughts?

-- 
Stefano.