Vanilla Java

Overview An interesting document on Java's short comings (from C developer's perspective) was written some time ago (about 2000? ) but many of the arguments issues are as true (or not) today as they were ten years ago. The original Java Sucks posting. Review of short comings Java doesn't have free(). The author lists this as a benefit and 99% of the time is a win. There are times when not having it is a downside, when you wish escape analysis would eliminate, recycle or free immediately an object you know isn't needed any more (IMHO the JIT / javac should be able to work it out in theory) lexically scoped local functions The closest Java has is anonymous methods. This is a poor cousin to Closures (coming in Java 8), but it can be made to do the same thing. No macro system Many of the useful tricks you can do with macros, Java can do for you dynamically. Not needing a macro system is an asset because you don't need to know when Java will give you the same...

Overview In many cases volatile is required when you need a guarantee about visibility of changes between threads. i.e. All threads see a consistent view of the same field. Demonstrating a consistent failure when you don't use volatile is tricky, and likely to be platform specific. An example The following example show that each thread starts by flipping the value and then stops as each thread has a different view of the field value This works on Java 7 update 2 on Centos 5.7 (x64). Even incidental change to the code, change the behaviour showing how brittle the example is. I would be interested if others can reproduce this behaviour The code public class RequiresVolatileMain { static boolean value; public static void main(String... args) { new Thread(new MyRunnable(true), "Sets true").start(); new Thread(new MyRunnable(false), "Sets false").start(); } private static class MyRunnable implements Runnable { p...

Overview Shifting has lots of edge cases. Some particular to Java. Over shifting In C the expression n and n >> 64 would always be 0, but in Java it will always be n This is because the shifted value is mod'ed by the number of bits. A puzzle If the following program for (int i = -200; i >> i == 1) System.out.print(i+" "); prints -193 -161 -129 -97 -65 -33 -1 37 70 102 135 167 199 What do you get if you change the type to long ? See if you can work it out without running the code.

Overview Using shift in Java and some surprising edge cases. Getting the sign For the following program, what is the values for n so that I can change the type of x without having to change the code. // sign is 1 if negative and 0 if non-negative long sign = x >>> n; There is a value you can replace n such that you don't need to know the type of x Similarly, I want to shift the lowest bit to be the highest without knowing what type I am shifting // sign is MIN_VALUE if odd otherwise 0 long sign = x For bonus points, write formula for all the possible solutions of n (there is more than one) Is a power of two How do you determine an integer is a power of 2. This is a fairly common interview question. Its pretty hard to figure out in an interview I imagine. To save you googling, you can write this in C with x&&!(x&(x-1)) In Java, you can write this using just 0 ~ - & == != . Complete this expression using those operators long x = boolea...

Overview Its easy to assume that because Java doesn't support unsigned primitives that you need a complex wrapper to using unsigned numbers. The challenge Modify the following class which has been written to use signed int as unsigned value. The starting code works for signed values. You need to change the methods so it treats them as unsigned 32-bit int values. The aim is to add/change a minimum of lines. (You can't change the tests or turn them off) public enum Unsigned {; public static int add(int i, int j) { return i + j; } public static int subtract(int i, int j) { return i - j; } public static int multiply(int i, int j) { return i * j; } public static int shiftLeft(int i, int n) { return i > n; } public static int parseUnsignedInt(String text) { return Integer.parseInt(text); } public static String toString(int n) { return Integer.toString(n); } public sta...

Overview The Java Thread Affinity version 1.4.1 library has support for the concurrency library through an AffinityThreadFactory. This follows my previous article on HyperThreading support in the library which give mroe detail on what it does and how it works. Example In the AffinityThreadFactoryMain example, private static final ExecutorService ES = Executors.newFixedThreadPool(4, new AffinityThreadFactory("bg", SAME_CORE, DIFFERENT_SOCKET, ANY)); public static void main(String... args) throws InterruptedException { for (int i = 0; i () { @Override public Void call() throws InterruptedException { Thread.sleep(100); return null; } }); Thread.sleep(200); System.out.println("\nThe assignment of CPUs is\n" + AffinityLock.dumpLocks()); ES.shutdown(); ES.awaitTermination(1, TimeUnit.SECONDS); } by changing the ThreadFactory, you can decide how threads in the ...

Overview A benefit of hyper-threading is the ability to support more threads without incurring the overhead of context switches. If your threads spend a high proportion of their time waiting for resources e.g. busy waiting on a data source, accessing main memory or waiting for short periods of time for IO, hyper threading can improve performance at little cost. However, hyper threading can impact performance when the two threads on the same core start competing for resources, such as the FPU, Level 1 cache, or CPU pipeline. For these reasons, hyper-threading is often turned off in high performance systems. A solution to get the best of both worlds The Java Thread Affinity version 1.4 library attempts to get the best of both worlds, by allowing you to reserve a logical thread for critical threads, and reserve a whole core for the most performance sensitive threads. Less critical threads will still run with the benefits of hyper threading. Example Say you have a system e.g. an ...