Java Needs an Opt-Out of Static Typing

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)
It's like XML, but you can store source code in it.
I've, step-by-step, been explaining the history and character of the high level logic problem and the solution being developed in the HLL Open-Source Project. More than once, I've mentioned the enormous advantages of modern computer languages over what was available twenty-five years ago when the first few of my brain-cells became stimulated by the question. For more than one reason, I've selected Java for the implementation language. (One that I'll note is that it's currently the most popular application language on the planet, matching the intent that HLL should be a production tool, rather than an interesting curiosity.)

One great issue remains, however. Java is a statically-typed language. Why is that a problem, you might ask if you haven't yet seen it as a problem yourself? Let me take an example. I have mentioned JBoss Rules (also known as Drools) quite often in my articles. In The Ghosts in My Machine: Chapter 2 I mentioned how it overcame a critical problem in the ancient art of rule-processing.

Popular rule-based expert system tools had been built as stand-alone products to support only rule-processing, and could not be integrated with other programs and were not extensible with other programs. The JBoss rule processing system mentioned in chapter 1 deals with this problem directly. The rule-processing software is built in Java, carrying with it the characteristics of the underlying language. A rule-process can be initiated from another program and program objects can be referenced directly in rules. This allows programmers much greater flexibility to fashion their own hard-coded relationships between rules and other components in each application.

In HLL, I am about to create a similar openness in the configuration system, and that will be carried over into a simple rule-processing and planning system directly supported by the HLL core (with the option to use a more sophisticated systems such as JBoss Rules). Application developers will be able to specify their own components in XML files that the HLL processor will handle generically.

In the prototype, developers could add their own components to the core – which is very much like saying they can add whatever they want by changing the core source code. (Well, du-uh!) Because I want to maintain the concept of the core, a next sort of “bottom-uppish” evolutionary step is to predefine another package specifically for application components (that may in turn initiate other systems that HLL doesn't know about). The HLL core processing components that deal with configurable application components will have all members of the predefined “application package” imported by using a wild card (import nu.isr.hll.light.application.*;). Application developers will be able to put initiator components in the application package, and the HLL core will process them in whatever way is described in (XML) configuration files.

One HLL unit can also contact another HLL unit with a request to have one of its application components executed, with results returned. But I dream other dreams. I would like to build dynamic HLL applications that can process components that were not defined at compile-time. I'd even like to be able to fetch objects from somewhere out in the WWW that a particular HLL unit has never heard of and run them locally. What I'd like is a LoadUndefinedClass class with methods for calling methods and accessing public fields.

And really, I can almost do this with generics. I can almost build the LoadUndefinedClass class using reflection. Almost isn't good enough, of course. No matter what trick I play on the compiler, the run-time engine is going to throw an error if there's no predefined class for it to refer to.

So, what's stopping us from getting a LoadUndefinedClass class? Purity of the language? Fear that Java programmers might write programs that don't work? Come-on!!!

UPDATE (Sept. 6, 2011) InvokeDynamic class : New JDK 7 Feature: Support for Dynamically Typed Languages in the Java Virtual Machine
.