This years javaone conference is about to happen and since my conference pass has been ordered it is time to wrestle myself through the program in order to find the most optimal schedule in terms of quality and time. Meaning a lot of reading, shuffling, weighting and head-scrabbing. A process which probably will last untill the last session of the conference. But some sessions are a definitive certainty. And one of these sessions tagged whith the coolest session title of the conference:
Java™ Puzzlers, Episode VI: The Phantom-Reference Menace/Attack of the Clone/Revenge of the Shift
After last years ‘Tiger Traps’, changes are big this session will end up high in this years top-10!
Last week the latest release of the Spring frame work was announced on the springframeworkdotorg website. Nothing special, just an .0.x bugfix and enhancement release, actually nothing exiting. So why is it worth a blog entry? Because of the curious announcement that spring bean creation has gone through tremendous performance improvements. Let me Quote: “Regarding the performance improvements, repeated creation of Spring bean instances is up to 12 times faster in this release than previous versions of Spring 2.0. AspectJ-based weaving performance has also increased by a significant factor. “.
Wow, twelve times! That is a pretty precise and accurate number! So not ten, not eleven but exactly twelve times faster! But to bad, my manager asked me to speed up bean creation time by a factor thirteen so I think I need to switch to Guice instead.
The problem in this statement is not the number itself but the fact a number is used to express improvements in an area the expresser has no full control. Currently I’m downloading both the 0.3 and 0.4 releases of Spring2 and my first conclusion is the 0.4 release is about 1.01 times bigger in terms of megabytes (off the record, 62.2 MB for a framework download is pretty fat). My second conclusion is the 0.4 release got downloaded 1.3 times faster. Both are facts, (it’s happening straight in front of me!) but the last fact does not express anything! There are too many factors that are influencing this magic number. Same with the 12 times faster statement. I won’t argue about the fact 2.0.4 has improved bean creation and I immediately believe there situations the number is matched by the comma. But personally, it says nothing to me: I’ll wake up when someone tells me the startup time of all my spring based apps have been square rooted. And even then I’ll point to the useless sleep statements in my constructors which are sitting there only to invalidate bold performance claims.
Note I’m not trying to nitpick on anything; every improvement is more than welcome, as long as my beans see the light, but this kind of statements are besides hollow, technically completely insignificant. Why not give insight *what* has been done to improve performance. Like:
- AbstractAutoProxyCreator caches advice information per bean, for efficient prototype creation with auto-proxying
- AnnotationAwareAspectJAutoProxyCreator caches Advisors for singleton @Aspect aspects, increasing performance
- BeanWrapperImpl mimimizes bean name parsing overhead and caches parsed property path tokens
- DefaultListableBeanFactory caches pre-converted property values as far as possible
- ConstructorResolver caches the resolved constructor or factory method, for faster re-creation of prototype instances
- ConstructorResolver caches converted argument values, to avoid conversion overhead for re-created prototype instances
(As one can see, ‘grep “cache” changelog.txt’ clarifies everything)
Nevertheless, I’m pretty happy with this release and I’m only writing this down as an advice for the upcoming 2.0.5! And now the changelog is still open on my desktop, I can end this blog entry by probably the most important enhancement:
- updated JRuby support for JRuby 0.9.8 !!
By the way, JRuby 0.9.8 claims IO sometimes to be 6.5 times faster ……
Bjarne Stroupstrup, the inventor of the C++ programming language, has an interesting technical FAQ about C++. He has an example in the FAQ that inspired me to try this out in C++, Java and C#. Have a look at the following C++ code. What do you think this prints?
(NOTE: The C++ code looks a bit weird. I had to replace the angle brackets with ‘[’ and ‘]’ because the WordPress editor does not let me enter angle brackets properly, even if I edit the HTML code manually…).
#include [iostream] // NOTE: Use angle brackets here
class Super {
public:
void method(int i) {
std::cout [[ "method(int): " [[ i [[ std::endl; // NOTE: Use angle brackets here
}
};
class Sub : public Super {
public:
void method(double d) {
std::cout [[ "method(double): " [[ d [[ std::endl; // NOTE: Use angle brackets here
}
};
int main(int argc, char* argv[]) {
Sub obj;
// Which method is called for each of these statements, the int or the double version?
obj.method(10);
obj.method(3.2);
return 0;
} Here is the Java version. What do you think this prints? Do you think Java works the same as C++ or not?
class Super {
public void method(int i) {
System.out.println("method(int): " + i);
}
}
class Sub extends Super {
public void method(double d) {
System.out.println("method(double): " + d);
}
}
public class Main {
public static void main(String[] args) {
Sub obj = new Sub();
// Which method is called for each of these statements, the int or the double version?
obj.method(10);
obj.method(3.2);
}
} And lastly the C# version. What do you think - does C# work the C++ or the Java way, or is it the same - or different?
namespace Example {
class Super {
public void method(int i) {
System.Console.WriteLine("method(int): " + i);
}
}
class Sub : Super {
public void method(double d) {
System.Console.WriteLine("method(double): " + d);
}
}
class Program {
static void Main(string[] args) {
Sub obj = new Sub();
// Which method is called for each of these statements, the int or the double version?
obj.method(10);
obj.method(3.2);
}
}
} 
