RECODER FAQs

Troubleshooting

Q:

My compiler seems to have problems with SourceElement.Position

A:

Compilers that work correctly are jikes or javac. You might also want to help your compiler by providing (redundant) public static modifiers in front of the member class declaration (IBM Visual Age), or the fully qualified name if the name resolution fails (Inprise JBuilder).

Q:

There are lots of deprecation warnings during compilation.

A:

Usually, compilers will not report deprecation warnings. You can safely ignore them; we use the @deprecated tag to mark unfinished, "risky" methods that custom applications should avoid. These methods will be removed or refined in later versions.

Q:

RECODER does not seem to find a file which is in the search path?!

A:

The file name might be expanded into an absolute path. Currently, the repositories handle relative file names only. Simply add the system root to your search path ("/." for Unix systems).

Design Questions

Q:

Why did you introduce that many lists?

A:

Java did not provide parameterized (generic/template) types at time of development and we felt the need to provide type safe containers in public interfaces. The pattern applied here provides us with a workaround.

Q:

Why are the java.util.Collection classes not used for Lists, Sets and so on?

A:

Two reasons: First, at the time of writing, there was no recommendable JDK available for the primary development platform Linux, so we had to remain compatible with JDK 1.1. Second, our implementations require significantly less memory and are - for most objects - faster than the standard implementations. Unfortunately, the Collection interfaces are not trivial to support by now, so no attempt was made. This is partly due to the underlaying implementation; for instance, iteration over entry pairs for instance would never become very efficient as we use a different layout internally. Lists are clearly not really compatible, even though one could attempt to make ObjectMutableList a subtype of java.util.List.