upgrading mockito – forwards and backwards

I upgraded Mockito from 1.X to 2.X. (Because I wanted to try out the JUnit 5 MockitoExtension.

JUnit 4

I like @RunWith(MockitoJUnitRunner.class). The two main benefits:

  • Inject mocks as instance variables instead of static call to MockitoAnnotations.initMocks(this);
  • Tells you about unnecessary mock setup calls you have.

JUnit 5

Instead of the Mockito Runner, you use @ExtendWith(MockitoExtension.class). This was written by the JUnit 5 team. The two main benefits:

  • Inject mocks as instance variables
  • Inject mocks as method parameters

What’s missing

In JUnit 5, Mockito no longer tells you about extra setup code that you should delete. And neither version automatically calls verify() like JMock does. I miss that feature and wish Mockito had it. It is nice to be able to have the mock library tell you the actual code didn’t call an expected value without having to remember to code a call to verify the mock. (If Mockito does have it and I didn’t notice, please leave a comment!)

eclipse and line wrapping

Last month, a co-worker referenced an Eclipse setting that I wish I’ve known about for years.  With streams, I typically indent code like:


list.stream().filter(j -> j.disabled)

.map(j -> j.name)

.forEach(System.out::println);

Then I’d let Eclipse format the code and it would turn into a one (or two) line wall of text. I’ve been “solving” that problem by adding comments before some of the methods so Eclipse couldn’t wrap it. Some of those comments are useful for those new to streams. However many are redundant. You probably don’t need a comment that the last line outputs :).

Then my co-worker taught me that there is an Eclipse setting to control the line breaks. Wish this was on by default!

How to configure

If you don’t already have a custom Eclipse formatter:

  1. Eclipse preferences
  2. Java > Code Style > Formatter
  3. New
  4. Enter a name
  5. Click ok

Control line breaks

  1. Edit the profile
  2. Line wrapping tab
  3. Check “Never join already wrapped lines”

java @ speed: making the most of modern hardware – live blogging from qcon

Java @Speed – Making the most of modern hardware
Speaker: Gil Tene
See the list of all blog posts from the conference

duct tape engineering should only be done when absolutely necessary

We think of speed as a number. But it’s not a quality without a context. Are you fast when you deploy? When at peak load? When the market opens? When acually trade? How long can you be fast in a row?

In Java, speed starts slow when app starts and gets faster until gets to steady point. Because the code changes over time. It starts out purely interpretted then optimizes after profiling. Also, GC pauses.

Modern servers

  • Number cores/chip has tripled
  • Instruction window keeps increasing
  • More parallelism each generation
  • Cache also increasing

Compilers

  • Can reorder code
  • Can remove dead code – nobody knowsif it ran the code. So can say did it; just really fast.
  • Values can be propagated – remove temporary variables
  • Can remove redundant code
  • Reads canbe cached – as if you extracted a variable. Use volatile if needs to avoid
  • Writes can be eliminated – can save calculation if doesn’t change
  • Can inline method call
  • Also does clever tricks lie checking for nulls only after SEGV happens. If you turn out to throw a lot of null pointers, deoptiizes to add guard clause
  • Class Hierarchy Analysis (CHA) – looks at whole code base for optimizations
  • Inlining works without final because knows no subclass. If a new subclass shows up, deoptimizes at that time.
  • If think only have one subclass, add guard clause and optimize. The guard clause will unoptimize
  • Deoptimizations create slowdown spikes in performance even during the optimized phase. Warmup isn’t always enough because warm up code might not hit all scenarios. “The one thing you haven’t done is trade.” So the first real trade is slow because it is deoptimization.
  • Azul has a product that logs optimizations and re-loads them on startup from prior runs.

Microbenchmarking is hard because some things are optimized away (like basic math). Use jmh from OpenJDK to microbenchmark, but still suspect everything.

I like that he showed the assembly code and explained the relationship to a simple for loop.