Tony Wu wrote:
On Thu, Dec 18, 2008 at 5:43 AM, Tim Ellison <[email protected]> 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?
I'm happy with this patch. Thanks Jack.
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.
What we need is a performant version of something like ...
boolean instanceOf(Object obj, String typeName)
No more ideas, seem we have to chose between these,
1. try/catch
2. reflection
Is this dependency problem a common case or just for beans module? If it
a common case, I think we may should find a better way to resolve it. If
not, I suggest to create a helper class to do these trick things.
The former has more overhead whereas the later has less compiler checking.
Regards,
Tim
[1]
https://issues.apache.org/jira/secure/attachment/12396303/HARMONY-6050_Jack.diff
2008/12/17 Tim Ellison <[email protected]>
Alex Blewitt wrote:
But the solution would be to do:
Beans. instantiate/2 -> Beans. instantiate/3
Beans. instantiate/3 (does the work)
Beans. instantiate/4 -> Beans. instantiate/3 (and calls the applet
initialiser)
I've attached such a proposed change to
https://issues.apache.org/jira/browse/HARMONY-6050. Sorry I can't
compile/test in-situ, but if someone can give that a go and run
associated tests, that would be great.
I took another look, and it isn't so simple. While we know the caller
to the instantiate/4 method has got applet loaded, we also have to deal
with the case where instantiate/3 loads a bean of type Applet.
We should not inadvertently load applet.jar by deferring /3 to /4, but
we still need to cope with potentially loading it for the /3 case. If
you are still following me...
Regards,
Tim
--
Best Regards,
Regis.
