Vanilla Java

Overview This is a comparison between OpenHFT's SharedHashMap and a popular key-value store Redis. Any vendor will tell you how great their product is, so I will start by outlining why you wouldn't use SharedHashMap, before I tell you why it is a "must have" for performant applications. Why you would use Redis? Redis is a more mature database, relatively widely used and it includes; Support for multiple languages. Access over TCP to remote clients. A command line management tool. It out performs many other key-value stores. Why you would use OpenHFT's SharedHashMap? You need to maximise performance in Java. It outperforms Redis, and many other popular key-values stores by more than an order of magnitude in Java. Why does SharedHashMap out perform Redis? It is designed for performance from the start, by being as lightweight as possible. It acts as an embedded data store, even across multiple processes. You don't pay the price of TCP mess

This is a few puzzles for you to solve in Java. b == a is true (long) b < a is true d < c is true d < (long) c is false e <= f is true e >= f is true e == f is false x == y is false x.doubleValue() == y.doubleValue() is true x.equals(y) is false x.compareTo(y) == 0 is true See if you can work out why this code produces the output above (if you use StackOverflow, I will know ;) long a = (1L << 54) + 1; double b = a; System.out.println("b == a is " + (b == a)); System.out.println("(long) b < a is " + ((long) b < a)); double c = 1e19; long d = 0; d += c; System.out.println("\nd < c is " + (d < c)); System.out.println("d < (long) c is " + (d < (long) c)); Double e = 0.0; Double f = 0.0; System.out.println("\ne <= f is " + (e <= f)); System.out.println("e >= f is " + (e >= f)); System.out.print

Overview I was watching this excellent presentation by Rolan Kuhn of Typesafe on Introducing Reactive Streams  At first glance it appears that it has some similar goals to Chronicle, but as you dig into the details it was clear to me that there was a few key assumptions which were fundamentally different. Key assumptions The key assumptions  in the design of Chronicle are low latency is your problem, not throughput. Data comes in micro-bursts which you want to handle as quickly as possible long before the next micro-burst of activity.  you can't pause an exchange/producer if you are busy. (or pausing the end user is not an option) your information is high value, recording every event with detailed timing is valuable. Recording all your events is key to understanding micro-bursts. You want to be able to examine any event which occurred in the past. Low latency is essential The key problem Chronicle is design to help you solve is consistent low latency.  It assumes

These are questions which are likely to be too advanced to ask in any interview as they may just put candidates off.  Never the less, they may be work practising in your own time. Myth 1) System.exit(0) prevents finally being called Why does this code     System.setSecurityManager(new SecurityManager() {         @Override         public void checkExit(int status) {             throw new ThreadDeath();         }     });     try {         System.exit(0);     } finally {         System.out.println("In the finally block");     } print In the finally block and why doesn't it print a stack trace? Myth 2) String str = "Hello"; In this code, str is a String object. Unlike C++, all variables are either primitives or references.  variables cannot be objects.  This means when you have an expression like     String str = "Hello";     String text = "Bye";     str == text; // compares two references, not their c