Re: [Java] Function Binding Redux (long post)

on Fri Jul 20 2007, John Moeller <fishcorn-AT-gmail.com> wrote:

> 2a. Generate a Java source file where the methods wrap the function 
> dispatcher.
>
> Not entirely appealing, because it's a build-time solution, not a 
> runtime solution.  

Not necessarily.  If Java can compile and load source files
dynamically (it can, can't it?), I don't see any reason why you can't
generate this source file on demand at runtime.  I guess that's where
the "special class loader" you meantion below would come in.

> But it would enable the use of "natural" syntax very easily.
>
> 2b. Generate the same, except directly in bytecode, and put the result 
> in a class file.
>
> Same advantages as (2a), except without the compile time, but the 
> drawback that we'd have to maintain bytecode generation (probably not a 
> big deal, though).

Agreed, probably not a big deal at all.  I'd be surprised if details
of the function-calling convention ever changed enough to require
maintenance.

> 3.  Do the same as (2b), but load the class at runtime with a
> special class loader.  This is (from what I understand) the crux of
> Rene's idea, and the most initially appealing.
>
> I've been trying to think of ways to make this work, but there are some 
> major compromises:
>
>    1.  Without wrangling class loaders at startup, 

I don't know what you mean, or anything about what's involved here.
That's not a criticism; I'm just letting you know I'm not even a Java
n00b, much less an Xpert.

>        it's impossible to use the class name in source code without
>        it having been loaded first.  This means that you have to
>        load the class, then use it through its Class interface.
>        This means using reflection, which is an entirely procedural
>        API.  It's pretty gross.  If the class can implement an
>        interface though, (I'm referring to the Java kind of
>        interface), then you could just cast it, because a class can
>        implement an interface that's already been loaded by another
>        class loader with no problem.

I don't see how the "implement an interface" thing helps you very
much.  You'd still need to generate Java code for the interface,
right?

>    2.  You could wrangle class loaders at startup, or some major
>        milestone in your program's execution.  That is, you could come up
>        with a "launcher" that set up the class loader chain, and invoke
>        "main" from your main app class.  This would enable you to use
>        your generated classes naturally, because the main class would be
>        loaded with the special class loader in the loader chain, and all
>        of its dependent classes (i.e., the rest of the program) would be
>        loaded with the same loader chain.

I'm way out of my depth now.

>        Unfortunately, this means that you can't have your app classes
>        visible from the launcher's classpath.  You actually have to take
>        steps to *prevent* the default loaders from finding your app
>        classes.  This is inconvenient, and may simply be impossible for
>        some users.  They may not have control over how their classes are
>        started.
>
>    3.  Hack the JVM startup so that it uses a different class loader.
>        This still has the problem of accessibility, and probably the
>        problem of portability, because not all JVMs may implement an app
>        class loader override.
>
> I thought of another alternative.  If we're willing to compromise on
> natural syntax,

I don't recommend that.

> we can go one better than compromise (1) above.  I got this idea
> from looking at the Java scripting API.  In the scripting API, you
> can pass an interface class to your script object, and have it
> return an object defined in the script as an instance of the
> interface.
>
> We could do something like this:
>
>    Instance x = new Instance("X", ctorArg1, ctorArg2);
>    Runnable r = x.asInterface(Runnable.class);
>
>    new Thread(r).start();
>
> or even:
>
>    WrappedClass x = new WrappedClass("X");
>    Runnable r = x.asInterface(Runnable.class, ctorArg1, ctorArg2);
>
>    new Thread(r).start();

Is this just a compromise on the construction syntax, or something
more/worse?

> This would presumably throw an exception if there wasn't a function void 
> run() that could be dispatched to.
>
> It seems that it should be possible to generate a class that
> implements an interface on the fly (I think that implemented
> interfaces are just markers in the class data anyway).
>
> What do you think?

Too ignorant to have much of an opinion; I hope someone with an iota
of Java-fu will have some useful feedback for you.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/