using gcj for a different language - is it possible?

Florin fmateoc@mfire.com
Wed Dec 31 21:41:00 GMT 2003


Hi all,

I hope this is not too off-topic for this list.
I have been toying with the idea of getting Smalltalk compiled ahead of time
like Java is (when compiled with gcj).
The two langages are very similar from many non-syntactic points of view:
stack-based bytecodes, single inheritance, garbage collector, bounds-checked
arrays, (green) threads, all the functions are methods attached to classes,
dynamic lookup, dynamic code loading, large class library.
Because of all these similarities I thought of trying to use the Java
front-end.

Hopefully some of you can help me figure out if this plan makes sense or
not:

1. I would first generate from Smalltalk the source files in Java
source or class format. I am not sure which would work best. Source format
would have the advantage that one could get the sources in better shape by
first getting them to be compiled to byte-codes, so we would not create bad
class files. Direct class files creation would be easier because the byte
codes map pretty well.

Now, the base class libraries being substantially different, I was wondering
if it is possible to use gcj without the base classes implementations from
libgcj, and reading instead all the base classes from class files, therefore
String or Exception for example ending up in a different place in the class
hierarchy.
Is there a list of base classes that are known to the runtime, and what
exactly is known about them?
Obviously, I would still want to use the garbage collector, the thread
switching provided by the runtime, as well as the runtime generated
exceptions (which are very similar).
I assume there might be problems with the security mechanism, which does not
exist in Smalltalk, as well as exception handling, because in Smalltalk
handling an exception does not necessarily unwind the stack, the operation
triggering the exception may (for example) be retried with a different
argument.
Hopefully, these could be dealt with in a mini-libgcsmalltalk that would
also implement some of the base native methods.

2. Almost all the method calls would have to be interface calls (based on an
idea from Per Bothner's note about translating Smalltalk to Java), with
almost every method being declared in a separate interface. I don't know how
well gcj would handle potentially huge numbers of interfaces implemented by
many classes.
I wonder if this approach would allow me to get away without doing any type
inferencing. Smalltalk is not statically typed, so there would be basically
no type information available, everything would be Object except when cast
to the above-mentioned interfaces. Given that there are no interfaces in
Smalltalk, all the interfaces in the system would only mean "implementing a
certain selector", so the bad cast exception would map perfectly to
Smalltalk's runtime generated MessageNotUnderstood.
The question is, could the compiler do my work for me, or should I try to
help it by first doing some type inferencing?

3. One significant difference in the Smalltalk object model is that classes
are real objects that in turn have their own class and dynamically looked-up
methods.
Is it possible for the object type information to point to another object? I
would prefer to avoid modifying the object layout, which is probably known
to the garbage collector.
Alternatively, I could add an instance variable to Object pointing to the
class object, but that seems heavy-handed and would be disconnected from the
type information.


There are probably more issues that I missed, but one other thing that I
remember right now is: does gcj support weak references ?


Thank you in advance for your insights and I wish you all a Happy New Year !

Florin




More information about the Java mailing list