Classloaders are one of those subjects that affect every Java developers’ daily life, but aren’t necessarily something that most people understand to the core. The fact that you’re interested in this, my friend, makes you an exception to the rule. Luckily, our CTO Jevgeni is as well, and he regularly eats classloaders for breakfast. The great folks from Jazoon 2010 in Zurich have recently made his “Do you REALLY get class loaders?” presentation available, which we’re happy to share with you below. Jevgeni has also previously written a series of articles on class loading that you can read at your leisure. If you want to see the video stream and the slides at the same time, click anywhere other than the “Play” button and you will be taken to the Parleys website (which also happens to have lots of other great presentations).

And hey, since you’re already here, why not see how JRebel handles classloaders first hand?

Here’s the presentation abstract:

Class loaders are at the core of the Java language. Java EE containers, OSGi, NetBeans modules, Tapestry 5, Grails and many others use class loaders heavily. Yet when something goes wrong, would you know how to solve it? In this session we’ll take a tour of the Java class loading mechanism, both from JVM and developer point of view. We’ll see how different delegation systems are built, how synchronization works, what is the difference between finding classes and resources, what wrong assumptions has been made and are now supported. Next we will look at typical problems that you get with class loading and how to solve them. ClassNoDefError, IncompatibleClassChangeError, LinkageError and many others are symptoms of specific things going wrong that you can usually find and fix. For each problem we’ll go through a hands on demo with a corresponding solution. We’ll also take a look at how and why classloaders leak and how can you remedy that.

Hey folks!

Next week we’re happy to be a part of a webinar with the great team over at MuleSoft, and we wanted to extend the invite out to all of you! Using JRebel together with TCat makes life a lot easier for Tomcat users, so take this chance to learn more and register for the event!

~~
Do you ever ask yourself these questions: “Can I eliminate the redeploy phase from Tomcat’s development cycle? How can I more efficiently diagnose performance bottlenecks in my Tomcat application? How can I simplify configuring Tomcat for my application?”

Tomcat users spend 160 hours per year waiting for redeploys, not to mention the time getting back into the flow of coding. They also spend quite a bit of time configuring Tomcat for deployment to production, and investigating and resolving performance and availability issues — without deep diagnostic data.

In a webinar on July 28th at 10am PT, MuleSoft and ZeroTurnaround have teamed up to provide web application developers using Tomcat with the ultimate “one-two punch” for developer productivity.

Register now!

Join us for a 45-minute demo-driven webinar, where you will see how JRebel and Tcat Server can help you:

* Instantly see the effects of your code changes without having to restart Tomcat
* Discover and quickly resolve performance issues with deep diagnostic capabilities
* Visually browse and edit Tomcat configuration files

Speakers:
Sateesh Narahari, Director of Product Management at MuleSoft
Toomas Romer, Co-Founder, Lead Developer at ZeroTurnaround

Logistics:
Date: July 28, 2010
Time: 10am PT / 1pm ET / 7pm GMT (find your time zone)

About MuleSoft:
MuleSoft is the Web Middleware Company, providing enterprise-class software based on the world’s most popular open source application infrastructure products, Mule ESB and Apache Tomcat. MuleSoft brings an ideal combination of simplicity and power to today’s web applications with Mule ESB, Tcat Server and iBeans. MuleSoft’s products boast more than 1.5 million downloads and over 2,500 production deployments by leading organizations such as Walmart.com, Nestlé, Honeywell and DHL, as well as 5 of the world’s top 10 banks. MuleSoft is headquartered in San Francisco with offices worldwide.

About ZeroTurnaround:
ZeroTurnaround builds technologies that make the Java platform more productive: both for development and production. Our Rebel technology integrates directly into the JVMs, application servers, and development tools that most teams use – making them more competitive. JRebel saves Java EE developers between 3-7 weeks of wasted development time (yup; 40-hour workweeks), has been downloaded hundreds of thousands of times, and pays for itself in under a week. Our customers are the who’s who of the finance, web application, and technology industries, including most global banks plus the Bank of America, American Airlines, Lufthansa, LinkedIn, HP, Siemans, Logica, Kayak, Oracle, IBM, and more. For rolling out or rolling back upgrades to live applications instantly, check out LiveRebel, in private beta now.

This is a story of an interesting support request handled by our guru Lauri Tulmin. The inquiry was about a rare occurring ArrayIndexOutOfBoundsException that JRebel seemed to cause in Wicket. After some investigation he discovered that the root exception was thrown from the following Wicket code:

private final Map<IModifiable, Entry> modifiableToEntry = 
   new ConcurrentHashMap();
 
  public void start(Duration pollFrequency) {
    this.task = new Task("ModificationWatcher");
 
    this.task.run(pollFrequency, new ICode() {
      public void run(Logger log) {
        Iterator iter = new ArrayList(
          ModificationWatcher.this.modifiableToEntry.values()).iterator();
        while (iter.hasNext())

Specifically the exception was thrown from the constructor of ArrayList. How was that possible?

Let’s take a step back and review the reasons for this code. One issue with collections is that when iterating a ConcurrentModificationException is thrown if a collection is changed (usually by a different thread). This is done to protect the Iterator from unpredictable behaviour. A common idiom to avoid it is to copy the collection before iteration like that:

for(Iterator i = new ArrayList(collection).iterator(); i.hasNext();) {...}

Note that the collection must either to be synchronized or otherwise suitable for a multi-threaded environment.

This idiom is a very common one, as easily proven by a simple Google Code search. In fact we used it several times in the JRebel code and is present in several places in Wicket as well. So how could this cause an ArrayIndexOutOfBoundsException?

When Lauri investigated in depth he found out that this idiom is inherently unsafe in a multi-threaded environment (even when the underlying collection is synchronized!). The reason for that is the way ArrayList was constructed before Java 1.6. In my 1.5 Java SDK source code it looks like this:

public ArrayList(Collection<? extends E> collection) {
  int size = collection.size();
  firstIndex = 0;
  array = newElementArray(size + (size / 10));
  collection.toArray(array);
  lastIndex = size;
  modCount = 1;
}

The issue is that there is a race condition between the time the size is recorded and the collection.toArray(array) is called. During that time it is conceivable (and indeed possible) that the size of the collection is changed by a different thread. If the size is now bigger, the array copying in toArray() fails with the dreaded ArrayIndexOutOfBoundsException. When researching the issue further we found that the constructor in Java 1.6 ArrayList has been changed to avoid this issue, so at least on Oracle Java 1.6 or later you are safe. Unfortunately I couldn’t find a specific bug referring to that issue, so likely as not it’s an accidental fix.

So what should you do to avoid this issue? One way is to put the synchronized block around the whole loop, but this requires that you only access that collection from other threads in the same synchronized block. An easier solution is to use the toArray()method like this:

for (Iterator i = Arrays.asList(collection.toArray()).iterator(); i.hasNext();)