GCJ/libgcj capabilities

[Jeff Sturm]

(catching up on my email after vacation...)

Daniel P. Zepeda wrote:
> Matt Welsh wrote:
> > Can you say "vendor lock-in", boys and girls? Oh, wait a minute -- I thought
> > Java was supposed to *eliminate* vendor lock-in? Boy am I confused.
> 
> I'm not.  I've thought for a long time that there would be these sorts of
> issues come along. It doesn't make economic sense for Sun to create this
> platform without maintaining some type of hold on it, to make their money.
> After all, Sun is just another big corporation. This "write once, read
> many" idea, although technologically possbile -- if not difficult -- is
> just so much marketing swill.

"Write once, run anywhere" has worked for me, provided I stick with a
subset of Java technology and don't use non-portable assumptions (e.g.
relying on thread priorities to actually work).

Though I am an avid Java developer, I appreciate the language mostly for
what it was in the 1.0 days... fully object-oriented, garbage-collected
and multi-threaded.  Most of what Sun has added since 1.0 is code
bloat.  They wrote lots of incomplete, partially implemented
specifications in a failed attempt to convince the industry that Java
can be all things to all people.

Incidentally, my production systems are still based on JDK 1.1.x, and I
haven't yet begun to use 1.2, even in development.  It simply has no
features that I need or want.  I am strongly considering basing my next
project on gcj... I have no reason to believe it will be any less robust
than Sun's JDK.  It will probably be faster.  It will certainly be more
portable.  Besides I like the compiler ;)

--
Jeff Sturm
jsturm@sigma6.com