Monthly Archives: September 2006

Type resolution in JVM specification

The JVM spec covers the following details about the lifecycle of a program:

  • VM start up
  • class and interface loading
  • linking
  • initialization
  • creation of new class instances
  • unloading of classes
  • VM exit

In this entry, we are interested in detailing how JVM is handling type resolution. Having the following code:

public class EntryPoint {
 public void someMethod() {

import not.on.classpath.SomeClass

public class ExternalDependencyClass {
 public static void callMethod() {
   SomeClass cls= new SomeClass();
   // [...] work

We are interested in finding out if the spec describes the behavior of the above code when the SomeClass is not found on the classpath (though the compilation was correctly performed).

So, the class EntryPoint is loaded, and it must be initialized before it can be invoked, and a type (class or interface) must always be linked before it is initialized.

Linking step involves:

  • verification: checks if the loaded representation is well formed, has a proper symbol table, the bytecode obeys the semantic requiremetns of the JVM
  • preparation: involves allocation of static storage and any data structures that are used internally by the virtual machine, such as method tables.
  • resolution (optional)

Resolution is the process of checking symbolic references from the loaded class to other classes and interfaces, by loading the other classes and interfaces that are mentioned and checking that the references are correct.

The resolution step is optional at the time of initial linkage.

An implementation may resolve a symbolic reference from a class or interface that is being linked very early, even to the point of resolving all symbolic references from the classes and interfaces that are further referenced, recursively. (This resolution may result in errors from further loading and linking steps.)

This is an eager or static resolution implementation. There is also possible to do the resolution in a lazy way:

An implementation may instead choose to resolve a symbolic reference only when it is actually used; […]. In this case, if the class had several symbolic references to another class, the references might be resolved one at a time or perhaps not at all, if these references were never used during execution of the program.

If the JVM implementation has chosen to use the eager/static type resolution strategy than an exception will be thrown before the program is executed. For the “lazy” type resolution JVMs, an exception will be thrown if and only if the symbolic reference is used.

Now, you may wonder what is the solution. The only approach that will work in any JVM disregarding how the JVM implements the type resolution is to load the classes containing unsatisfied dependencies at the moment the execution needs them through reflection (for example if you are developing a library/framework than you will always have to do it this way because you don’t know on what JVMs the library will be used). But, if you are developing an application that is known to run only on a JVM that used the “lazy” type resolution strategy than the initial code is safe.

As a final note, SUN JVMs (at least 1.4 and 1.5) are using the lazy type resolution strategy.


Leave a comment

Filed under Uncategorized

Eclipse API and Code Folding

One of the my first open source projects I have worked on was Coffee-Bytes code folding plugin. It happened a long time ago and at some point the development has been discontinued.

However, tonight, working on some very long sources I have remembered it and I said I should give it a new try. Unfortunately, once I enabled it no editors could been displayed. Checking the .log file I have found the reason: the folding code was broken with a NoSuchMethod exception.

I have found in my archives the last version of the plugin and I thought I should check the API. To my surprise the API was still available (or at least reachable), but what made me post this entry is a feature added in Eclise 3.1: Access Restrictions, according to which when you create a plugin you can restrict others plugin access to its code. While I find the idea quite good (as it makes the API more clear), I have found out that almost everything related to java source code editors is restricted, and I am wondering why? I thought some other plugins would benefit from a clear API (for example AJDT), and now finding this makes me wonder about the reasons (I am quite sure there are good reasons).

However, getting back to the points of this entry, you can read more about Access restrictions: here.

Following the last advise specified at the above link:

But what if you really, really, really, really need to use the class? In that case, you can use it, but you need to be aware of what it means (four really’s usually does it for me).

I have done some small changes to readapt the code and now I have again Coffee-Bytes code folding working on Eclipse 3.2. Just look at the picture to see how reach it is compaired with the default code folding offered by Eclipse:

Reach Eclipse Code Folding

It offers you folding for:

  • top level types
  • normal methods
  • constructors
  • getters and setters
  • main methods
  • inner types
  • static initializers
  • import statements
  • source headers
  • comment blocks
  • javadocs

and even User defined code folding:

User defined code folding



Filed under Uncategorized

TestNG revamped support for JUnit

I have spent a couple of hours this weekend on a new approach to running JUnit 3.x tests in TestNG

Previously, we have tried to emulate through TestNG the behavior of JUnit and things were quite complex. Also, considering how many extensions are there for JUnit we have never been sure we are able to run all existing JUnit tests.

So, I decided to give it another try and see if I can come out with a better approach. And instead of trying to emulate JUnit runtime behavior, I thought I can handle JUnit tests to JUnit itself and just make it report back the results. After a couple of hours of hacking I got it working and right now I think we will be able to run an even bigger percentage of existing JUnit code. And as a validation of the changes, I have run not only the TestNG tests (almost 300), but also JUnit internal tests (131) and all passed.

This new revamped support for JUnit will be released in the next version, but if you want to challenge it please feel free to build it yourself from the SVN trunk (or drop me an email) and put it to extensive work.


Filed under Uncategorized