I have an issue with a legacy code base. I want to start compiling it with 1.6 class format, but there is one problem which reveals itself only when I try to run the compiled code. I get the following exception:
java.lang.ClassFormatError: Illegal class modifiers in class FooBar 0x209
Googling this doesn't reveal a lot of details. According to this the issue might be related to mismatch between interface and implementation modifiers. And of course, it must be some new restriction which wasn't in 1.5.
The problematic is class huge and has a lot of inner classes and inner inner classes so the problem is hard to track down (it's one of the inner classes I'm sure). Needless to say, the class doesn't have any tests either so changing it requires extreme caution and is laborous.
So, does anyone have any exact information about 0x209 - what does the code mean specifically?
EDIT:
Thanks to Arne bumping us into the right direction we were able to track down the issue and make a workaround. The root cause is not quite clear but now we can avoid it.
We are using Doug Lea's ancient util.concurrent package in certain areas because some components are running in environments which only provide Java 1.1 (yes, it 's quite alright to laugh, I don't mind).
This same code (using the concurrent utils) is also used as a small component of another related software. Since Doug's code used some 1.2 features, we were also forced to modify certain parts of util.concurrent to make it 1.1 compatible with Sun's 1.1 backported collections package (can't find the link to those any more). Somehow it has caused this peculiar Eclipse compilation behavior which occurs when we change the class format to Java 1.6. This is the minimum code which causes the problem:
EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap;
import com.sun.java.util.collections.Map;
public class FooBar
{
public static void main(String[] args) {
Map.Entry e = (Map.Entry)(new ConcurrentHashMap().entrySet().iterator().next());
}
}
After you compile this with Eclipse (with compilation set to 1.6, 1.5 works fine) and try to load the class from Sun's 1.6 JRE the problem occurs. The workaround: instead of looping through entries, we loop through keys and get values inside the loops with the keys.
Our setup here is so exotic that no wonder nobody else has bumped into this. I finally checked our build scripts and lo and behold, the ant-script has 1.6 source and target-settings. So apparently this is Eclipse-specific.
EDIT2:
I Looked closer to the Sun bug report I have linked here. The problem there is also related to com.sun.java.util.collections.Map.Entry. And that occurred with Sun's Javac. Interesting.