Introduction
How often do you think about possible changes in your API? Do you consider that something required could become optional in future? How about compatibility of such change? One of this changes is going from primitive (e. g. int) to its wrapped type (e. g. Integer). Let’s check it out.
API – first iteration
Let’s start with simple DTO class Dep in our public API.
public class Dep {
private int f1;
public int getF1(){
return f1;
}
public void setF1(int f1){
this.f1 = f1;
}
// other fields and methods omitted
}
f1 is obligatory field that never will be null.
Let’s use it in Main class:
public class Main {
public static void main(String... args) {
Dep dep = new Dep();
dep.setF1(123);
System.out.println(dep.getF1());
}
}
compile it:
$ javac depInt/Dep.java $ javac -cp depInt main/Main.java
and run:
$ java -cp depInt:main Main 123
It works.
API – obligatory field become optional
Now suppose our business requirements have changed. f1 is not longer obligatory and we want possibility to set it to null.
So we provide next iteration of Dep class where f1 field has type Integer.
public class Dep {
private Integer f1;
public Integer getF1(){
return f1;
}
public void setF1(Integer f1){
this.f1 = f1;
}
// other fields and methods omitted
}
We compile only the new Dep class because we do not want to change the Main class:
$ javac depInteger/Dep.java
and run it with old Main:
$ java -cp depInteger:main Main
Exception in thread "main" java.lang.NoSuchMethodError: Dep.setF1(I)V
at Main.main(Main.java:4)
Wow! It does not work…
Why does it not work?
We can use javap tool to investigate Main class.
$ javap -c main/Main.class
Compiled from "Main.java"
public class Main {
public Main();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String…);
Code:
0: new #2 // class Dep
3: dup
4: invokespecial #3 // Method Dep.”<init>”:()V
7: astore_1
8: aload_1
9: bipush 123
11: invokevirtual #4 // Method Dep.setF1:(I)V
14: getstatic #5 // Field java/lang/System.out:Ljava/io/PrintStream;
17: aload_1
18: invokevirtual #6 // Method Dep.getF1:()I
21: invokevirtual #7 // Method java/io/PrintStream.println:(I)V
24: return
}
The most important are 11th and 18th instructions of main method. Main lookups for methods which use int (I in method signature).
Next let’s compile the Main class with Dep which has f1 of type Integer:
javac -cp depInteger main/Main.java
and use javap on this class:
$ javap -c main/Main.class
Compiled from "Main.java"
public class Main {
public Main();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String…);
Code:
0: new #2 // class Dep
3: dup
4: invokespecial #3 // Method Dep.”<init>”:()V
7: astore_1
8: aload_1
9: bipush 123
11: invokestatic #4 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
14: invokevirtual #5 // Method Dep.setF1:(Ljava/lang/Integer;)V
17: getstatic #6 // Field java/lang/System.out:Ljava/io/PrintStream;
20: aload_1
21: invokevirtual #7 // Method Dep.getF1:()Ljava/lang/Integer;
24: invokevirtual #8 // Method java/io/PrintStream.println:(Ljava/lang/Object;)V
27: return
}
Now we see the difference. The main method:
- converts
inttoIntegerin instruction 11th, - invokes method
setF1which takes parameter of typeInteger(Ljava/lang/Integer;) in instruction 14th, - invokes method
getF1which returnsIntegerin instruction 21st.
These differences do not allow us to use the Main class with Dep without recompilation if we change f1.
How about Groovy?
We have GroovyMain class which do the same as Main class written in Java.
class GroovyMain {
static void main(String... args) {
Dep dep = new Dep(f1: 123)
println(dep.f1)
}
}
We will compile GroovyMain class only with Dep which uses int:
$ groovyc -cp lib/groovy-all-2.4.5.jar:depInt -d main main/GroovyMain.groovy
It runs great as expected with int:
$ java -cp lib/groovy-all-2.4.5.jar:depInt:main GroovyMain 123
but with Integer… It works the same!
$ java -cp lib/groovy-all-2.4.5.jar:depInteger:main GroovyMain 123
Groovy is immune to such change.
With CompileStatic
But what if we compile groovy with CompileStatic annotation? This annotation instructs groovy compiler to compile class with type checking and should produce bytecode similar to javac output.
GroovyMainCompileStatic class is GroovyMain class with only CompileStatic annotation:
import groovy.transform.CompileStatic
@CompileStatic
class GroovyMainCompileStatic {
static void main(String… args) {
Dep dep = new Dep(f1: 123)
println(dep.f1)
}
}
When we compile this with Dep with int field:
$ groovyc -cp lib/groovy-all-2.4.5.jar:depInt -d main main/GroovyMainCompileStatic.groovy
then of course it works:
$ java -cp lib/groovy-all-2.4.5.jar:depInt:main GroovyMainCompileStatic 123
but with Dep with Integer field it fails like in Java:
$ java -cp lib/groovy-all-2.4.5.jar:depInteger:main GroovyMainCompileStatic
Exception in thread "main" java.lang.NoSuchMethodError: Dep.setF1(I)V
at GroovyMainCompileStatic.main(GroovyMainCompileStatic.groovy:6)
Conclusion
Change from primitive to its wrapped java type is not compatible change. Bytecode which uses dependent class assumes that there will be method which consumes or returns e. g. int and cannot deal with the same class which provides such method with Integer in place of int.
Groovy is much more flexible and could handle it, but only if we do not use CompileStatic annotation.
The source code is available here.
Couple of years ago I wasn't a big fan of unit testing. It was obvious to me that well prepared unit tests are crucial though. I didn't known why exactly crucial yet then. I just felt they are important. My disliking to write automation tests was mostly related to the effort necessary to prepare them. Also a spaghetti code was easily spotted in test sources.
