My Digital Neuron

package test;
import java.util.*;

import static test.StaticallyImported.*;

public class Test {

  public static void main(String[] args) {

    //passing Type Argument works fine
    HashMap m1 =
      StaticallyImported.<HashMap>aStaticallyImportedGenericMethod();

    //same thing, with static import syntax: compiler error
    HashMap m2 = <HashMap>aStaticallyImportedGenericMethod();
  }
}

class StaticallyImported {
  static <A extends Map> A aStaticallyImportedGenericMethod() {
    return null;
  }
}

In 1998 Microsoft introduced a variant of Java called Visual J++ that included delegates, basically type-safe function pointers. Anders Hejlsberg was very involved with their development, and he went on to add them to C#.

This occurred against backdrop of a war between Sun and Microsoft, much of it over the non-compliance of the MS Java implementation with Sun’s license terms.

Sun rejected the idea of delegates, and a whitepaper attributed to “The Java Language Team”  [http://java.sun.com/docs/white/delegates.html]  was published justifying this decision on technical grounds, in no uncertain terms. Here the gist of its message:

“The newest version of the Microsoft Visual J++ development environment
supports a language construct called delegates or bound method
references. … It is unlikely that the Java programming language will
ever include this construct. … bound method references are unnecessary
and detrimental to the language…. bound method references are
harmful because they detract from the simplicity of the Java
programming language and the pervasively object-oriented character of
the APIs. “

Java’s Alternative: Interfaces and Inner-classes?

The whitepaper describes what became the “Java-way” of representing pointers to functions

• One interface is defined for each function signature, eg String => Integer
• One inner class adapter is written that implements the interface and bridges the call to one underlying method being invoked.

The problem was, delegates (and similar ideas – functions-as-values, closures, blocks, lamdas) have proven to be a much more flexible and elegant than the Java-way. They are supported in virtually every language to become successful in the last decade. Except  Java, the worlds most popular language, still lacks them, much to many peoples frustration.

So, how did Sun get it wrong? They were presented a working implementation of with what’s now recognized as a good solution, but spurned it in favor of an inferior alternative.

The power of group allegiances to affect human judgment and clear thinking

Anders proposed a good idea for Java, but he worked at Microsoft.  It seemed the Sun-MS rift prevented technical people at Sun seeing, or perhaps admitting, that the delegate concept of a typesafe function-pointer had genuine merit.

The underlying tendency to unconsciously prefer ideas that originate from people in allied groupings, organizations or cultures, regardless of actual content, is very widespread (certainly not confined to Sun, as at minimum it afflicts me too). History is full of examples. While it encourages intra-group harmony and consistency, it interferes with our ability to distinguish truth from untruth, and thus slows our learning and progress, and ultimately, reduces our intelligence.

In this case, Java was a casualty of polarised group-think between two warring corporations.

I eventually want to create a Blog/Wiki hybrid residing at http://www.benhutchison.com A JAMWiki (see below) site is running at the URL now, but it is temporary.

This need drove me to consider Java-based Wiki software that would run on Tomcat.

I installed, configured and tested 3 packages:

• XWiki
• JSPWiki
• JAMWiki

Of the three, JAMWiki seems to be the best, but sadly, still not adequate for my needs. On the plus side, it was easy to install and use for everyday Wiki stuff, and is MediaWiki compatible. Its technology stack is based on Spring 2.5 and JSP, and the code is code is neat and java-doc’ed. The 0.6.7 version tag understates its maturity.

However, when I dug deeper I found that internally, it uses a very old-fashioned DB-centric (anemic) domain model. A fair bit of the business logic is encoded into SQL queries. Plenty of code duplication and verbosity. No ORM. Poorly abstracted – lots of individual servlets take care of rendering particular pages, making the system hard to re-compose or re-configure. Ultimately, dissappointing.

I have used it for a while for http://www.benhutchison.com , but am going to move on once I find/build something better /more flexible.

XWiki has a sizeable community but I found it was too big, heavy and complex for my taste – the 45Mb War consumed masses of memory but was seemed short on useful, useable features.

JSPWiki has amateurish UI & docs (and internal code, I suspect)  – I would advise steering clear of it.

So sadly, I dont know of any Java -based Wiki engine I would recommend right now, if you want a degree of customization.

Parametrizing code with types will be part of almost every future statically typed language. I think any programmer serious about working with static typing needs to have an understanding of the conceptual territory:

• What does Type Variance mean?
• Covariance versus Contravariance
• Definition-site versus Use-site Variance

I recommend Barry Kelly’s post as an nice summary of the issues:

http://barrkel.blogspot.com/2006/07/covariance-and-contravariance-in-net.html

Tomcat has a horrible gotcha around the seemingly simple task of deploying a web-app to the so called “root context”, ie at <hostname>/<webapp>.

Either

1. Define a ROOT.xml context file in conf/Catalina/localhost
2. Name your webapp WAR “ROOT.war” or containing folder “ROOT”

(Note: I mean, literally, it must be named “ROOT”. Case sensitive)

Note that advice given in Tomcat docs and elsewhere on setting the context in <webapp>/META-INF/context.xml can be misleading: you cannot deploy to root context simply by using this setting.

Cause

The path attribute, which configures deployment to root context, is ignored outside conf/server.xml. See the docs for path attribute, especially 2nd paragraph. I think this was introduced with Tomcat 5.5.

Why is this poor design?

Well, it seems to run misdirect the “Convention over Configuration” principle that has proven so powerful in recent years. While inferring the context from the filename is a convention, the principle states that configuration should be optional and when present override the convention. In Tomcat’s case, the configuration (ie a “path” attribute) is silently ignored when specified.

The impact is that you must change your War filename or deployment folder, with resultant impacts on build processes & tools, just to vary its deployment URL – a form of inappropriate coupling. Even though there is a setting defined that would allow the artefact name and deployent URL to be decoupled.

I dont know what they were thinking…

Update: Is Glassfish v2 a better alternative?

July to October 2008, I trialed using Glassfish v2 instead of Tomcat, to run 3 small-medium Java webapps. Glassfish was pretty good, but I am now going back to Tomcat, as it seems the better overall option.

While I found the Glassfish Admin user-interface very convenient, the app-server proved slow and memory hungry compared with Tomcat. I also had problems getting virtual hosting to work properly under Glassfish.

I think the situation could change with Glassfish 3, currently in beta, as it is much more modular and can run webapps in a much more lightweight configuration.

As an undergraduate at Melbourne Uni in the mid 90s, we mainly used C with vi on slow, ugly unix terminals. I thought it sucked.  When Java appeared on my radar in 96 I was in 3rd year, and I immediately jumped ship to get onto a higher-level, OO language. 12 years later, and I’d call myself a “native speaker” – Im familiar with almost every corner (and almost every shortcoming) of the language.

Anyway, Java’s weaknesses are well documented elsewhere, so I wont bore you. Ive been searching for the exit for some years, and have finally found my ticket into the next generation, something to get excited and inspired by, something worth comprehensively rewiring my brain for, something to love. Its Scala.

If at first you dont succeed…

I only got into Scala on my second attempt, and even then, the realisation of how good a programing language it is came only slowly. Now it rushes like a torrent in my head, opening new vistas and resetting expectations about how easy programming should be.

The first time, a year ago, its weird swiss-academic accent put me off; eg the name: type syntax, underscore wildcards._, Bottom Types, and the inability of the Eclipse plugin to auto-import like Java does. “Not for me”, I thought, “too strange and theoretical!”

So I followed Groovy, JRuby, C# and Boo instead. But none of them were right for me. C# and Boo dont run on the JVM. And the weak type systems in Groovy and JRuby is something I cannot comfortably swallow, because deep down I’m convinced types represent a fundamental programming truth, and thus should be modelled by the language.

…try, and try again

So I came back and made a second attempt at Scala. I bought Programming in Scala (which is a great beginner book) and I listened to an inspiring talk by Scala creator Martin Odersky. And gradually, I was able to see beyond the strange accent and appreciate that Scala delivers a cutting-edge, ultra-high-level, performant language thats widely usable in the real world, because its so thouroughly compatible with Java and the JVM.

If you’re considering Scala, realize its a very deep, very intelligently designed language. Like me, you might not grok it without considerable effort… but once you do, the rewards are worth it.

Rodrigo Di Olivera is a powerfully creative man, of relatively few words, who perhaps speaks loudest through the software he creates (including Boo, Prevayler).

Now he’s released a nice piece of programming alchemy: a tool that converts Java into C#.

One day I hope to port my Arcadia RPG engine to Windows Mobile (.NET Compact Framework). I expect this tool has just made that task almost trivial, given that Arcadia makes very few demands of its host environment’s APIs.