Pages

Friday, December 27, 2013

Learning Vaadin 7 review

Some time ago I was proposed to review the second edition of the "Learning Vaadin 7" (On Amazon) book. Shame on me for holding it for so long. Previously I have used Vaadin 6 and was really impressed by its features and simplicity of doing real desktop-like web-applications. But at the same time every now and then I was frustrated by some of the methods and mostly by the methods returning plain Objects. Fortunately now these type-safety problems are solved with the Vaadin 7.
But what about the book? It seems as really good introduction to Vaadin for junior developers:

  • It has a really extensive and balanced introduction that defines Vaadin place in the Java and Web ecosystems. Actually, I think that it is worth reading on its own.
  • It proceeds with detailed instructions on the development environment setup with a dive into production setup.
  • It is really detailed with all the basic and not so basic concepts of building Vaadin applications clearly explained.
The drawbacks of the book, that I can name are:
  • Examples use ant+ivy as a build system that seems less widespread to me, but it may have its benefits since it leaves much less area for "build magic" and gives more control and understanding of the build. Also information about Maven is given in a separate chapter.
  • Book seems like a one time reading for me. It can not be used as reference - but again, it is clearly stated that this is not a goal. Also it will motivate readers to search for information as it should be done after the book is read.
As an overall conclusion, I would not buy such book for myself, but I will probably recommend it to newbie developers.

Monday, November 25, 2013

Java8 HashMap is not compatible with Java7... in a way...

One of the things that shine in Java (not the only one!) is its performance. And it constantly improving. One of the performance improving features of Java8 is an improvement to HashMap and many related standard hashing collections. Actually from the title of this JEP (JDK Enhancement Proposal) "Handle Frequent HashMap Collisions with Balanced Trees" it is clear that this enhancement uses Comparable and Comparator functionality. If class do not implement Comparable interface or not Comparable with each other classes are stored in the map - Comparator based on the hashcode is used. But if class implements Comparable - this implementation is used.

So based on all this here is the very simple question. What does this code output on the JVM version 7 and on the JVM version 8?

Thursday, November 21, 2013

Benchmarking Guava's ImmutableMap

So I decided to bench (with the help of the excellent JMH suite) Guava's ImmutableMap. The first my try revealed some not expected results.

Source of the benchmark: Results: What I was not expected is that Guava's ImmutableMap with single entry is much faster to create than standard Collections.singletonMap(). Another surprise was in no performance benefits from using ImmutableMap with more than one entry comparing to HashMap and HashMap inside standard Collections.unmodifiableMap().

But this was test for creation of the map only. So here is the second version with simple work of the "contains" method: Results: The result is almost the same.

What is different in Collection.singletonMap comparing to the Guava's ImmutableMap is cached keySet, entrySet and values fields. I decided to make a little test to know whether not-initialized (and thus pointing to null) and not-used fields impact performance. Results: As it is seen the difference is significant. So probably the difference in Collections.singletonMap() and Guava's ImmutableMap is caused by these three fields even if they are not used.

In order to compare performance using these caching fields (or at least one of them) I made the third version: Results: Guava's ImmutableMap is still a bit better than Collections.singletonMap() but the difference is much less than in the first version. I assume that if using all the fields cached in standard version - it will be better.

Another surprise it no performance benefits from using Guava's Maps.newHashMapWithExpectedSize(). 128 entries is definitely enough to produce at least one rehash of the HashMap but probably they do not damage performance in a significant way, or there was really no rehashes since the expected size of the HashMap was inferred form the subsequent code but the JVM.

And the last surprise was that HashMap inside the Collections.unmodifiableMap() may have a better performance not only comparing to the Guava's ImmutableMap, but also comparing with exactly the same HashMap without any covers.

Saturday, June 29, 2013

Synchronized vs threadlocal SimpleDateFormat based on JMH

Micro-benchmarks are really hard. If you have seen some in this blog and you think that at least some of them are correct - you are wrong! ;-) Actually I don't think that I would ever really need to do some micro-benchmarks. To the moment all performance optimizations that I have done were about SQL (mostly), or not loading all the data into memory, but loading and processing it in chunks instead, or introducing some caching, or introducing multi-threading, or just rewriting the algorithm from scratch (introduction of multi-threading is usually the complete rewrite too).

But to have some fun (and to have at least anything to write in blog about) I sometimes do such stupid benchmarks. Of course it is better for this fun activity to have at least some similarity to the real world. Recently (maybe not really recently) Oracle Java Performance Team has open-sourced their framework for micro-benchmarks. I decided to try it and rewrote my benchmark for patterns of multi-threaded usage of the standard SimpleDateFormat (why actually use it since we have joda-time for Java <= 7 and new shiny standard datetime api for Java >= 8?). So here is the result of this benchmark on the Core i7-3632QM (laptop) processor.
The code for this can be found here.
I have tried the same benchmark on the Core i7-3770K (desktop) processor also. And here is the graph:
What we can see is the expected result, except that for the synchronized access to the single SimpleDateFormat the results are not very smooth and stable. So here is the same graph with the synchronized access to the SimpleDateFormat measured in 30 iterations (5s each) instead of 10.

This measurement has not cleared anything actually... What I think is that JIT-compilation of of the version with single synchronized SimpleDateFormat is not stable, so the result of the measurement is stable across different iterations of the same run, but is not stable across different runs and maybe contrintuitive for different number of threads in the same run (different methods => different acts of compilation => different code).

Monday, June 10, 2013

First attempt with scala

I decided to try scala once again (all previous attempts did not last long). I have not read any book about scala so far, and this is just dummy attempt, so I tried to use everything that I already know from Java. To my luck I have stumbled on the project by Graham Lea that uses maven for building, spring-mvc as the web-framework and hibernate as a database access layer. This project actually works, so it is possible to try it moving from one working state of the project to the other.
What I have done in my fork so far:

  • maven-eclipse-plugin is a deprecated way of generating Eclipse project files for the maven project, since Eclipse itself has a pretty good support for maven-basd projects. However inside the stable version of Scala-ide a rather old version of Eclipse is used internally, so maven support is not so great, but still it is good enough to not use maven-eclipse-plugin. So I removed its configuration from the project.
  • Selenium tests was the part that didn't work for me in this project (probably because I'm on Linux), so I removed them and started tests using spring-test library.
  • The latter required spring framework upgrade. Also I have upgraded Hibernate and scala and scala-maven-plugin to the latest versions. This required a bit of editing the scala sources and changing the scala-ide installation since different versions are required for scala 2.9.x and 2.10.x.
  • I migrated the project from using Hibernate SessionFactory to EntityManager and spring-data-jpa (scala traits can be used as spring-data repository interfaces). It seems that this way of using Hibernate is a bit more up-to-date and is free from issues like this one, that I trapped into some time ago.
Glitches that I have stumbled over are about Scala-ide and both can be seen in this file:

  • Organizing imports action removes imports in use making compilation to fail (in the file mentioned SpringJUnit4ClassRunner import is removed, but I have seen this in other situations too)
  • Formatting the source remove comments (in the file mentioned the "//TODO..." comment is removed)
So now is the time to read something about scala and all the surrounding magic. Any thoughts on what book or resource should I read?

Thursday, May 9, 2013

Github vs Bitbucket

Github totally owns the open-source movement today. And this situation impacts enterprise development. But as far as I can tell Bitbucket is much better for proprietary development in private repositories. Here are the arguments:

  • Option to prevent non-fast-forward pushes. It even allows to prevent non-fast-forward and still allowing removal of feature-branches! As far as I know, this may require a bit of configuration in standalone git repositories. No such option on Github. UPDATE: Requires email to support@at@github.com but the response is fast  - even in my not straightforward case.
  • Pricing model. Github offers unlimited collaborators form the start and additional private repos for additional money. Bitbucket offers unlimited private repos from the start and additional collaborators for additional money. I think the latter option is better - division of project in modules residing in separate repositories is the technical task. And technical decision person should have freedom to do the best. Technical staff usually does not make financial decisions. And extending the team is really that kind of decision that could not be made without considering financial side. So I think if choosing what side of the plan to make dependent on money - number of collaborators is better because without any Github or Bitbucket this side does depend on money. And number of repositories, if not made artificially dependent on money, does not depend on money at all.
So there are only two of them - but the first I would consider as a show-stopper, and the second really annoys leading to several unrelated projects in the single repository. 

Thursday, April 4, 2013

Use newer Java FTW!


One of my recent tasks was trying to convince client, that we should target the 7th version of the JVM, and not the 5th. I failed. Actually I don't think that such task is possible unless there are no any real reasons in using older Java. Nevertheless here is the text, that I wrote: