[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: More Java guidelines questions



On Mon, 2008-04-28 at 00:50 -0500, Les Mikesell wrote:
> Callum Lerwick wrote:
> > 
> >> Sure, that was a good argument for pushing gcj in the past.
> >> The question is should we focus on gcj or openjdk/icedtea now.
> > 
> > IMHO the only reason Java bytecode exists is to make it possible to
> > distribute "run anywhere" proprietary software while keeping the source
> > code closed. Thus in an open source environment, Java bytecode has
> > little reason to exist.
> 
> Errr, what about applet downloads and RMI, neither of which requires 
> similar architecture or compiling capability at the other end?  Are you 
> sure you are talking about something that even resembles java?

You distribute source code, and "JIT" compile it direct from source
code, yes. Just like Python or Perl or PHP or Javascript...

And yes, Java wasn't designed for this from the start, so the existing
compiler is too slow and heavyweight for this. This may even be
impossible. But the interpreted language space is pretty well covered
already anyway.

> > If we're going to *distribute* compiled code, it
> > may as well be nice fast native code.
> > 
> > Yes I know what you're going to say, lots of languages, such as Python
> > do bytecode as well. But they do it as a backend implementation detail,
> > with no guarantee of stability and stored on disk only as a performance
> > optimization, rather than an intentional mechanism for source code
> > obfuscation. IMO we, the open source community, should shun Java
> > bytecode.
> 
> It would be better to ship something that follows the spec, or call it 
> something other than java.

If that's what it takes.

I guess what my point is here, is Java, in Sun's implementation, has
chosen to stand half-way between a native-compiled language and an
interpreted language. Which has resulted in it being mediocre at either
and ultimately just serves to inherit the disadvantages of AOT
compilation with none of the advantage (speed). If it continues on its
current path, it's just going to be eclipsed (heh) by Python on the
interpreted side of things and by C# (and continued use of C++ and C) in
native compilation. In the open source world, that is. The closed source
world will gladly continue cranking out Java code as it is the COBOL of
the 90+'s...

Pick a side Java, we're at war.

(Note to the international community: That was a Colbert Report
reference.)

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]