We wanted to update the recoder library to the latest version, but unfortunately the there is no source release.
Do we have to extract them directly from SVN?
By the way: The documentation (recoder-0.82-apidoc.zip) could contain a file error: I cannot expand it. "End-of-central-directory signature not found"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I extracted the current source code from the svn and tried to compile it.
Unfortunately, it won't compile with neither Sun JDK1.6 nor JDK1.5.
The problem is the co-variance in the following return type relationship:
public interface Expression extends ProgramElement { Expression deepClone(); }
public interface LoopInitializer extends Statement { }
public interface Statement extends ProgramElement { Statement deepClone(); }
public interface ExpressionStatement extends Expression, LoopInitializer
{ ExpressionStatement deepClone(); }
which is currently not allowed (as it seems) by Java:
ExpressionStatement.java:17: types recoder.java.LoopInitializer and recoder.java.Expression are incompatible; both define deepClone(), but with unrelated return types
Can switch off this error message? Which compiler am I to use?
Double greetings (since I forgot them last time)
Mattias
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) The API-Doc is broken indeed. I've uploaded a working version, it should spread throughout the mirrors soon.
2) Since there seems to be demand, we'll provide additional source-releases (besides the binary and api-doc releases)
3) javac (up to 1.6.0_03) behaves differently from the built-in eclipse-compiler. I found this link (bug-report at forums.sun.com): http://forum.java.sun.com/thread.jspa?threadID=687004&messageID=3997641
but nobody from sun seem's to have investigated it. However, it links to a discussion at the eclipse-forums. Looks like the guys from eclipse follow the specification, and in my opinion it also makes more sense.
Unfortunately, I don't see a quick workaround besides using the eclipse compiler. Removing the declarations with the covariant return types will result in re-introducing a lot of explicit type casts...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi!
We wanted to update the recoder library to the latest version, but unfortunately the there is no source release.
Do we have to extract them directly from SVN?
By the way: The documentation (recoder-0.82-apidoc.zip) could contain a file error: I cannot expand it. "End-of-central-directory signature not found"
Hello again,
I extracted the current source code from the svn and tried to compile it.
Unfortunately, it won't compile with neither Sun JDK1.6 nor JDK1.5.
The problem is the co-variance in the following return type relationship:
public interface Expression extends ProgramElement { Expression deepClone(); }
public interface LoopInitializer extends Statement { }
public interface Statement extends ProgramElement { Statement deepClone(); }
public interface ExpressionStatement extends Expression, LoopInitializer
{ ExpressionStatement deepClone(); }
which is currently not allowed (as it seems) by Java:
ExpressionStatement.java:17: types recoder.java.LoopInitializer and recoder.java.Expression are incompatible; both define deepClone(), but with unrelated return types
Can switch off this error message? Which compiler am I to use?
Double greetings (since I forgot them last time)
Mattias
Hej,
1) The API-Doc is broken indeed. I've uploaded a working version, it should spread throughout the mirrors soon.
2) Since there seems to be demand, we'll provide additional source-releases (besides the binary and api-doc releases)
3) javac (up to 1.6.0_03) behaves differently from the built-in eclipse-compiler. I found this link (bug-report at forums.sun.com):
http://forum.java.sun.com/thread.jspa?threadID=687004&messageID=3997641
but nobody from sun seem's to have investigated it. However, it links to a discussion at the eclipse-forums. Looks like the guys from eclipse follow the specification, and in my opinion it also makes more sense.
Unfortunately, I don't see a quick workaround besides using the eclipse compiler. Removing the declarations with the covariant return types will result in re-introducing a lot of explicit type casts...