Bug 111494 - Disassembler doesn't produce an output that can be compiled for enum types
Summary: Disassembler doesn't produce an output that can be compiled for enum types
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.3 RC4   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-04 14:20 EDT by Olivier Thomann CLA
Modified: 2007-06-22 05:40 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Thomann CLA 2005-10-04 14:20:42 EDT
The following code doesn't produce an good output that can be recompiled:

public enum X {
	BLEU(10),
	BLANC(20),
	ROUGE(30);

	X(int i) {}
}

The output is:

public final enum X extends java.lang.Enum {
  
  public static final X BLEU;
  
  public static final X BLANC;
  
  public static final X ROUGE;
  
  private static final X[] ENUM$VALUES;
  
  static {} {
  }
  
  private X(java.lang.String arg0, int arg1, int i) {
  }
  
  public static final X[] values() {
    return null;
  }
  
  public static final X valueOf(java.lang.String arg0) {
    return null;
  }
}

The problems are:
- synthetic methods are present and should be removed.
- enum constants should be separated with commas
- a semi-colon should follow the enum constants
- enum constants should get theirs initialization.

I can fix the first three items, but I don't see how to retrieve the
initialization for each enum constants as this is located in the clinit method.

I might be able to look for the constructor to find what argument is needed for
each enum constant, but I would then put a default value.
Would this be good enough?
Comment 1 Olivier Thomann CLA 2005-10-04 14:21:46 EDT
I should also remove the "extends java.lang.Enum" as this is a syntax error for
enum types to have a extends clause.
Comment 2 Olivier Thomann CLA 2005-10-04 14:22:24 EDT
See org.eclipse.jdt.core.tests.compiler.regression.ClassFileReaderTest.test079
for further details.
Comment 3 Jerome Lanneluc CLA 2005-10-05 04:27:54 EDT
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.
Comment 4 Olivier Thomann CLA 2005-10-05 15:18:50 EDT
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. 
Comment 5 Olivier Thomann CLA 2005-10-05 15:26:10 EDT
I added corner case in
org.eclipse.jdt.core.tests.compiler.regression.ClassFileReaderTest.test080/81
Comment 6 Jerome Lanneluc CLA 2005-10-06 09:47:03 EDT
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.
Comment 7 Olivier Thomann CLA 2007-02-19 09:31:47 EST
Do we still want to fix this in the disassembler ?
Comment 8 Olivier Thomann CLA 2007-06-21 12:57:59 EDT
Closing as WONTFIX.