Venue: JEEConf 2017

Sources: github

Slides: google slides

Venue: JUG Kyiv

Sources: github

Slides: google slides

The first option I considered when I decided to start up this blog was to use static site generator, and Jekyll as the most popular one was an obvious choice. Shortly after I was ready with the first version of this blog and first post - Using Jekyll, Asciidoctor and GitHub Pages for static site creation, I’ve noticed a link in @sdelamo Groovy Calamary #68 to the static site generator from Groovy world - Grain. As I consider myself as a Groovy ecosystem fan, I could not resist it and quickly migrated this blog to Grain.

When there is a need to make sequential code concurrent, there are two major options. First one is to take the original code as is, divide it between multiple executors, protect a mutable state from concurrent access, do all other "please don’t fail" multithreading stuff and hope for better. The alternative is to look through different concurrency concepts like data parallelism, actors, dataflows, CSP, etc., select the most appropriate one for your problem statement and write the solution on its basis. Luckily there is a library that provides DSLs for all major concurrency concepts called GPars. In this article I will tease how it can be used before my JEEConf talk.

On the latest JUGUA meeting Igor Dmitriev has delivered a talk about minor, behind the scenes changes in JDK. On of them, seems to be widely-known, was HashMap being intelligent enough to turn buckets which are actually long linked lists (because of pure hashCode implementation) into search-trees. Anyway, Igor greatly explained it in a very detailed manner. One thing that was unclear for me, and Igor was not able to explain it as well, is why search tree is constructed for keys which do not have ordering? After some time investigating this question at home, seems like I have the answer.