| An apparent bug in the Eclipse compiler for Java 8 [message #1733783] |
Tue, 31 May 2016 18:34  |
 Erika Redmark
Messages: 22
Registered: January 2013 |
Junior Member |
|
|
I'm currently facing a very odd bug; whenever I clean, or export my RCP project, a specific class file fails at runtime: (Eclipse Luna),
java.lang.ClassFormatError: Illegal class modifiers in class <company>/component/model/tree/ProjectStructure: 0x4419
This is a basic class, not an enumeration or abstract as those modifiers might indicate, and the 9 shouldn't be there at all. The only thing right about that is the final modifier. This happens only when I do a clean, or export my RCP project. The class itself is broken to the point that neither a decompiler nor a bytecode editor recognise it.
If I change anything in the class and save then run, the error goes away. It's like the incremental compiler is working, but when compiling from scratch it fails. I have no idea why; I've been aggressively commenting out methods trying to find out what is specific about this class that is causing the issue. I've had this issue before and ended up redoing the class in groovy just to avoid the error. I can't do that again with this one.
I am using a Java 8/Groovy project with Lombok. The last time I encountered this same issue I was not using Lombok, so I do not believe it has anything to do with this; other classes with Lombok have no issues. I'll try to figure out what is triggering the issue, but in the mean time has anyone else encountered this or have any ideas on how to stop it?
|
|
|
|
| Re: An apparent bug in the Eclipse compiler for Java 8 [message #1733790 is a reply to message #1733784] |
Tue, 31 May 2016 21:49  |
Erika Redmark
Messages: 22
Registered: January 2013 |
Junior Member |
|
|
I finally figured out what was happening; there was a type that if I used it in any way in a Java class, that class would fail with that message... but the root error was with the type. Having said that, I must confess the type was written in Groovy, so I am not sure if said type's semantics can be replicated in Java.
I had (names changed and irrelevant info removed) in groovy...
class Something implements Nameable {
....
enum InnerEnum {
TYPE_1 {
@Override ImmutableList<SomeCustomRawType> method(Something s) { ... }
},
TYPE_2 {
@Override ImmutableList<SomeCustomRawType> method(Something s) { ... }
}
abstract ImmutableList<SomeCustomRawType> method(Something s)
}
}
I do not know if there was an issue with the type in the generics (it was technically a raw type, and I've since completely removed the need for that, in hindsight, rather stupid enum). Using this particular class InnerEnum from anywhere in any Java 8 code was a disaster, but groovy code had no issues. I also notice that the bad specifier includes enum and abstract, both of which are present here.
Whether the enum needs to be declared in another class, whether it has to have one abstract method that refers to said inner class, whether SomeCustomRawType can be replaced with anything (or whether ImmutableList<SomeCustomRawType> can be replaced with anything), whether the number of instances defined has something to do with it, I do not know. At the very least I was able to pin it down to a specific problem class that caused problems not with itself, but with any users of the class in pure Java 8 code. Additionally, the location I encountered this bug before and had to rewrite the class in Groovy? That was the only other other-wise Java class I had this same issue with. So I can confirm there is something about what Groovy does to that enum that, when used in ANY way in Java 8 code, even just assigning InnerEnum.TYPE_1 to some variable, causes the compiler to fail to compile only on an initial build after clean.
The good news at least is that once I found the issue and I cleaned after every run, I was able to find that the bug appeared deterministically, so I could control and predict when it would/would not occur. Also good news Lombok has nothing to do with it.
The only open question now is; can however that type was processed by groovy reproduced in Java for the same effect? That I do not know. I'll go ahead and keep tabs on this topic. If you need any further information, I can always look up how the old code was and answer them, although it is company code so I can't freely give it out, sorry.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03060 seconds
] 
Search
Help
Register
Login
Home
