StackHolder - Jakub Kubrynski

DataTransferObject is one of the most popular design patterns. It has been widely used in archaic Java Enterprise application and some time ago got second live due to growth of RESTful APIs. I don't want to elaborate on DTOs pros (like for example hiding domain logic, etc) because there are whole books talking about it. I just want to cover technological aspects of DTO classes. Usually we create just simple POJO with getters, setters and default constructor. The whole mapping configuration usually limits to  @JsonIgnore annotation added on getter we want to skip. It's the simplest way but can we do better? I'll focus on most popular in Java world Jackson Mapper  and try to answer 3 basic questions which are usually skipped during development, and which in my opinion can improve the design of the transport layer. 1. Can we skip getters? Yes! Jackson is able to serialize our objects using different strategies. Those strategies are fully customizable on two levels: for ...

There are three injection variants in Spring framework: Setter-based injection Constructor-based injection Field-based injection Each of those mechanisms has advantages and disadvantages and there is not only one right approach. For example field injection: @Autowired private FooBean fooBean; It's generally not the best idea to use it in the production code, mostly because it makes our beans impossible to test without starting Spring context or using reflection hacks. On the other hand it requires almost no additional code and could be used in integration tests - which definitely won't be instantiated independently. And in my opinion this is the only case for field-based injections. Now let's focus on two major variants. In  Spring documentation  we can read that ...it is a good rule of thumb to use constructor arguments for mandatory dependencies and setters for optional dependencies. Also in documentation referring Spring up to 3.1 we could find a sentenc...

Recently at DevSKiller.com  we've decided to move majority of our stuff to simple containers. It was pretty easy due to use of Spring Boot uber-jars, but the problem was in  NewRelic  agents which should have to be included separately. That caused uncomfortable situation so we decided to solve it by including NewRelic agent into our uber-jar applications. If you also want to simplify your life please follow provided instructions :) At first we have to add proper dependency into our pom.xml descriptor: <dependency> <groupiId>com.newrelic.agent.java<<groupId> <artifactId>newrelic-agent</artifactId> <version>3.12.1</version> <scope>provided</scope> </dependency>

Caching solves wide sort of performance problems. There are many ways to integrate caching into our applications. For example when we use Spring there is easy to use @Cacheable support. Quite easy but we still have to configure cache manager, cache regions, etc. Sometimes it's unfortunately like taking a sledgehammer to crack a nut. So what can we do to "go lighter"? There is a technique called  memoization . Technically it's as easy as pie but true genius lies in simplicity. Model solution looks as follows: public Foo getValue() { if (storedValue == null) { storedValue = retrieveFoo(); } return storedValue; } As you can see there is no problem in implementing it manually, but as long as we remember about DRY rule we can use already implemented solutions which additionally provides thread safety. Pretty good idea is to use  Guava  library. // create Supplier<Foo> memoizer = Suppliers.memoize(this::retrieveFoo); // and use Foo variable = mem...

New day, new version of Java... nice :) We used to update minor Java versions mostly due to security issues. But sometimes those minor updates brings us brand new, awesome features. So was for example with 7u40 which brought us awesome Mission Control known from JRockit. (If you are interested in tracking changes across Java updates take a look at http://www.oracle.com/technetwork/java/javase/8all-relnotes-2226344.html for Java 8 or http://www.java.com/en/download/faq/release_changes.xml for Java 7) Same situation is now with versions 7u60 and 8u20 . Since now flags MinHeapFreeRatio and MaxHeapFreeRatio became manageable, which means we can change its values... in runtime :)

knowyourmeme.com/photos/531557 thx to @mihn Sometimes debugging Java code is not enough and we need to step over the native part of Java. I spent some time to achieve proper state of my JDK to do that, so short description probably will be useful for ones starting their trip. I'll use the brand new OpenJDK 9! At first you have to obtain main repository by typing hg clone http://hg.openjdk.java.net/jdk9/jdk9 openjdk9 Then in the openjdk9 directory type bash get_source.sh That will download all sources to you local filesystem. Theoretically compiling openjdk is not a big deal, but there are some (hmmm....) strange behaviours if you want to use it for debugging.

Spring Boot  is a brand new application framework from Spring. It allows fabulously quick development and rapid prototyping (even including CLI ). One of its main features is to work from single "uber jar" file. By "uber jar" I mean that all dependencies, even an application server like Tomcat or Jetty are packed into a single file. In that we can start web application by typing java -jar application.jar The only thing we're missing is the managing script. And now I want to dive into that topic. Of course to do anything more than starting our application we need to know its PID. Spring Boot has a solution named  ApplicationPidListener . To use it we need to tell SpringApplication we want to include this listener. And there are to ways to achieve that.