Tiobe Index

I stumbled accross the following Programming Community Index, Tiobe which tries to chart the most popular programming languages.


Although the metrics to determine these ratings are discussable, I like to point out a few things :

• The index can be used to make a strategic decision about what programming language should be adopted when starting to build a new software system. Apparently, since Java remains the most popular language, long term projects will not suffer from a shortage of people with programming experience in Java. It may not have the fastest developement cycle or the best performance but it is the safest choice.
  
• Talking about niche's, the ABAP language is back on his way up. Combining this with the popularity of Java (both are usable within the SAP framework) results in a high demand of ERP/SAP specialists, like a few friends of mine are experiencing.
• Remarkable Ruby: Ruby continues his way up. The hype keeps growing. Since JRuby can easily be integrated in the Java 6 SE VM, it definitely makes sense for Java developers to start learning this programming language. Due to Tiobe, Ruby is the top favorite for the title "Programming language of the year 2006". Poor performance of Ruby remains an issue however.
  
• The eye catching increase of Transact SQL is unexplainable. The language is available for many years in Microsoft SQL Server. I am forced to use it in my current project and I can hardly hide the fact that I dislike it. It is related to PL/SQL, which also occupies a fairly high ranking.
• The popularity of the D language is sky rocketing. I am a total virgin with this programming language, so I cannot tell anything useful about it. I only took a quick tour at the D website and the language features look pretty low level to me. Due to its name, it claims to be the successor of C(C++). Its performance is great and its increase in popularity is remarkable.
  

Javapolis

I just got back from the European Conference on Java : Javapolis. I had the chance to attend a very interesting session from Eric Evans on Domain Driven Design and an astonishing demonstration of Ruby On Rails from the JRuby guys. That certainly tastes like more !

Writing Java Doc

One of the rules the great book Effective Java Programming Language Guide mentions, is to write doc comments for all exposed API elements. Since I have difficulties remembering all the specific conventions considering this rule, I find Sun's How To Write Doc Comments very useful. In my personal opinion there is absolutely no valid excuse to NOT write doc comments for all your public methods and classes.

Java VM Performance

During surfing, I came accross the following articles considering Java performance :

• Java Benchmark, claiming that Java is faster than C++
• And its reply : Java is not really faster than cpp

I am not going to jump into the flameware C++ versus Java. One interesting topic however did drew my attention. Despite the opposite benchmark results of both articles, they have one result in common : the significant performance difference between client VM and server VM.

Every form of Sun's Java runtime comes with both the client VM and the server VM. Java applications and applets run by default in the client VM. Following the benchmarks, the Server VM is much faster than the Client VM, although it has the downside of taking around 10% longer to start up due to its HotSpot behavior, and it uses more memory.
To run Java applications with the server VM, use
java -server [arguments...] instead of java [arguments...]. Setting this -server parameter causes the use of an optimizing JIT compiler, due to Java HotSpot VM options.

In relation to the post Adding your development database under source control you have to modify the database server startup script as follows :

<java classname="org.hsqldb.Server" classpathref="master-classpath" fork="true">
<jvmarg value="-server"/>
</java>

If running this results in the following error :

Error: no `server' JVM at ...

you have to copy the server folder from your Java/jdk1.5.0_10/jre/bin to the Java/jre1.5.0_10/bin folder.

P.S. For the freaks who get a thrill of performance statistics, the more reliable source is the performance shootout at Computer Language Shootout.

Lazy Unit Testing

<preamble>
I recently started reading "Beyond Java" from Bruce Tate. I was sting by the following sentence in the introduction : "(..) are now stretching Java beyond its intended purpose, and that's good...to a point. You're also increasing the barrier to entry. Ask any novice who's tried to troubleshoot a problem with Hibernate's lazy loading, or Spring's proxies.".
</preamble>


Today, I finally solved my unit test problems I encountered in my pet project. It had everything to do with Hibernate's lazy loading (and me being a novice in Hibernate/Spring). Since I used the Spring's Open Session In View pattern, my web application never suffered from using Hibernate's lazy collections. But during my unit tests, where I couldn't rely on this nice pattern, I encountered the following error far too many times :

org.hibernate.LazyInitializationException: failed to lazily initialize a collection

I used to fix-hack this by opening a session and lock(LOCKMODE.NONE) the asserted collection. But today I came accross this unit testing article (step 11), and I adapted my unit tests accordingly and now it works great.
The key solution was to add the following :

protected void setUp() throws Exception {
this.session = SessionFactoryUtils.
getSession(sessionFactory, true);
TransactionSynchronizationManager.
bindResource(sessionFactory,
new SessionHolder(session));
}

protected void tearDown() throws Exception {
TransactionSynchronizationManager.
unbindResource(sessionFactory);
SessionFactoryUtils.
releaseSession(session, sessionFactory);
}

Nevertheless, Bruce definitely has a point, the development of a basic Java application has a high entry cost ! Time to check out Ruby On Rails like he suggests ?!