Wednesday, 7 October 2015

An Evening with Java Champion Martijn Verburg

I managed to attend a lecture of Martijn Verburg1 at the Supernova conference room in the Jaarbeurs in Utrecht yesterevening. Courtesy of Blue4IT.

Martijn Verburg, a.k.a. The Diabolical Developer, provided two interactive sessions. The first was "The Diabolical Developer's guide to Performance tuning" The second was "The Habits of Highly Effective Teams".

"The Diabolical Developer's guide to Performance tuning"

Martijn Verburg is the CEO of JClarity1, a company that does Performance analysis of Cloud applications. JClarity introduced the “Performance Diagnostic Methodology” (PDM) to quickly get to the root of the problem.

The points to aid in analysing performance issues were in the following order:
  1. What is your Cloud made of?
  2. Draw diagrams
  3. Measure each Architectural Layer
  4. What is the CPU doing? Overworked or Bored?
  5. Linux commandline tools are pure awesomeness
  6. Garbage collection logs
  7. Oracle micro benchmarks
  8. Visualvm, Netbeans
The talk had a focus sometimes on the Cloud. He seemed critical of it.

The Cloud, or virtualisation in general, seems to be 20 to 25% slower than the old situation of dedicated hardware. It seems a lot of the time virtualised resources are overcommitted on existing hardware. Apparently with virtualisation it is possible that your performance goes down because of "noisy neighbours", i.e. someone else gets a lot of traffic/cpu/stuff to deal with and the others on the same node suffer.

One of the things he noticed in the field, is that performance issues were seldom the cause of some badly programmed application. The issue was usually located a lot lower in the stack, somewhere between the hardware and the JVM.

When analysing performance, start at the bottom and work your way up. So, check the hardware and the Operating System. What is it doing?

Keep your methods small. Java is better able to optimise small methods during Runtime.


Some tools mentioned:
  • JMeter
  • Gatling
  • there seems to be a JDBC driver, that is nothing more than a wrapper around an existing JDBC driver to analyse the traffic
  • vmstat
  • jcviewer
  • visualvm
  • javap -c
  • Netbeans
  • Protobuf
  • Jitwatch

"The Habits of Highly Effective Teams"

I managed to find the slides at [3].

The points in order were:
  1. Social interaction
  2. Strong leadership
  3. Empowerment over Control
  4. Shared goals
  5. Respect and Trust
  6. Common culture
  7. Automation and tools
  8. Encourage debate
  9. Embrace diversity
He mentioned Dunbar's number, on average people can sustain about 150 relationships.

He mentioned the Peter principle, which was interesting as I had never heard of it.

He did mention that where a lot of managers say that you have to earn respect and trust, that simply does not and will never work. It's better to assume total respect and trust, until you are proven wrong by the person you respect and trust.

When debating a technological something, as we engineers often do, the only thing that has any value in a debate are hard facts and empirical data (and not opinions, assumptions, emotions and the like). If you have an inkling that some decision is wrong, prototype it and verify it. Martijn Verburg and his team use the Matt Raible method, where they draw up a Matrix of all the technologically important stuff and give points for a certain framework where it excels or falls short. Then they start prototyping with the three frameworks with the highest scores.

Make the shared goals SMART (Specific, Measurable, Attainable, Relevant, Time-bound).


Martijn Verburg seems highly quotable. Here are some that stuck in my mind.
“Virtualisation is ruining it for everyone.”
“Seagull managers fly in, make a lot of noise, dump on everyone, then fly out.”
“Having to use swap when running out of memory, is like getting your beer from Pluto instead of the other side of the pub.”
“Don't optimize. Java is way smarter than you are.”
“Lead, follow or get out of the way.”
P.S. the picture at the top of the article is the ceiling of the conference room in the Jaarbeurs in Utrecht. They have some very interesting architecture. Seemed like we were sitting right under a rocketengine.


[1] Blue4IT - Kennisavond met Java Champion Martijn Verburg
[2] JClarity
[3] Slideshare Slides - Habits of Highly Effective Teams

Thursday, 1 October 2015

Calling super constructors

So, a constructor in a subclass, if it needs to call the constructor in the super class, is required to do this in the first line of the body of the constructor1.

If it does not, Java will insert a call to the default super constructor. If it does not exist, you get a compile time error.

So, what if you need to do things, before the super call takes place?

As the object is in the process of being constructed (that's why it's called a constructor), the object is in a non-valid state. This likely explains why the language designers felt that a call to another constructor should be the first part of the body of a constructor.

Well, apparently the only solution is to do everything you need inside the expressions that take the place of the super constructor arguments.

I was forced to do just that in my MudWebException.

So, there's an easy workaround, but it feels clumsy.

Take care not to access any of the methods or properties of the object that is being constructed, as it is in a non-valid state. As a matter of fact, I think it's a really bad idea to call methods in the object from within your constructor.


[1] JLS 8.0 Section 8.8.7. Constructor Body
StackOverflow - Why does this and super have to be the first statement in a constructor?