StackHolder - Jakub Kubrynski

Advantages coming from dependency injection can be addicting. It's a lot easier to configure application structure using injections than doing all resolutions manually. It's hard to resign from it when we have some non-managed classes that are instantiated outside of the container - for example being part of other frameworks like Vaadin UI components or JPA entities. The latter are especially important when we're using Domain Driven Design . During DDD training ran by Slawek Sobotka  we were talking about options to remove "bad coupling" from aggregate factories. I'm sure you'll admit, that it's better to have generic mechanism able to "energize" objects by dependencies defined by e.g. @Inject annotation than inject all necessary dependencies into particular factory and then pass them into object by constructor, builder or simple setters. Spring framework brings us two different solutions to achieve such requirement. I'll now describe

I haven't used Groovy for 2 years, since my last touch with Grails . I get stuck in (hard)core Enterprise Java, with some performance aspects in background. I've almost missed a chance to learn Spock , but fortunately Warsaw Java User Group helped me to snap out of some legacy systems and back to normal self-development. In fact I hope that frameworks such as Spock or Geb will change approach to writing tests, by making them easier and more effective. Both frameworks use Groovy, as well as the new king in build tools - Gradle . Seeing pace how Groovy impacts our daily routines I decided to look closer at its performance, and compare it to Java 7. My test environment is based on Java 1.7.0_25 and Groovy 2.1.6. As always in such comparisons I used Caliper  in version 1.0-beta-1 (almost stable) and prepared a number of (I hope) representative microbenchmarks. First benchmark based on Fork/Join framework should be most similar in both languages, because it uses some nati

I used to attend Confitura (formerly Javarsovia) or at least watch videos from presentations. I even had a chance to speak on it 4 years ago and share my reflections about continuous integration. This year I also decided to try to organize myself and prepare presentation about profiling Java Virtual Machine. Few days after submitting abstract, my chat window blinks with Tomek Dziurko saying:  - "Hello! Confitura Organisation Commitee would like to invite you to join us. We don't give anything in return except satisfaction, but we take a lot of time. Are you in?" Of course it's great honor but also we've to remember that with great power comes great responsibility :) Finally after exchanging a few words I've decided to accept challenge and put my shoulder to the wheel! Now I can say that it was definitely great decision! Guys - if you're reading this post please know, that working with you is a huge delight! But I'm not going to sum up months of p

Some time ago I had to change standard clustering behavior of Quartz Scheduler, and let it work without synchronizing over database. There are of course a lot of options to do that, but because I'm big fan of simplicity I've decided to use standard Spring @Scheduled configuration and totally skip thinking about cluster at this level. The idea was to just invoke "check that I'm on master node" method at the beginning of the scheduled method. The only problem was how to write such method :) The choice was to use JBoss HA Singleton functionality. It's available in JBoss 7.x but the big lack of documentation forces some experiments... nice! First thing which we need to do is to provide proper dependency, containing few important classes. Of course remember about right version (here I'm using 7.1.1.Final because it's available in public repositories and all next versions of 7 needs to be build manually). org.jboss.as jboss-as-clustering-singleton

Many times in our systems we've to use some messaging platform to provide communication between different servers. Usually we want this platform to be fast (the more the better) and reliable. There are many popular solutions like RabbitMQ, HornetQ and commercial products. But I wanted to try something completely different and really fast so I choosed Java-Chronicle ! Following Peter Lawrey words: "This library is an ultra low latency, high throughput, persisted, messaging and event driven in memory database. The typical latency is as low as 80 nano-seconds and supports throughput of 5-20 million messages/record updates per second." I will add that it can also synchronously persist it into disk and replicate over network - nice :) After cloning project from GitHub we can find two major in this context classes: ChronicleSource and ChronicleSink. The first will be our master server, which will be used as endpoint for getting new excerpts (in this post you can assume that i

As we know unfortunately Maven has no out of the box support for different test types. There are in fact few open tickets for adapting Maven to different test strategies, like adding integrationTestSourceDirectory to POM model ( MNG-2009 ) or new lifecycle phases for operating on integration test sources ( MNG-2010 ) to replace necessity of using build-helper-maven-plugin. But apart from separating varying tests from each other how can we use available mechanisms to invoke both unit and integration tests and measure theirs code coverage? I want to achieve such situation (maybe except the number of tests because I usually want to have a little bit more :)) on the  Sonar  dashboard: We'll work on a simple maven project with the popular layout:

I'm not sure I can be treated as a java master, but fortunately thanks to Warsaw Java User Group I had a chance to attend the 33 Degree Conference. Schedule looked very impressive as there were many rock-star speakers and outstanding talks. It was really hard to choose valid path, but after taking some hard decisions I've created the custom agenda. I've never liked keynotes, so let me start from regular talks :) I've already noticed that Estonia is quite unique in the market of superior Java tools - companies like ZeroTurnaround and Plumbr are doing really nice job. I like them especially when they are talking about as interesting things as JVM internals :) Nikita Salnikov-Tarnovski made very nice presentation titled How much memory do your objects really need?  Apart from the fact that he is showman the talk was really interesing! He introduced  java-object-layout  tool which can analyze object layout schema in different JVM's - another advantage is that this p

A few days ago I needed to parse some reports in Java application. Recently I used for such tasks built-in features, but I can say they are not very user-friendly or intuitive. And I think that there's no reason to use something strange for implementing such simple things. I'll be much better to find very cool replacement. After spending some time googling I've checked that unfortunately there were nothing satisfactory. I've even started thinking about using Scala but luckily in last-ditch attempt I've found JOOX . Really weird name, but I've found out it's abbreviation from Java Object Oriented XML... hmmm - sounds promising :) Authors described it as "simple wrapper for the org.w3c.dom package, to allow for fluent XML document creation and manipulation where DOM is required but too verbose". For me it's enough to start looking for maven artifact: org.jooq joox 1.1.0 Core element

Since the first version of Java, day-by-day many developers have been trying to achieve at least as good of performance as in C/C++. JVM vendors are doing their best by implementing some new JIT algorithms, but there is still a lot to do, especially in how we use Java. For example, there is a lot to win in objects<->file serialization - notably in writing/reading objects that can readily fit in the memory. I’ll try to shed some light on that topic. All the tests were executed on the simple object shown below:  public class TestObject implements Serializable { private long longVariable; private long[] longArray; private String stringObject; private String secondStringObject; //just for testing nulls /* getters and setters */ } To be more concise I’ll show only the write methods (though the other way is quite similar, too). Full source code is available on my GitHub (http://github.com/jkubrynski/serialization-tests).

Lots of us faced with some performance challenge encountered the problem with the right measuring time of some method invocation, loop iteration, etc. The first solution that comes to mind is to use System.nanoTime() before and after execution. And after subtraction we will get our result. But are we sure that the simplest answer is also the best one? What about comparing multiple measurements? What about JIT impact? Fortunately, a new king is in town - the Caliper. It solves all these problems and protects us from committing other standard errors. It’s not my idea to write another tutorial (those available in Caliper’s source repository are good enough to start using this framework). Instead, let's go into details of how to interpret obtained results and choose the right parameters to perform benchmark. The first important thing that Caliper does is it creates full scenarios cartesian using: defined virtual machines benchmark methods (for time measurements it should be pu