[coyotos-dev] Accept GCJ into the tool chain?

[Jonathan S. Shapiro]

On Mon, 2006-11-27 at 11:48 +0000, Sam Mason wrote:
> I'd be interested in knowing what you see Java being used for.  Your
> original email mentioned application development and you just mentioned
> the build chain now.  Java for application development I can see as
> a good thing, but wouldn't something ML or Haskell be good for the
> build/tool chain?

Let me back up on the Java question and explain where this is coming from.

I'm interested in Java from three perspectives:

1. As an application language for general users. I don't intend to use
it this way, but it will be important to some customers and sooner or
later we need to support it. In addition, we will ultimately need to run
some things that use Java as an embedded language, so eventually we need
Java no matter what. HOWEVER, this is a long-term issue, and not one
that should influence our development path right now.

2. As a language for writing utility domains, where the domains are
"sealed" (all symbols resolved at compile time, no run-time class
loaders) and the code is **statically compiled**.

In this context, the role of Java is mainly to provide memory safety.
BitC would be my first choice here, but it isn't mature enough yet.

Note that I'm not stuck on Java per se here. What I'm after is a safe
programming language that can be used to write domain code that is not
performance critical. Other languages, including C#, ML, Haskell, or
even Scheme, would meet this goal. While ML and Haskell are great
languages, I rule them out mainly because of the lack of programmers who
know them. I would frankly prefer C# to Java, but I don't see a stable
statically compiled implementation that is available *today*.

Another alternative would be D, but that also has the problem of a
limited pool of programmers.

3. As a language for crafting some of our cross-development tools [this
is the immediate issue]. For example, mkimage could very quickly be
moved to Java and this would allow us to stop worrying about memory
management and adopt a reasonable exceptions model, which would be very
helpful. This is actually an area where I would *really* prefer BitC.

And I should acknowledge that the two main candidates here: mkimage and
capidl, are both tools where exit() is probably the correct
implementation of GC. Neither program generates much garbage, and both
programs hang on to most of their state until they exit.

Today, we are relying on the Boehm collector for both of these, and that
appears to be working. I am very nervous about this, because porting the
Boehm collector is difficult and the collector itself is not always
predictable in its behavior.


So let me back up here:

For things like compilers, where GC and exception handling are extremely
useful, what languages are people using that I may be failing to
consider?


shap