Paul Hammant's Blog: Can the next big language drop public static void main(String[] args) please?

Java and C# support main as an entry point for applications. The static nature of this, and the fact that it is not subject to an interface contract, often leads applications developed for this entry point to not be components. As you know I'm chasing a component nirvana.

A few years ago when we started working on Jesktop, we noted that many OSS applications were too wedded to their main methods to be easily usable in the Jesktop platform. Forking the app, and a few refactorings made things possible in most cases, but quite often the original coder was unwilling to take back the changes, as they were simply unconvinced of the elegance of untangling the app from its main method.

More recently, having been aware of James Strachan's Groovy from its earliest conception, I rolled up my sleeves to make the only contribution to that project that the team had subtly missed - they had honored the prevailing vision of the main method in Groovy classes. The logical conclusion, in this constructor dependency injector age was that an array of string args are best passed in through constructor. All the same functionality can happen for the args, but the component may also have more constructors that are alternate and more strongly typed was of instantiating a component. The groovy team suggested that an invisible main method could also be created so that a compile class is still interoperable with Java.exe.

Java.exe is a poor container. Its presence reminds us that mainable apps do run inside a container. It may well be very subtle, but it is still a container for launching of apps. Prior to JDK 1.5, it was a container that could only launch one app at a time. Its modus operandus for setting of context for its hosted components is via some static (spit) properties. Thus my personal future-language nirvana, is for its command-line component to be something like:-

public class SpellChecker {

// use from command line
public SpellChecker(ApplicationContext appContext, String[] args) {
// etc
}

// embedded use
public SpellChecker(Dictionary dict) {
this.dict = dict;
// etc
}

// embedded use, with written in documentation American English dictionary.
public SpellChecker() {
this.dict = new AmericanEnglishDictionary();
// etc
}
// method etc
}

Anyway, returning to Jesktop, passing in dependencies to graphical components via ctor, is proving quite neat. At the moment, it is for exposed parts of the kernel (double clicking on a Jesktop jar file in a arbitrary explorer-like tool should yield a action of launch) only. A subsequent phase will allow hot publication and subscription to services inside the app.