harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib]Make harmony's modularity better
Date Mon, 15 Dec 2008 12:16:29 GMT
Alexei Fedotov wrote:
> I like when a compiler does a hard job of type and method checking.
> Why should we use reflection and hide applet dependency, hence
> prohibiting the compiler to check things for us?

Right.

Why not make use of Java's dynamic loading ... something like this
(untested):

Index: src/main/java/java/beans/Beans.java
===================================================================
--- src/main/java/java/beans/Beans.java	(revision 725055)
+++ src/main/java/java/beans/Beans.java	(working copy)
@@ -198,7 +198,13 @@

 		if (result != null) {
 			// Applet specific initialization
-			if (result instanceof Applet) {
+		    boolean isApplet = false;
+		    try {
+		        isApplet = result instanceof Applet;
+		    } catch (ClassNotFoundException e) {
+		        // Ignored - leave isApplet as false.
+		    }
+			if (isApplet) {
 				appletLoaded((Applet) result, loader, beanName, context,
 						initializer, deserialized);
 			}


Regards,
Tim

> If this was C, I'd made a common header describing initialization for
> two modules.
> 
> Thanks.
> 
> On Mon, Dec 15, 2008 at 2:35 PM, Sian January
> <sianjanuary@googlemail.com> wrote:
>> Hi Tony,
>>
>> I think it would be very good if we could minimise unnecessary
>> dependencies between Harmony modules.  I would definitely like to get
>> involved with this.
>>
>> For the specific example, don't forget that Applet is not final so
>> could be subclassed, in which case class.getName() would return
>> something else.  However you should still be able to do it with
>> refection, (e.g. something like
>> Class.forName("java.applet.Applet").cast(result))
>>
>> Thanks,
>>
>> Sian
>>
>>
>> 2008/12/15 Tony Wu <wuyuehao@gmail.com>:
>>> Hi, all
>>>
>>> Just came across a problem. when I was running beans without the
>>> applet.jar in classpath, the jre throws "NoClassFoundExcetipn: Applet"
>>> and exit even the bean class I was operating was not an applet. I did
>>> a quick look into the Beans.java, there are some code  for applet
>>> specific initialization,
>>>
>>> if (result != null) {
>>>                        // Applet specific initialization
>>>                        if (result instanceof Applet) {
>>>                                appletLoaded((Applet) result, loader, beanName,
context,
>>>                                                initializer, deserialized);
>>>                        }
>>>                        if (null != context) {
>>>                                context.add(result);
>>>                        }
>>>                }
>>>
>>> I think at least we can make some change to the the line "result
>>> instanceof Applet", such as getClass.getName.equals to avoid this
>>> unexpected exit.
>>> Furthermore, I just simply deleted the dependencies to some non-luni
>>> classes in the manifest files. By tracing these compiler errors in
>>> eclipse, I found there are some similiar cases in beans and other
>>> modules as well, I'm going to tidy up these code and make our
>>> modularity better.
>>>
>>> It is welcome if anyone has interest on this task and would like to help.
>>> --
>>> Tony Wu
>>> China Software Development Lab, IBM
>>>
>>
>>
>> --
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>
> 
> 
> 

Mime
View raw message