Summary: | Disassembler doesn't produce an output that can be compiled for enum types | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Olivier Thomann <Olivier_Thomann> |
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | jerome_lanneluc |
Version: | 3.2 | ||
Target Milestone: | 3.3 RC4 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Olivier Thomann
2005-10-04 14:20:42 EDT
I should also remove the "extends java.lang.Enum" as this is a syntax error for enum types to have a extends clause. See org.eclipse.jdt.core.tests.compiler.regression.ClassFileReaderTest.test079 for further details. For the working copy mode, we just need to be able to compile against the generated source. So if the constants are initialized with dummy values, this is fine. I released a fix that will cover the cases where the enum class doesn't have enum constants that need to implement some abstract methods. In this case, it is difficult to find out what needs to be done as I don't have all the info using a single class file. I would need to resolve interfaces and this is beyond the scope of a disassembler or I would need to access the .class file correponding to the anonymous. For a case like this, public enum X { BLEU(0) { public String colorName() { return "BLEU"; } }, BLANC(1) { public String colorName() { return "BLANC"; } }, ROUGE(2) { public String colorName() { return "ROUGE"; } },; static {} X(int i) { } private X(String s) {} abstract public String colorName(); } I would return: public enum X { BLEU(0), BLANC(0), ROUGE(0),; private X(int i) { } public abstract java.lang.String colorName(); } This won't compile because of the abstract method. I can detect abstract methods, and then add a default method stub for each constant. But I could also have this case: interface I { String colorName(); } public enum X implements I { BLEU(0) { public String colorName() { return "BLEU"; } }, BLANC(1) { public String colorName() { return "BLANC"; } }, ROUGE(2) { public String colorName() { return "ROUGE"; } },; X(int i) { } } where looking at X.class, I have no idea that I need to add a method for each constant as X.class has no abstract method. So the disassembler would need to be able to load other class files in order to generate the proper source. I added corner case in org.eclipse.jdt.core.tests.compiler.regression.ClassFileReaderTest.test080/81 We have the same kind of problem with member classes. E.g. public class X { class Member {} Member field; } In this case, X.class doesn't contain the signature for Member, but it should be generated. The API should then pass in the path to the .class file to disassemble, and the tool should retrieve the member class file to generate the source. Unclear if this should be on the disassembler, or a separate tool. Do we still want to fix this in the disassembler ? Closing as WONTFIX. |