[Coco] [Color Computer] Java for the m6809

[James Diffendaffer]

--- In ColorComputer at yahoogroups.com, "John W. Linville"
<linville at ...> wrote:
>
> Did you read the paper at all?  Or could you not be bothered?

What, the document file that says it only implements a subset of Java
and the "os" only has a handful of functions you can use?

Everything I said is true and without some sort of native API it's not
much use unless all you want to do is simple prints and file I/O which
isn't even CoCo compatible.  At least with C you can directly
implement hardware I/O without having to create a native API in
assembly.  EVERYTHING you access on an individual system has to be
done with a native API when you program in Java.  Java does not allow
direct access to memory so you have to write that in assembly or C.

> If you only care about practical computing, why on earth are you
> reading this list?

Look... you even admit you aren't a Java person, but I am.  It's not
even practical for impractical computing like the CoCo.
The whole portability aspect of Java (probably it's biggest selling
point) is non-existent.  This doesn't even support a full enough
implementation to run as much as that Java ring that was given away at
trade shows.

Now, if it supported a full implementation of Java SE it might be
usable but as is you really can't do much with it and certainly not
for the coco.  Definitely not as much as GCC.

To be honest, GCC has supported compiling Java to native code for
years as long as the target code generator was written to work with
the entire compiler suite.  If the 6809 code generator for GCC does
that then I'm sure it would offer a much more complete implementation.  

I should also point out that Java code generated by a byte code
compiler is going to be less efficient than that of a direct native
compiler because it expects to be run on a bytecode interpreter.  Some
bytecode operations are illegal because they would step outside the
sandbox created for the Java application for security purposes.  If
you are compiling a native executable you don't need to worry about
the sandbox security and you could optimize the code further.

The only reason I can see for taking their approach is because it
would be easier to convert bytecodes to assembly than implement a full
compiler.

> So, will you be able to run "Fantastic Java-based Desktop App 2.7"
> on your MultiVue desktop?  Of course not.  So what?
> Might you be able to write something new?  Using a modern language and
> development tools?  To ultimately run something on your coco or similar
> hardware?  I don't see why not, other than laziness or disinterest...

You obviously don't even know enough about it to comment and you want
to jump all over me for pointing out obvious flaws with the project.
You aren't going to be able to write games with it, you can't write
business applications with it, and you can't even write the simplest
tools with it the way it is.  

> Is your reflexive pessimism helpful to the group?  No.

Reflexive pessimism?  Oh, that makes an expert now doesn't it.
At least know what you are talking about before jumping on someone
that actually does!
Is your uninformed ranting useful to the group?  No.