In this article I’ll concentrate on the practical application of the currying.

Let’s start with the quick rough definition: F is a curried function with N arguments when an invokation of it can be transformed to N function invokations and each invokation takes exactly one argument and returns function for the next subsequent call. For those who interested in the formal definition of it here is the wikipedia article.

For instance in javascript a function that computes a sum of two arguments in a curried form can be written as follows:

function add(x) {
    return function (y) {
        return x + y
    }
}

// x + y ==> add(x)(y)

On the first glance the pattern may look disappointing and too artificial to be used in real world applications (at least for the novices in functional programming).

But in fact this powerful pattern can help you to deal with certain problems for what OOP is used before in more elegant way.
For instance you need a printing function that is capable to print something on the output stream.
The usual approach would be to introduce a Printer class that accepts output stream in the constructor and provides the prospective clients with the public print method.
The other functional approach that uses currying may help you to get rid of the excessive printer entity but still provide the prospective clients with the similar print function.

Here is how these approach may look in javascript:

// OOP-alike approach:
Printer = function(stream) {
    this._stream = stream
}

Printer.prototype = {
    _stream: null,

    print: function(message) {
        // implementation omitted for clarity
    }
}

// usage:
//   var p = new Printer(s);
//   p.print("Hello");
//   p.print("World");

and

// Currying-driven approach:
function print(stream) {
    return function (message) {
        // implementation omitted for clarity.
    }
}

// usage:
//   var p = print(stream);
//   p("Hello");
//   p("World");

You may find the latter approach much cleaner and more readable as I did

I would notice that currying was not emerged to replace OOP and this pattern is good when it fits the problem you want to solve (as any other design pattern does).

[To be continued]

To start working with this option you need hsdis plugin, available here.

Then put the downloaded library to the location your OS aware of.
E.g. if you’re using linux all you need is to update LD_LIBRARY_PATH:

export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/home/alex/bin/hsdis"

Then you must be able to start java with the PrintAssembly flag:

/usr/lib/jvm/java-6-sun/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -server -cp . App

The dissassembled output might look as follows:

0xb3a15f0f: jmp 0xb3a15f1b ;*invokespecial RangeCheck
; - java.util.ArrayList::get@2 (line 322)
; - App$Finder::findSolution@33 (line 243)
; - App$Finder::findSolution@182 (line 263)
; - App$Finder::findSolution@182 (line 263)
0xb3a15f11: mov %eax,%ecx
0xb3a15f13: jmp 0xb3a15f1b ;*invokespecial RangeCheck
Total: 13211984ns
; - java.util.ArrayList::get@2 (line 322)
; - App$Finder::findSolution@33 (line 243)
; - App$Finder::findSolution@182 (line 263)
0xb3a15f15: mov %eax,%ecx
0xb3a15f17: jmp 0xb3a15f1b ;*invokespecial RangeCheck
; - java.util.ArrayList::get@2 (line 322)
; - App$Finder::findSolution@33 (line 243)
0xb3a15f19: mov %eax,%ecx ;*synchronization entry
; - App$Finder::findSolution@-1 (line 236)
0xb3a15f1b: add $0x68,%esp
0xb3a15f1e: pop %ebp
0xb3a15f1f: jmp 0xb3a11da0 ;*return
; - App$Finder::findSolution@27 (line 240)
; {runtime_call}
0xb3a15f24: hlt
0xb3a15f25: hlt


The following settings increase performance drastically on Sun JVM 1.6:

-server
-Xms128m
-Xmx512m
-XX:MaxPermSize=250m
-XX:ReservedCodeCacheSize=64m
-XX:+UseConcMarkSweepGC
-XX:+AggressiveOpts
-XX:+CMSClassUnloadingEnabled
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing
-XX:CMSIncrementalDutyCycleMin=0
-XX:-TraceClassUnloading


Notice, that I enabled concurrent mark-sweep GC (in theory it’d be faster than others on 1.6) and aggressive optimizations as well as server JVM and I don’t use assertions (no `-ea’ switch).

I tested these on x86 linux with Idea Community edition of build 111.69

As for appearance I’d suggest using Nimbus theme (Settings -> Appearance -> Look and Feel).

That’s how idea looks on my Ubuntu:

Full screenshot is available here.

P.S.: For Mac OS X users:
There is no idea.vmoptions file on Mac OS X.
In order to modify the mentioned JVM settings, you’d go to the application’s package contents, then open the inner “Contents” folder and then open Info.plist (just click on it and the standard plist editor will be opened). In the opened plist editor consider changing Java > VMOptions key as given above.
You may copy-and-paste the following value I use on my Mac laptop:

-Xverify:none -XX:+UseConcMarkSweepGC -XX:+AggressiveOpts -XX:+CMSClassUnloadingEnabled -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:-TraceClassUnloading -Xbootclasspath/a:../lib/boot.jar


Note, that you may want to make Idea start in 32-bit mode to reduce the memory consumption and increase the overall IDE performance. Just ctrl-click on the application icon in the “Applications” folder and click on the checkbox “Open in 32-bit mode”.

After doing so Idea starts in 1 (ONE) second or so on my Mac Book Pro!

I had 7 interface classes and visitor for all of these, and 7 concrete implementations, then I tested instanceof and visitor pattern on a large collection of randomly picked instances of these classes, the timing for 100000 objects was as follows on my machine (best value is taken for several interations of both benchmarks, the less is of course the better):

instanceof: 5.055 sec
visitor: 3.511 sec

The testing code snippets are as follows:

// for instanceof:
    public static int measureInstanceOf(Node[] nodes) {
        int litCount = 0;

        for (int i = 0; i < N; ++i) {
            if (nodes[i] instanceof Literal) {
                ++litCount;
            }
        }

        return litCount;
    }

// for visitor:
    public static final class LiteralCheckerVisitor implements NodeVisitor {
        boolean isLiteral = false;

        public void visitMarker(Marker marker) {}
        // other methods are similar to the given above and skipped

        public void visitLiteral(Literal literal) { isLiteral = true; }
    }

    public static int measureVisitor(Node[] nodes) {
        int litCount = 0;
        final LiteralCheckerVisitor visitor = new LiteralCheckerVisitor();

        for (int i = 0; i < N; ++i) {
            // equivalent of instanceof Literal
            visitor.isLiteral = false;
            nodes[i].accept(visitor);
            if (visitor.isLiteral) {
                ++litCount;
            }
        }

        return litCount;
    }

As for java version:

java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-10M3326)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode)

The resolution is quite simple - try to avoid instanceof, at least in time-critical code. It's usage often indicates a misunderstanding of the OOP principles and often may result in bad design (and bad performance as well as higher maintenance costs).

<build>
    <plugins>
        <!-- Packaging configuration -->
        <plugin>
            <artifactId>maven-assembly-plugin</artifactId>
            <configuration>
                <archive>
                    <manifest>
                        <addClasspath>true</addClasspath>
                        <mainClass>com.mysite.App</mainClass>
                    </manifest>
                </archive>
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
            </configuration>
        </plugin>
    </plugins>
</build>

Then you’ll be able to create self-sufficient jar:

mvn clean package assembly:assembly

The question is – how to make StaticApplicationContext work as if “annotation-config” is specified to make application context process annotated fields, methods (e.g. @Resource, @PostConstruct, etc.)?

After digging in spring javadocs it turns out to be very simple:

final StaticApplicationContext context = new StaticApplicationContext();

context.registerSingleton("beanPostProcessor", CommonAnnotationBeanPostProcessor.class);
context.registerSingleton("superior", SuperiorImpl.class);
context.registerSingleton("inferior", InferiorImpl.class);

context.refresh(); // Refresh is mandatory before any getBean invocation, otherwise bean processors won't work

final Superior superior = context.getBean(Superior.class);

The most important line is where CommonAnnotationBeanPostProcessor is registered in the DI context.

The spring documentation states regarding this class:

NOTE: A default CommonAnnotationBeanPostProcessor will be registered by the “context:annotation-config” and “context:component-scan” XML tags. Remove or turn off the default annotation configuration there if you intend to specify a custom CommonAnnotationBeanPostProcessor bean definition!


NOTE: Annotation injection will be performed before XML injection; thus the latter configuration will override the former for properties wired through both approaches.

• Create jar where your annotations processor will reside, say ann-proc.jar (Just define annotation processor class).You may want to add dependency to the JDK’s tools.jar in case you wanna use sun-specific code model entities:
  
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.6.0</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>

  
• Create (or proceed to) another jar (say my.jar) you want to process with annotations processor, add annotations you want to process.
• Add the following file (which in fact is a SPI configuration file) to my.jar resources folder
  
resources
|
+ /META-INF/services
|
+ javax.annotation.processing.Processor

  The contents of this file would look as follows:
  
com.ann.proc.processor.MyAnnotationProcessor

  
• That’s it, do mvn clean install on the my.jar package having installed ann-proc.jar and see the effect.If you want to debug your annotations processor, you may use mvnDebug, say do mvnDebug clean compile in the my.jar root folder and attach your IDE to the 8000 debug port.

# Options used by NetBeans launcher by default, can be overridden by explicit
# command line switches:
netbeans_default_options=”-J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true -J-Dswing.aatext=true -J-Dawt.useSystemAAFontSettings=lcd_hrgb”

Checked with openjdk, it probably won’t work for “older” sun JDK.

Spring 3.0.5 doesn’t work with aspectjweaver 1.6.10+ due to AssertionError at org.aspectj.weaver.UnresolvedType.nameToSignature!

E.g. if you use aspects in your spring config with, say, jdbc:initalize-database configuration clause, most likely you’ll get assertion error in your JUnit test what uses such a config.

The possible workaround would be to switch to aspectjweaver of version 1.6.9.