It has been a crazy few months in startup land. The interesting thing for me about startups is no matter how crazy it is compared to corporate work, I find myself really content amidst the chaos. The big change here is we have decided to build our backend architecture in Go instead of Java. Having done Java for 19 years this is a big change, but for business decisions we decided that the trade offs with Go were better for our long term business needs than the trade offs with Java. Now that I have been using it for a few months I figured I would discuss some of the differences between the languages and what I like and dislike about each.

The bug

I have been using Jackson for JSON processing for many years now. It is a great framework and mostly just works. It is the default framework in Spring Boot and mostly it just sits behind the scenes and drives most micro services in Java these days. That is why I was surprised when we hit a bug in the framework as I hadn’t really had any issues in the past.

I came across this blog post today which I thought was really good. It is a deep dive into the default hashCode() implementation in java. To me the most amazing outcome of the piece is that if a given class is going to be accessed by multiple threads you really need to override hashCode otherwise biased locking is disabled. All in all it is an interesting look in the guts of the JVM and worth a read: default hashCode

Recently at work I worked on a project using Amazon AWS Lambda. This is a cool concept. Amazon calls it serverless computing, but really what it is, is abstracting the server so that you can just focus on a small task that needs to run.

In this case we had a rest endpoint that just stores some data in a database.  If we think about a traditional Spring Boot Microservice we would probably do Spring Data JPA, point it at a mysql DB, and then have some rest controllers that talk to a service tier which persists the data. With Spring Boot this isn’t much code, but you still have some embedded Tomcat Server and a fair amount of ceremony for doing something very simple. After building the app you will need to deploy it to Elastic Beanstalk instance or else an EC2 Nano Instance or something similar. That is a lot of DevOps overhead to do something very simple. With Lamdba we can create a simple class that takes a pojo java object (Jackson style). With Lambda you don’t have Hibernate, you are just dealing with raw JDBC but when you are just inserting 1 Row into a Database you don’t really need am object relational mapping. You then use Amazon’s API gateway to send any requests to an endpoint to the lambda function and you are all good to go.

I upgraded to MacOS Sierra, and have really been enjoying the shared clipboard. I haven’t really noticed any other new features that impact my day to day development, however I would advise Java developers to avoid it for the near future. I have searched and searched and I wasn’t coming up with any results. Then I found this blog post. This is definitely part of the problem. I made the host file changes and got a slight boost, but not enough to explain the whole thing.

I was reading the Spring Blog the other day and I came across this story. I was intrigued because I found the name funny so I read the post and watched the embedded youtube video and was completely blown away. Take all the excitement I had for Spring Boot after SpringOne and multiply it by 10. Not only does this build on top of Spring Boot it integrates in all the trendy front end technologies that are in use today. All the pain of bootstrapping and setting up a full on website is taken away while they do all the work for you.

In my current position one of the metrics we track is code coverage for our unit tests. When I started at the company we were using JUnit with Mockito and JaCoCo. This was a pretty good setup we got good coverage reports and Mockito makes the testing writing much easier.

One of the limitations of Mockito is that you can’t mock private methods or static methods. This presented an issue for us in reaching our desired level of coverage. We initially worked around some of the private method issues using reflection, but it wasn’t always ideal. The decision was made to use PowerMock. PowerMock solved all of our Mockito issues immediately. It was compatible with Mockito but gave us some new powerful features to allow us to get much better unit test coverage. Then we ran our Jacoco reports and found that the reporting no longer worked. Due to the way PowerMock uses byte code manipulation in order to mock static methods it is not compatible with JaCoCo and there is no plan for them to support measuring that.