Re: Thought on future of XMLC

On Thursday 21 November 2002 13:33, David Li wrote:
> How about moving the class generation to runtime. In your reloading
> codes, the elements referred to by the accessor methods are
> synchronized at runtime. The current code generating style is similar
> to the style of BCEL (bcel.sf.net) and this package support
> generating/loading new classes at runtime. This way, the compiler will
> generate only interface for compiling time checking and the impl
> classes will be generated at runtime.

Sounds very interesting. Especially if you think of annonymous implementation 
classes that support a number of predefined "page interfaces". That way, you 
can easily hook components inot a page and don't need to worry about the 
actual implementation - just check if the object returned from the XMLC 
factory supports your component's page interface.

> I am using BCEL to support loading of uncompiled new files and it's
> getting close to working now. I have to rewrite much of the
> ClassGenerator in term of BCEL, thu.

Hmmm - I did the same once using a more "traditional" approach - generate a 
Java file, run javac/jikes on it and then do a Class.forName() (basically, 
call the existing XMLC from a running application). Works pretty well and 
does not require changing XMLC. Of course, using BCEL eliminates the need for 
having .java and .class files in the fielsystem at all, but is this really 
that much of a benefit?

Regards,

Richard
-- 
Richard Kunze 

[ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1
http://www.tivano.de, kunze@xxxxxxxxx