Weird scenario with Hibernate query

As some of you (the JavaZone participants) may already know, on InfoQ we are using both Jackrabbit JCR implementation and Hibernate for persistence (we are trying to put the data where it belongs [smile/]). As always Hibernate is doing a great job and I am very happy with it. We have enabled second level cache and also the query cache (using EHCache because due to our architecture we don't need clusted caching) and the performance we get is really cool. However, lately one of my collegues has pointed me that something weird is happening: a stored entity which should be refreshed only after X hours, is getting refreshed much more often. Now, I thought this is really weird. Even worse, this is happening only in some very specific scenarios. So, I started to look into the problem. The cache configuration is correct as everywhere else I see the expected behavior and the code snippet I've identified as being the cause of the problem is classical:

return session.createCriteria(CategoryDef.class)
             .add(Expression.eq("alias", alias))
             .setCacheable(true)
             .setCacheRegion("CategoryDef.QueryCacheFindByAlias");

So what's going on? The secret of the problem I was looking into is that the cache region CategoryDef.QueryCacheFindByAlias was missing from the ehcache.xml (the special EHCache configuration file). Because of this, once this region/cache should have been used, a new cache with the specified name was created... based on the properties of the defaultCache. The tricky part was that I would have expected that the new cache to be created using the org.hibernate.cache.StandardQueryCache (the query cache), but my initial thoughts were definitely wrong, this region being used only for the unnamed/anonymous cached queries, all others being considered normal cache regions. The way I figured it out was even more interesting: doing a debug session I have noticed that in case of a cache miss, the query went to DB and retrieved the whole entities without checking the second level cache (still it is checking against the current Session cache). And this was the point that made me think that in fact I am looking at a normal region (derived from the default) and not to a special one. To confirm my supposition, I have checked the Cache configuration and indeed the parameters were the ones defined into the defaultCache.

category: Hibernate, Data Access, Java Content Repository, Jackrabbit

Subversion 1.4 breaks existing Eclipse SVN plugins

This evening I had a horid surprise: after upgrading my SVN client (TortoiseSVN) to version 1.4.0 which supports the latest subversion (same 1.4.0) and committing some folder level properties, I was starting to see that some projects in my Eclipse workspace were not anymore recognized as SVN projects. As I do these activities more or less without paying too much attention, I've found myself bitching around quite soon (and I've even hadn't known who to blame) When checking the Subversion 1.4.0 Release Notes the following fragment explained everything:

Due to certain improvements and bugfixes made to the working copy library, the version number of the working copy format has been incremented. This means that Subversion clients earlier than 1.4 will not be able to work with working copies produced by Subversion 1.4. Similarly, the repository format has changed as well, meaning that pre-1.4 Subversion tools that normally access a repository directly (e.g. svnserve, mod_dav_svn, svnadmin) won't be able to read a repository originally created by Subversion 1.4. WARNING: if a Subversion 1.4 client encounters a pre-1.4 working copy, it will automatically upgrade the working copy format as soon as it touches it, making it unreadable by older Subversion clients. If you are using several versions of Subversion on your machine, you need to be careful about which version you use in which working copy, to avoid accidentally upgrading the working copy format. This "auto upgrade" feature, however, does not occur with the new repository format.

So, both SVN Eclipse plugins (or at least the two I know): Subversive (the one I am using) and Subclipse are now screwed because none of them has yet incorporated the new Subversion release. My advise: if you are an Eclipse user and you want to upgrade your SVN client, wait for the plugins to be upgraded themselves, because otherwise you will not be able anymore to work with SVN from within Eclipse.

category: Eclipse,Source Control,Subversion,Artifacts & Tools

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() {
   ExternalDependecyClass.callMethod();
 }
}

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.

Reference:
• Loading, Linking, and Initializing

category: JVM

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: 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:

category: Eclipse

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.

category: Software Testing, Testing, TestNG