Sometimes you have a piece of logging that is very important, maybe even part of a business requirement. In that case, you might want to verify that in a unit test, so you can rest assured that this requirement is actually met. How to do that? Mock it away A first approach might be to just mock your logging framework in a unit test and verify it was called as you expected.
As a closing keynote on the second day of Jfokus, Jonas Bonér took the stage under the very clarifying title “Blah blah Microservices blah blah”, which turned out to mean “From microliths to microsystems”. As a first observation, he stated that no-one really likes microservices. They are kind of a necessary evil - because “doing” microservices comes at a cost. In fact, microservices are just a specialisation of an older concept called distributed systems.
The second day of Jfokus is just as action-packed as the first one. However, part of the action is me giving two talks. Both of them scheduled today, so a little less time for attending other sessions and blogging about them. I did attend some other sessions after lunch time, on which I’ll report below. Introduction to Machine Learning Directly after the lunch, James Ward gave an introduction to machine learning.
Inspired by a Jfokus session I attended today I decided to download and install a preview of Java 9 on my MacBook. That went pretty quick and without much trouble. But when I issued java -version on my terminal, I was greeted with Java(TM) SE Runtime Environment (build 9-ea+155) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+155, mixed mode) Although that’s nice - you’d even expect it, maybe - I realised I often need Java 8 as well.
These days, I’m in Stockholm, attending and speaking at the Jfokus conference. Yesterday night was a great opportunity to get to know a few other speakers during dinner. We were even surprised by an act of the Lemon Squeezy barbershop quartet singing for us - very beautiful! But today, the serious stuff started. In the following sections, I have written down my notes and observations of each of the sessions I attended.
When using third-party components (be it open source or not), we all know it’s a good practice to keep your frameworks and libraries up to date. This is also one of the spearhead in the OWASP Top 10 (2013 edition): A9 - Using Components with Known Vulnerabilities. To help you assess your projects status with regard to this, OWASP.org developed the tool Dependency Check. This tool is primarily intended code bases in Java, .NET, Ruby, Node.js, and Python. Integration with various build tools is also provided for.
To start with a cliche: the Java ecosystem continues to develop at a high pace. Various open source frameworks releasing versions, sometimes even multiple versions at the same time. This may quickly turn into a risk But how to deal with it? Basically, you have two options. We’ll take a typical Maven-project as an example, which uses Commons Lang 3. See the end of this post if you prefer Gradle over Maven.
This week, I came across an interesting difference between the Java API documentation and its current implementation. A difference? Or is it just a matter of thorough reading? If you look at the Javadoc for Double.valueOf(), you’ll find that it is likely to outperform the use of new Double(). Sounds good! And don’t we all ove it when we get a free performance boost? However, examining the source code to see what causes this “significantly better space and time performance”, we find….