Dr. Heinz Kabutz is well known for his Java Specialists’ Newsletter,
 initiated in November 2000, where he displays his acute grasp of the 
intricacies of the Java platform for an estimated 70,000 readers; for 
his work as a consultant; and for his workshops and trainings at his 
home on the Island of Crete where he has lived since 2006 -- where he is
 known to curl up on the beach with his laptop to hack away, in between 
dips in the Mediterranean. Kabutz was born of German parents and
 raised in Cape Town, South Africa, where he developed a love of 
programming in junior high school through his explorations on a ZX 
Spectrum computer. He received a B.S. from the University of Cape Town, 
and at 25, a Ph.D., both in computer science. He will be leading
 a two-hour hands-on lab session, HOL6500 – “Finding and Solving Java 
Deadlocks,” at this year’s JavaOne that will explore what causes 
deadlocks and how to solve them.  Q: Tell us about your JavaOne plans.A:
 I am arriving on Sunday evening and have just one hands-on-lab to do on
 Monday morning. This is the first time that a non-Oracle team is doing a
 HOL at JavaOne under Oracle's stewardship and we are all a bit nervous 
about how it will turn out. Oracle has been immensely helpful in getting
 us set up. I have a great team helping me: Kirk Pepperdine, Dario 
Laverde, Benjamin Evans and Martijn Verburg from jClarity, Nathan 
Reynolds from Oracle, Henri Tremblay of OCTO Technology and Jeff 
Genender of Savoir Technologies. Monday will be hard work, but 
after that, I will hopefully get to network with fellow Java experts, 
attend interesting sessions and just enjoy San Francisco. Oh, and my 
kids have already given me a shopping list of things to get, like a 
GoPro Hero 2 dive housing for shooting those nice videos of Crete. (That's me at the beginning diving down.) Q: What sessions are you attending that we should know about?A:
 Sometimes the most unusual sessions are the best. I avoid the "big 
names". They often are spread too thin with all their sessions, which 
makes it difficult for them to deliver what I would consider deep 
content. I also avoid entertainers who might be good at presenting but 
who do not say that much.In 2010, I attended a session by 
Vladimir Yaroslavskiy where he talked about sorting. Although he 
struggled to speak English, what he had to say was spectacular. There 
was hardly anybody in the room, having not heard of Vladimir before. To 
me that was the highlight of 2010. Funnily enough, he was supposed to 
speak with Joshua Bloch, but if you remember, Google cancelled. If Bloch
 has been there, the room would have been packed to capacity.Q: Give us an update on the Java Specialists’ Newsletter.A: The Java Specialists' Newsletter
 continues being read by an elite audience around the world. The 
apostrophe in the name is significant.  It is a newsletter for Java 
specialists. When I started it twelve years ago, I was trying to find 
non-obvious things in Java to write about. Things that would be 
interesting to an advanced audience.As an April Fool's joke, I told my readers in Issue 44
 that subscribing would remain free, but that they would have to pay 
US$5 to US$7 depending on their geographical location. I received quite a
 few angry emails from that one. I would have not earned that much from 
unsubscriptions. Most readers stay for a very long time.After 
Oracle bought Sun, the Java community held its breath for about two 
years whilst Oracle was figuring out what to do with Java. For a while, 
we were quite concerned that there was not much progress shown by 
Oracle. My newsletter still continued, but it was quite difficult 
finding new things to write about. We have probably about 70,000 
readers, which is quite a small number for a Java publication. However, 
our readers are the top in the Java industry. So I don't mind having 
"only" 70000 readers, as long as they are the top 0.7%.Java 
concurrency is a very important topic that programmers think they should
 know about, but often neglect to fully understand. I continued writing 
about that and made some interesting discoveries. For example, in Issue 165,
 I showed how we can get thread starvation with the ReadWriteLock. This 
was a bug in Java 5, which was corrected in Java 6, but perhaps a bit 
too much. Whereas we could get starvation of writers in Java 5, in Java 6
 we could now get starvation of readers. All of these interesting 
findings make their way into my courseware to help companies avoid these
 pitfalls.Another interesting discovery was how polymorphism works in the Server HotSpot compiler in Issue 157 and Issue 158.
 HotSpot can inline methods from interfaces that have only one 
implementation class in the JVM. When a new subclass is instantiated and
 called for the first time, the JVM will undo the previous optimization 
and re-optimize differently.Here is a little memory puzzle for your readers: public class JavaMemoryPuzzle {  private final int dataSize =      (int) (Runtime.getRuntime().maxMemory() * 0.6);  public void f() {    {      byte[] data = new byte[dataSize];    }    byte[] data2 = new byte[dataSize];  }  public static void main(String[] args) {    JavaMemoryPuzzle jmp = new JavaMemoryPuzzle();    jmp.f();  }}When
 you run this you will always get an OutOfMemoryError, even though the 
local variable data is no longer visible outside of the code block.So
 here comes the puzzle, that I'd like you to ponder a bit. If you very 
politely ask the VM to release memory, then you don't get an 
OutOfMemoryError: public class JavaMemoryPuzzlePolite {  private final int dataSize =      (int) (Runtime.getRuntime().maxMemory() * 0.6);  public void f() {    {      byte[] data = new byte[dataSize];    }    for(int i=0; i<10; i++) {      System.out.println("Please be so kind and release memory");    }    byte[] data2 = new byte[dataSize];  }  public static void main(String[] args) {    JavaMemoryPuzzlePolite jmp = new JavaMemoryPuzzlePolite();    jmp.f();    System.out.println("No OutOfMemoryError");  }}Why
 does this work? When I published this in my newsletter, I received over
 400 emails from excited readers around the world, most of whom sent me 
the wrong explanation. After the 300th wrong answer, my replies became 
unfortunately a bit curt. Have a look at Issue 174 for a detailed explanation, but before you do, put on your thinking caps and try to figure it out yourself. Q: What do you think Java developers should know that they currently do not know?A:
 They should definitely get to know more about concurrency. It is a 
tough subject that most programmers try to avoid. Unfortunately we do 
come in contact with it. And when we do, we need to know how to protect 
ourselves and how to solve tricky system errors.Knowing your IDE
 is also useful. Most IDEs have a ton of shortcuts, which can make you a
 lot more productive in moving code around. Another thing that is useful
 is being able to read GC logs. Kirk Pepperdine has a great talk at 
JavaOne that I can recommend if you want to learn more. It's this: 
CON5405 – “Are Your Garbage Collection Logs Speaking to You?” Q: What are you looking forward to in Java 8?A: I'm quite excited about lambdas, though I must confess that I have not studied them in detail yet. Maurice Naftalin's Lambda FAQ
 is quite a good start to document what you can do with them. I'm 
looking forward to finding all the interesting bugs that we will now get
 due to lambdas obscuring what is really going on underneath, just like 
we had with generics.I am quite impressed with what the team at Oracle did with OpenJDK's performance. A lot of the benchmarks now run faster.Hopefully
 Java 8 will come with JSR 310, the Date and Time API. It still boggles 
my mind that such an important API has been left out in the cold for so 
long.What I am not looking forward to is losing perm space. Even
 though some systems run out of perm space, at least the problem is 
contained and they usually manage to work around it. In most cases, this
 is due to a memory leak in that region of memory. Once they bundle perm
 space with the old generation, I predict that memory leaks in perm 
space will be harder to find. More contracts for us, but also more pain 
for our customers. 
  Originally published on blogs.oracle.com/javaone.