harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: [classlib]Make harmony's modularity better
Date Wed, 17 Dec 2008 23:56:12 GMT
On Wed, Dec 17, 2008 at 9:43 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Jack Cai wrote:
>> I have another try following Alex's idea. See the patch here [1].
>
> Yep, I think that does it!  Thanks Jack.
>
> Tony / Alex, does that look good to you too?

Yeah, looked good to me. I'm embarrased that it's way simpler than my
idea and easier to implement, too :-)

> I'm still unsure whether to have that catch Throwable as opposed to a
> creating a helper that tests the instanceof without referencing the
> Applet class directly, since the reference to Applet.class in the test
> will cause the applet.jar to be loaded if it is available.

Actually, I think that will be OK. Failures should be as late as
possible in the JVM - so it should only be if it hits that line that
it will have the issue. True, the class will be loaded into the
constant pool, but since it's not in the signature (and the /3 calls
the internal/4) we don't hit a method with the bad class, so we don't
have to resolve the class.

Even better would be not to refer to the class until it's needed,
though. You could do it by querying the hierarchy of the classes:

if (initializer != null )
{
Array interfaces = initializer.getClass().getInterfaces();
if (interfaces.contains("java.applet.AppletInitializer"))
{...}
}

Having said that, it's probably more performant to do the standard
Java class binding check and catch. (You've got to follow interfaces
recursively, really, to make sure that you don't have c > foo
interface > java.applet.AppletInitializer)

With all that said - isn't there some JavaBean code that does this for
calculating recursive property types for the default BeanInfo that we
could use?

Alex

Mime
View raw message