JDK7 doesn't seem to play nice with Spring 3.0.5 out of the box.

I did my testing on an installation of Ubuntu running in a VM on my Mac. I've done this before running JDK6 and Eclipse Helios (3.6) or STS, so I know it works. I did a clean install and update of Ubuntu, so there's just the OpenJDK also installed, and not any conflicting copies of Java or Eclipse or anything else. I've done this tons of times, so I'm pretty sure I'm not doing anything wrong with this.

I excitedly downloaded the new JDK7 from Oracle, and the new Eclipse Indigo (3.7), well, from Eclipse. They seem to play nice together, in that starting Eclipse with JDK7 as its VM seems to work.

I configured my eclipse.ini to use the new JDK, adding the "-vm /path/to/jdk1.7.0/bin/java" lines to file, in the right spot. Starting Eclipse doesn't evoke an error (as you'd expect getting it wrong), and digging through the Help menu to the installation details shows the line in the INI is found, and that the Java version reported is indeed 1.7.

I added the Polaron Subversion and EclEmma plug-ins from the Eclipse marketplace. After some restarting (because of the installations), I pulled a known-to-be-working in JDK6 Spring project from my SVN repository.

The project requires Tomcat, so I pulled down both the latest Tomcat v6 (which it used before) and also Tomcat v7 (I figured I'd stir everything up and see what that did, too). The version of Tomcat doesn't seem to affect my code, in as much as it compiles without complaint for either version.

The project uses (and includes the JARs in old-school fashion) Spring (v3.0.5), Hibernate (v3.6), some Apache Commons stuff, and whatever requirements those packages have. Pretty straight-forward stuff. Other than affecting the SVN-provided Eclipse project files, to support the change in Tomcat path and JDK runtime, no changes were made to the project for this simple test. The project compiled without a complaint. The updated Eclipse even found an HTML failure (there is no <spanclass> tag that the previous one missed.

Running the JUnit tests proved to be much less successful. As has always been done, I right-clicked on my test source folder and selected Run As and JUnit Test from the menu, and waited. The JUnit view appeared, as expected, but then every test failed. Two distinct failures are given.

In the console every test fails with this warning:

ERROR TestContextManager.prepareTestInstance - Caught exception while allowing TestExecutionListener [org.springframework.test.context.support.DependencyInjectionTestExecutionListener@11d5422] to prepare test instance [MYCLASS.SNIPPED.FOR.BREVITY@1efdf93] java.lang.IllegalStateException: Failed to load ApplicationContext at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:308)

In the JUnit view, each test fails at the same Spring injection warning:

java.lang.IllegalStateException: Failed to load ApplicationContext at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:308)

A little deeper we see the more likely culprit:

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#0' defined in class path resource [WEB-INF/applicationContext.xml]: Cannot resolve reference to bean 'envProps' while setting bean property 'location'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'envProps' defined in class path resource [WEB-INF/applicationContext.xml]: Instantiation of bean failed; nested exception is java.lang.VerifyError: Expecting a stackmap frame at branch target 11 in method MYCLASS.SNIPPED.FOR.BREVITY.()V at offset 4 at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:328)

This is something new to me. I was not entirely sure what the cause is, so I did a little research with my all-knowing friend...Google, of course. I could see that the problem had to do with autowiring my class, but the "stackmap frame at branch target" part had me, so I had to dig deeper.

It seems that the underlying bits and pieces of Spring and its associated requirements (notably in this point, asm), is not up to snuff with the latest JDK. Of course, it's probably a simple case of crossing that Java version boundary. JAR files seem to have some magic that help with that, but it does happen where the occasional old-enough JAR won't work with the newer JDK. That's probably what's happening here. Once someone releases these JARs compiled with JDK7, the problem will probably go away.

In the meantime, there's plenty to play with. I'll check out Eclipse Indigo (3.7) running on JDK6 in a little bit. I'll also dig into the new stuff in JDK7 and see where that might start pushing new projects.