Re: Thought on future of XMLC

On Thursday, Nov 21, 2002, at 21:01 Asia/Shanghai, Richard Kunze wrote:

> 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.

That's a possibility. I am doing this mostly for dynamically loading of 
newly added pages to the system.

This would be useful for one of my other projects, a scripting 
framework for XMLC. I did a BSF (IBM's Bean Scripting Framework) that 
add JavaScript and TCL scripting to Enhydra. This way, the application 
can be changed rapidly without compiling/loading of the applications.

> > 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?

Well... It sounds cool? ;)

I think the approach is the same. However, eliminating the need for the 
filesystem could be a good thing, especially used in a products. Less 
supporting harsh.

David