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.

My coworker discovered that the new version of AspectJ already has the flags built in to turn off the annotation processing. If we can do that we can continue using the Maven Processor Plugin to generate the Hibernate Metamodel data and not have to abandon this. The problem at this point is the AspectJ Maven plugin doesn’t support passing those flags along to AspectJ. So the next step is to get a patch in to that plugin and hopefully we can make the jump to Spring 4.1 at the start of the new year. After that I am going to focus on updating our container so we can finally make the move to Java 8 at work.

I was fortunate enough to attend SpringOne this year and I attended a talk by Venkat Subramaniam on Java 8. I have to say before attending this talk I have always been sort of meh on the functional features brought into the language, but this really got me excited about them. This is the first talk on functional programming that I have ever heard that wasn’t boring, but really engaged the listeners. I strongly recommend people check it out:

For a while now I have been avoiding upgrading the maven java compiler plugin. We are running 2.5.1 at work. The problem is, in the 3.x version, they seemed to have rewritten it, and it doesn’t want to play nice with the maven-processor-plugin that we used to run the hibernate meta model generator. So far it was like cool, I just won’t upgrade to the new version.

Then AspectJ came out with 1.8.2 and the new AspectJ compiler plugin which also seems to be built like the new compiler plugin. At this point I was like well then I might as well update both since Spring 4.1 wants at least AspectJ 1.8.2. But I still have the whole thing fall apart at that meta model step. I found a flag for the maven compiler about forceJavacCompilerUse but even that didn’t solve the problem for me. A coworker said basically AspectJ seems to be doing what we were using the maven-processor-plugin for and generating the meta models for the entities, so he disabled that plugin. However for some reason instead of dumping the generated files in the target directory it is putting them in whatever directory you are in for the build and we can’t seem to find a way to get it to drop them in the target folder.

I came across this blog post today which is the best thing I have read. Basically it is just a short cut list for the best different navigation features in IntelliJ. I didn’t know most of these and they are huge time savers so I wanted to share in case people missed the original post which was amazing.

I was messing around with some of the settings in the Java 8 VM. I have been playing around with Spring Boot lately. So I have a minimal webapp in Spring boot, that has a couple of entities, and services and controllers. I have it configured to run as a standalone jar with an embedded tomcat 8 server. When I do a java -server -jar myapp.jar Spring boot launches my app and when it finishes loading the java process is sitting at 870,160K of memory.

Earlier this year Spring Framework 4.1 was released. I was excited to try out the new features in our project at work and having previously upgraded us from Spring 3.1 to Spring 3.2 and from Spring 3.2 to Spring 4.0 I was expecting this to be another routine Spring update, but alas that was not to be.

One of the first things I do when looking to do a major version upgrade is to check all the dependency versions for the libraries to make sure all of our libraries are new enough to do the upgrade. In this case I discovered that Spring 4.1 requires Jackson 2.x and we were running Jackson 1.9.x.