Tuesday Jan 08, 2013

Java Experts on the State of Java

In a new article by yours truly, now up on otn/java, titled “Java Experts on the State of Java,” four Java experts, Adam Bien, Charles Nutter, Kirk Pepperdine and Simon Ritter, share their unique perspectives on what’s happening in the world of Java.

Consultant Adam Bien, winner of many awards and an expert in Java EE, remarks that, “Only a few years ago, Java EE was used mostly by larger companies—now it becomes interesting even for one-person shows.” He is also excited about Project Nashorn, which is coming in Java SE 8.

Charles Nutter, co-creator of JRuby and a Java Champion, observes that “JRuby seems to have hit a tipping point this past year, moving from ‘just another Ruby implementation’ to ‘the best Ruby implementation for X,’ where X may be performance, scaling, big data, stability, reliability, security, or one of several other features important for today’s applications.”

Java Champion Kirk Pepperdine, an expert in Java performance tuning, comments that, “The volume of data we’re dealing with just seems to be getting bigger and bigger all the time. A couple of years ago, you’d never think of needing a heap that was 64 GB, but today there are deployments in which the heap has grown to 256 GB, and there are plans for heaps that are even larger. Dealing with all that data simply requires more horsepower and some very specialized techniques. In some cases, teams are simply trying to push hardware to the breaking point. Under those conditions, you need to be very clever just to get things to work—let alone to get them to be fast. We are very quickly moving from a world where everything happens in a transaction to one in which you’ve lost if you even consider using a transaction.”

Finally, Oracle’s Java Rock Star Simon Ritter celebrates the Raspberry Pi: “I don’t think there is one definitive thing that makes the Raspberry Pi significant, but a combination of things really makes it stand out. First, it’s the cost: $35 for what is effectively a completely usable computer. OK, so you have to add a power supply; an SD card for storage; and maybe a screen, keyboard, and mouse, but this is still way cheaper than a typical PC. The choice of an ARM processor is also significant, because it avoids problems such as cooling (no heat sink or fan) and can use a USB power brick.”

Check out the article here.

Sunday Sep 30, 2012

The Java Specialist: An Interview with Java Champion Heinz Kabutz

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();

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();
    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.

Talking JavaOne with Rock Star Kirk Pepperdine

Kirk Pepperdine is not only a JavaOne Rock Star but a Java Champion and a highly regarded expert in Java performance tuning who works as a consultant, educator, and author. He is the principal consultant at Kodewerk Ltd. He speaks frequently at conferences and co-authored the Ant Developer's Handbook. In the rapidly shifting world of information technology, Pepperdine, as much as anyone, keeps up with what's happening with Java performance tuning.

Pepperdine will participate in the following sessions:

  • CON5405 - Are Your Garbage Collection Logs Speaking to You?
  • BOF6540 - Java Champions and JUG Leaders Meet Oracle Executives (with Jeff Genender, Mattias Karlsson, Henrik Stahl, Georges Saab)
  • HOL6500 - Finding and Solving Java Deadlocks (with Heinz Kabutz, Ellen Kraffmiller Martijn Verburg, Jeff Genender, and Henri Tremblay)

I asked him what technological changes need to be taken into account in performance tuning. “The volume of data we're dealing with just seems to be getting bigger and bigger all the time,” observed Pepperdine. “A couple of years ago you'd never think of needing a heap that was 64g, but today there are deployments where the heap has grown to 256g and tomorrow there are plans for heaps that are even larger. Dealing with all that data simply requires more horse power and some very specialized techniques. In some cases, teams are trying to push hardware to the breaking point. Under those conditions, you need to be very clever just to get things to work -- let alone to get them to be fast. We are very quickly moving from a world where everything happens in a transaction to one where if you were to even consider using a transaction, you've lost."

When asked about the greatest misconceptions about performance tuning that he currently encounters, he said, “If you have a performance problem, you should start looking at code at the very least and for that extra step, whip out an execution profiler. I'm not going to say that I never use execution profilers or look at code. What I will say is that execution profilers are effective for a small subset of performance problems and code is literally the last thing you should look at.

And what is the most exciting thing happening in the world of Java today? “Interesting question because so many people would say that nothing exciting is happening in Java. Some might be disappointed that a few features have slipped in terms of scheduling. But I'd disagree with the first group and I'm not so concerned about the slippage because I still see a lot of exciting things happening. First, lambda will finally be with us and with lambda will come better ways.”

For JavaOne, he is proctoring for Heinz Kabutz's lab. “I'm actually looking forward to that more than I am to my own talk,” he remarked. “Heinz will be the third non-Sun/Oracle employee to present a lab and the first since Oracle began hosting JavaOne. He's got a great message. He's spent a ton of time making sure things are going to work, and we've got a great team of proctors to help out. After that, getting my talk done, the Java Champion's panel session and then kicking back and just meeting up and talking to some Java heads."

Finally, what should Java developers know that they currently do not know? “’Write Once, Run Everywhere’ is a great slogan and Java has come closer to that dream than any other technology stack that I've used. That said, different hardware bits work differently and as hard as we try, the JVM can't hide all the differences. Plus, if we are to get good performance we need to work with our hardware and not against it. All this implies that Java developers need to know more about the hardware they are deploying to.”

Originally published on blogs.oracle.com/javaone.

Tuesday Oct 25, 2011

Perspectives on Garbage Collection

In a new article, part of the Developer Insight series, and titled “The Developer Insight Series, Part 6: Perspectives on Garbage Collection,” now up on otn/java, three leading Java developers offer insight into garbage collection.

Oracle Lab’s Ron Goldman notes, that, “Although automatic memory management has existed for more than 50 years, a lot of people still don't want it in their systems because it seems inelegant. It just strikes people as wrong – ‘It's my memory. I should be releasing it when I know it's no longer being used.’ Theoretically, that might be true, but in practice, programmers continue to forget to free up memory when they are done with it, or, even worse, try to free it up while it's still in use. The results? Buggy code that is apt to crash unexpectedly.”

Java Champion Kirk Pepperdine observes that, “Even though collection of very short-lived objects is almost free, high rates of object churn can still result in very inefficient GC numbers. Sometimes, the problem is simply that the Java Virtual Machine (JVM) doesn't have enough heap space. Monitoring GC activity will give you the hints you need for a successful heap-sizing exercise…”

And Oracle’s GC expert Tony Printesiz takes on eight myths about garbage collection, four of which are:

1. Reference counting GC will solve all my latency problems.
2. malloc and free will always perform better than GC.
3. Finalizers should be called promptly, as soon as objects become unreachable.
4. GC will eliminate all memory leaks.

The article provides a good context for developers to collect their thoughts about garbage. ;)

Read the complete article here.


Insider News from the Java Team at Oracle!

javeone logo


« April 2014