StackHolder - Jakub Kubrynski

Libraries provided by Netflix , usually look simple, but after a deep dive, you will realize this stuff is pretty complicated. In this article, I want to explain behavior and usage of the circuit-breaker pattern being a part of the Hystrix . Following the Wikipedia definition "Circuit breaker is used to detect failures and encapsulates logic of preventing a failure to reoccur constantly (during maintenance, temporary external system failure or unexpected system difficulties)." What does it mean? For example, let's consider the circuit as a connection between two services. It operates normally (aka stays closed) when the connection is stable, and the target service is healthy. We can execute our requests (assume 100 per second) without any problems. But when our target service is down (what we know after a few unsuccessful tries), it no longer makes any sense to try 100 times per second. So we open our circuit and serve responses from a predefined fallback, as we kno...

I can bet that every Java developer at least heard about L1 (aka EntityManager or Session) cache. But is your level of understanding it good enough? If you're not sure, consider going through this post. At first, we need to know what the persistence context is. Following EntityManager JavaDoc  we know, that: "A persistence context is a set of entity instances in which for any persistent entity identity there is a unique entity instance. Within the persistence context, the entity instances and their lifecycle are managed."  In fact, the first level cache is the same as the  persistence context . That means operations such as persist() , merge() , remove()  are changing only internal collections in the context and are not synchronized to the underlying database. What is the mosts important here is what happens when you invoke the  clear()  method. It clears the L1 cache. But we know L1 == persistence context. Does it mean clearing L1 removes al...

Equals and hash code are fundamental elements of every Java object. Their correctness and performance are crucial for your applications. However often we see how even experienced programmers are ignoring this part of class development. In this post, I will go through some common mistakes and issues related to those two very basic methods. Contract What is crucial about mentioned methods is something called "contract." There are three rules about hashCode and five about equals (you can find them in the Java doc for Object class), but we'll talk about three essential. Let's start from hashCode() : "Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information  used in equals comparisons on the object is modified." That means the hash code of an object doesn't have to be immutable. So let's take a look at the code o...

There are many ways of dividing whole application into packages. Discussions about pros and cons of packaging by feature or by layer can we found on many programming blogs and forums. I want to discuss this topic starting from testability and see if it will drive to any meaningful result. At the beginning let's try to describe what we usually want to test in our applications across different layers. Let's assume standard three tier architecture. At the bottom we have data layer. Depending on our attitude to Domain-Driven-Design we'll try to maximize (for rich, business-oriented entities) or minimize (for anemic entities built only from getters and setters) test coverage. In the second approach it's even hard to say about any tests, unless you don't trust Java and want to verify if get can retrieve value assigned before by set invocation. For rich entities we definitely want to verify business logic correctness. But to be honest it almost always can be done by si...

Few years ago in Java world it was almost obvious that every "enterprise" class project needed JPA to communicate with database. JPA is a perfect example of " leaky abstraction " described by Joel Spolsky. Great and easy at the beginning but hard to tune and limiting at the end. Hacking and working directly with caches, flushes and native queries is a daily routine for many backend developers involved in data access layer. There are enough problems and workarounds to write a dedicated book "JPA for hackers", but in this article I'll focus only on concurrent entity processing. Let's assume the situation: we have Person entity which in some business process is updated by some service. @Entity public class Person { @Id @GeneratedValue private Long id; private String uuid = UUID.randomUUID().toString(); private String firstName; private String lastName; // getters and setters } To ignore any domain complexity w...

Even today (and it's 2015) we have two versions or Oracle HotSpot JDK - adjusted to 32 or 64 bits architecture. The question is do we really would like to use 32bit JVM on our servers or even laptops? There is pretty popular opinion that we should! If you need only small heap then use 32bits - it has smaller memory footprint, so your application will use less memory and will trigger shorter GC pauses. But is it true? I'll explore three different areas: Memory footprint GC performance Overall performance Let's begin with memory consumption. Memory footprint It's known that major difference between 32 and 64 bits JVM relates to memory addressing. That means all references on 64bit version takes 8 bytes instead of 4. Fortunately JVM comes with  compressed object pointers  which is enabled by default for all heaps less than 26GB. This limit is more than OK for us, as long as 32 bit JVM can address around 2GB (depending on target OS it's still about 13 times l...

I've always been missing possibility to configure custom headers in JStat . Of course there are a lot of predefined data sets, but it'll be nicer if we could create our own data set. And as you probably already devised I'm writing this post because such functionality is of course available :) Unfortunately I haven't found it in any documentation so now I'll try to fill this gap. First thing we have to do is to provide custom descriptor with possible JStat options. This descriptor is just a text file containing something we'll call "jstat specification language". To make this custom file available to JStat we should place it in the following path: $HOME/.jvmstat/jstat_options If you want to view the bundled options please refer to  file in OpenJDK repository . The specification language is pretty similar to json files, and it contains the group of option  elements. Each option should be threaten as a set of columns that can be shown in single jsta...

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.

After my last article there were some questions about how Java configuration work in details, and we can extend it to suite our needs. So I'll try to answer those question in this post :) Heart of Spring java configuration mechanism are  @Configuration classes. That's the place where we can define all properties of our Spring context. Assuming that we lean our application on annotations (which should be true if we want to use java config) we create beans using  @Component annotation (with derivatives like  @Repository , @Service and @Controller ). Varying annotations apply for different layers: @Component generic for any compoenents @Repository persistence layer @Service service layer @Controller presentation layer

Few years ago majority of us were used to write XML config files everywhere, to setup even simple Java EE application. Today using Java or Groovy to configure projects is becoming preferred way - you just need to take a look at Gradle or functionalities introduced in further versions of the Spring Framework to gen up on this. Now I'll deal with configuring Spring contexts for web application. Java EE provides ServletContainerInitializer interface, which allows libraries to be notified of a web application startup. Since Spring 3.1 we have SpringServletContainerInitializer class which handles WebApplicationInitializer by instantiating all found classes implementing this interface, sorting them basing on @Order annotation (non-annotated classes gets the highest possible order, so they are processed at the end) and invoking onStartup() method.

I'm currently working on a project where we use Spring Framework 4.0 and Spock for testing. Unit testing in Spock is really great, but there are some lacks in integration testing - especially in mocking Spring beans. Our requirement is to start up Spring context but with particular bean replaced with mock. The easiest part we had do implement is just regular Spring test specification: @ContextConfiguration( classes = [GatewayConfig, PaymentServiceConfig]) class PaymentServiceSpecIT extends Specification { final String CLIENT_ID = "54321" @Inject PaymentService paymentService def "Should return auth token"() { when: def token = paymentService.getAuthToken(CLIENT_ID) then: token } }

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...