Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #32683 > unrolled thread

Translator, Compiler, Interpreter and Java

Back to article view | Back to comp.lang.java.programmer

Contents

  Translator, Compiler, Interpreter and Java Jeff Higgins <jeff@invalid.invalid> - 2015-09-25 00:37 -0400
    Re: Translator, Compiler, Interpreter and Java Robert Klemme <shortcutter@googlemail.com> - 2015-09-25 08:26 +0200
    Re: Translator, Compiler, Interpreter and Java Jeff Higgins <jeff@invalid.invalid> - 2015-09-25 08:36 -0400
      Re: Translator, Compiler, Interpreter and Java Robert Klemme <shortcutter@googlemail.com> - 2015-09-25 18:18 +0200
      Re: Translator, Compiler, Interpreter and Java Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 21:05 -0400
        Re: Translator, Compiler, Interpreter and Java Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 23:07 -0400
          Re: Translator, Compiler, Interpreter and Java Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 22:39 -0400
            Re: Translator, Compiler, Interpreter and Java Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:36 -0400
              Re: Translator, Compiler, Interpreter and Java Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:33 -0400
                Re: Translator, Compiler, Interpreter and Java Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 22:08 -0400
    Re: Translator, Compiler, Interpreter and Java Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 10:32 -0400
      Re: Translator, Compiler, Interpreter and Java Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 21:15 -0400
        Re: Translator, Compiler, Interpreter and Java Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 23:09 -0400
          Re: Translator, Compiler, Interpreter and Java Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 22:41 -0400
            Re: Translator, Compiler, Interpreter and Java Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:38 -0400
              Re: Translator, Compiler, Interpreter and Java Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:35 -0400
                Re: Translator, Compiler, Interpreter and Java Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 22:09 -0400
                  Re: Translator, Compiler, Interpreter and Java Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:16 -0400
                    Re: Translator, Compiler, Interpreter and Java Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 22:26 -0400
        Re: Translator, Compiler, Interpreter and Java Lew <lewbloch@gmail.com> - 2015-10-02 13:17 -0700
          Re: Translator, Compiler, Interpreter and Java Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:41 -0400
            Re: Translator, Compiler, Interpreter and Java Lew <lewbloch@gmail.com> - 2015-10-04 21:24 -0700
              Re: Translator, Compiler, Interpreter and Java Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 08:45 -0400
                Re: Translator, Compiler, Interpreter and Java Lew <lewbloch@gmail.com> - 2015-10-05 10:58 -0700
                  Re: Translator, Compiler, Interpreter and Java Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 14:23 -0400
                    Re: Translator, Compiler, Interpreter and Java Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:10 -0400
                      Re: Translator, Compiler, Interpreter and Java Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 22:26 -0400
            Re: Translator, Compiler, Interpreter and Java Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:01 -0400
              Re: Translator, Compiler, Interpreter and Java Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 22:10 -0400
    Re: Translator, Compiler, Interpreter and Java Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 16:55 +0100
      Re: Translator, Compiler, Interpreter and Java Lew <lewbloch@gmail.com> - 2015-10-02 13:14 -0700
      I don't remember JIT-ing for JDK 1.1 (Was: Translator, Compiler, Interpreter and Java) Jan Burse <janburse@fastmail.fm> - 2015-10-03 04:56 +0200
        Re: I don't remember JIT-ing for JDK 1.1 (Was: Translator, Compiler, Interpreter and Java) Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 23:11 -0400
          Re: I don't remember JIT-ing for JDK 1.1 (Was: Translator, Compiler, Interpreter and Java) Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 23:14 -0400
            Re: I don't remember JIT-ing for JDK 1.1 (Was: Translator, Compiler, Interpreter and Java) Mike Amling <mamling@chaff.us> - 2015-10-04 08:34 -0500
    Re: Translator, Compiler, Interpreter and Java Silvio <silvio@internet.com> - 2015-10-06 10:34 +0200
      Re: Translator, Compiler, Interpreter and Java Silvio <silvio@internet.com> - 2015-10-06 11:01 +0200

Page 2 of 2 — ← Prev page 1 [2]

#32781

On 10/2/2015 4:17 PM, Lew wrote:
> On 9/25/2015 10:32 AM, Jerry Stuckle wrote:
>>> Languages such as Java are somewhere in between.  There is a "compiler"
>>> (more properly called a "translator", IMHO) which converts the source
> 
> And yet the Java purveyors and experts all call it a "compiler". I think I'll stick with those who, as Eternal Hope pointed out, are most likely to have it right.
>

Just because you call a cow a horse does not make it a horse.

>>> code to a byte code.  But this byte code does not run natively; it
> 
> Bytecode (one word, btw) is also not Java.
> 

Then what is it?  Can you execute a BASIC interpreter against it (many
versions of BASIC can also be stored as byte code).  Or Python?  Or any
of the other bytecode interpreters out there?

If the bytecode is not Java, then any virtual machine should be able to
execute it.

>>> requires another program (like the jvm) to interpret the code and
>>> convert it to code which can be executed by the processor.  But because
> 
> Yes, bytecode is (mostly) interpreted. Not so Java.
> 

See above.

>>> this interpretation must be performed every time the program is
>>> executed, Java is considered an interpreted language.
> 
> Java is not interpreted every time the program is run. Premise invalid.
> 

The bytecode is.  Show me what non-Java interpreters can interpret Java
bytecode.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#32794

Jerry Stuckle wrote:
> The bytecode is.  Show me what non-Java interpreters can interpret Java
> bytecode.

Show us what Java interpreters can interpret JVM bytecode. Oh, and Java interpreters are quite rare; they're finally coming out with one for Java 9.Maybe. Mostly Java is compiled, so Java interpreters are hard to come by. But none of the extant ones interpret bytecode.

By the way, the term "Java bytecode" is not accurate. There is no such thing. There is JVM bytecode, which can result from compilation of Java, JavaScript, Python, Ruby, BASIC, Scala, and probably some other languages I don't know about.

I see you are continuing your habit of insulting people personally while not answering their points. We cite facts, you insult us. I am immune to your insults, btw, so please feel free to indulge yourself in all the nasty, unimaginative name-calling and insults you please. Jerry.

tt won't make you right, though. In fact, it will come across as an admission that you were wrong but are unwilling to admit it. So if you insult anyone, you're admitting that you were wrong. So please, insult away. Imagine yourself the king of repartée.

So to recap:
* There are very few Java interpreters.
* None of them interpret JVM bytecode.
* There is no such thing as "Java bytecode".
* JVM bytecode is the result of compilation of any number of languages, including the ones mentioned above, not just Java.

Peace.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#32797

On 10/5/2015 12:24 AM, Lew wrote:
> Jerry Stuckle wrote:
>> The bytecode is.  Show me what non-Java interpreters can interpret Java
>> bytecode.
> 
> Show us what Java interpreters can interpret JVM bytecode. Oh, and Java interpreters are quite rare; they're finally coming out with one for Java 9.Maybe. Mostly Java is compiled, so Java interpreters are hard to come by. But none of the extant ones interpret bytecode.
>

The JVM from Oracle, for instance.  On Windows, it's called java.exe.

> By the way, the term "Java bytecode" is not accurate. There is no such thing. There is JVM bytecode, which can result from compilation of Java, JavaScript, Python, Ruby, BASIC, Scala, and probably some other languages I don't know about.
> 

RLFLMAO!

> I see you are continuing your habit of insulting people personally while not answering their points. We cite facts, you insult us. I am immune to your insults, btw, so please feel free to indulge yourself in all the nasty, unimaginative name-calling and insults you please. Jerry.
> 

I've answered your points.  You're just too stoopid to read the answers.

> tt won't make you right, though. In fact, it will come across as an admission that you were wrong but are unwilling to admit it. So if you insult anyone, you're admitting that you were wrong. So please, insult away. Imagine yourself the king of repartée.
> 
> So to recap:
> * There are very few Java interpreters.
> * None of them interpret JVM bytecode.
> * There is no such thing as "Java bytecode".
> * JVM bytecode is the result of compilation of any number of languages, including the ones mentioned above, not just Java.
> 
> Peace.
> 

So to recap: wrong on every account.

You're even more stoopid than the normal Lew.  Are you sure you're the
same person?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#32799

On Monday, October 5, 2015 at 5:45:06 AM UTC-7, Jerry Stuckle wrote:
> On 10/5/2015 12:24 AM, Lew wrote:
> > Jerry Stuckle wrote:
> >> The bytecode is.  Show me what non-Java interpreters can interpret Java
> >> bytecode.
> > 
> > Show us what Java interpreters can interpret JVM bytecode. Oh, and Java interpreters are quite rare; they're finally coming out with one for Java 9.Maybe. Mostly Java is compiled, so Java interpreters are hard to come by. But none of the extant ones interpret bytecode.
> >
> 
> The JVM from Oracle, for instance.  On Windows, it's called java.exe.

That's not a Java interpreter. It does not interpret Java.

You have to run Java code through "javac.exe" (on Windows) or "javac" (other platforms) before "java"/"java.exe" can handle it. 

So again I ask, what *Java* interpreter can interpret bytecode?

byecode != Java. Different syntax, different semantics, different architecture.

By the way, it's spelled "stupid", not "stoopid".

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#32800

On 10/5/2015 1:58 PM, Lew wrote:
> On Monday, October 5, 2015 at 5:45:06 AM UTC-7, Jerry Stuckle wrote:
>> On 10/5/2015 12:24 AM, Lew wrote:
>>> Jerry Stuckle wrote:
>>>> The bytecode is.  Show me what non-Java interpreters can interpret Java
>>>> bytecode.
>>>
>>> Show us what Java interpreters can interpret JVM bytecode. Oh, and Java interpreters are quite rare; they're finally coming out with one for Java 9.Maybe. Mostly Java is compiled, so Java interpreters are hard to come by. But none of the extant ones interpret bytecode.
>>>
>>
>> The JVM from Oracle, for instance.  On Windows, it's called java.exe.
> 
> That's not a Java interpreter. It does not interpret Java.
> 
> You have to run Java code through "javac.exe" (on Windows) or "javac" (other platforms) before "java"/"java.exe" can handle it. 
> 
> So again I ask, what *Java* interpreter can interpret bytecode?
> 
> byecode != Java. Different syntax, different semantics, different architecture.
> 
> By the way, it's spelled "stupid", not "stoopid".
> 

Wrong again on all parts.

And with you, it's spelled "stoopid".


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#32817

On 10/5/2015 2:23 PM, Jerry Stuckle wrote:
> On 10/5/2015 1:58 PM, Lew wrote:
>> On Monday, October 5, 2015 at 5:45:06 AM UTC-7, Jerry Stuckle wrote:
>>> The JVM from Oracle, for instance.  On Windows, it's called java.exe.
>>
>> That's not a Java interpreter. It does not interpret Java.
>>
>> You have to run Java code through "javac.exe" (on Windows) or "javac" (other platforms) before "java"/"java.exe" can handle it.
>>
>> So again I ask, what *Java* interpreter can interpret bytecode?
>>
>> byecode != Java. Different syntax, different semantics, different architecture.
>
> Wrong again on all parts.

Nope.

He is correct that the JVM does not interpret Java.

He is correct that Java need to be send through the Java compiler before
the JVM can handle it.

It don't think it is possible to be wrong with a question.

bytecode != Java is also correct.

Arne

[toc] | [prev] | [next] | [standalone]

#32823

On 10/5/2015 10:10 PM, Arne Vajhøj wrote:
> On 10/5/2015 2:23 PM, Jerry Stuckle wrote:
>> On 10/5/2015 1:58 PM, Lew wrote:
>>> On Monday, October 5, 2015 at 5:45:06 AM UTC-7, Jerry Stuckle wrote:
>>>> The JVM from Oracle, for instance.  On Windows, it's called java.exe.
>>>
>>> That's not a Java interpreter. It does not interpret Java.
>>>
>>> You have to run Java code through "javac.exe" (on Windows) or "javac"
>>> (other platforms) before "java"/"java.exe" can handle it.
>>>
>>> So again I ask, what *Java* interpreter can interpret bytecode?
>>>
>>> byecode != Java. Different syntax, different semantics, different
>>> architecture.
>>
>> Wrong again on all parts.
> 
> Nope.
> 
> He is correct that the JVM does not interpret Java.
> 
> He is correct that Java need to be send through the Java compiler before
> the JVM can handle it.
> 
> It don't think it is possible to be wrong with a question.
> 
> bytecode != Java is also correct.
> 
> Arne
> 
> 

Arne, your head is so far up your arse that you can see your tonsils.

I'm through with your trolling.  Once you get a clue, maybe we can carry
on an intelligent conversation.  But I'm definitely not going to hold my
breath.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#32813

On 10/3/2015 10:41 AM, Jerry Stuckle wrote:
> On 10/2/2015 4:17 PM, Lew wrote:
>> On 9/25/2015 10:32 AM, Jerry Stuckle wrote:
>>>> code to a byte code.  But this byte code does not run natively; it
>>
>> Bytecode (one word, btw) is also not Java.
>>
>
> Then what is it?  Can you execute a BASIC interpreter against it (many
> versions of BASIC can also be stored as byte code).  Or Python?  Or any
> of the other bytecode interpreters out there?
>
> If the bytecode is not Java, then any virtual machine should be able to
> execute it.

????

Byte code is specific for its VM just like native code
is specific for the ISA.

Maybe you would be less confused if you made a habit of
using "Java Virtual Machine  byte code" and "Java language".

Those two are technically independent, but share some name and history.

Arne

[toc] | [prev] | [next] | [standalone]

#32816

On 10/5/2015 10:01 PM, Arne Vajhøj wrote:
> On 10/3/2015 10:41 AM, Jerry Stuckle wrote:
>> On 10/2/2015 4:17 PM, Lew wrote:
>>> On 9/25/2015 10:32 AM, Jerry Stuckle wrote:
>>>>> code to a byte code.  But this byte code does not run natively; it
>>>
>>> Bytecode (one word, btw) is also not Java.
>>>
>>
>> Then what is it?  Can you execute a BASIC interpreter against it (many
>> versions of BASIC can also be stored as byte code).  Or Python?  Or any
>> of the other bytecode interpreters out there?
>>
>> If the bytecode is not Java, then any virtual machine should be able to
>> execute it.
> 
> ????
> 
> Byte code is specific for its VM just like native code
> is specific for the ISA.
> 
> Maybe you would be less confused if you made a habit of
> using "Java Virtual Machine  byte code" and "Java language".
> 
> Those two are technically independent, but share some name and history.
> 
> Arne
> 

Once again you don't understand what's going on.   But that's nothing
new with you.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#32699

On 25/09/2015 05:37, Jeff Higgins wrote:
> I'm so confused.
> Will someone please clearly explain to me how the terms
> translator, compiler, and interpreter relate to the Java language?

http://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqd/index.html

Figure 1.1  oooooh look, there's an interpreter
Figure 1.3  well blow me down, there's a compiler

Of course what you need to understand is that Oracle are not in the same 
fortunate position as we are here in c.l.j.p

They don't *really* understand Java like some of the infallable geniuses 
we are privileged to have here.



-- 
Laughing Spam Fritter

[toc] | [prev] | [next] | [standalone]

#32764

On Friday, September 25, 2015 at 8:55:16 AM UTC-7, Eternal Hope wrote:
> On 25/09/2015 05:37, Jeff Higgins wrote:
> > I'm so confused.
> > Will someone please clearly explain to me how the terms
> > translator, compiler, and interpreter relate to the Java language?
> 
> http://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqd/index.html
> 
> Figure 1.1  oooooh look, there's an interpreter
> Figure 1.3  well blow me down, there's a compiler
> 
> Of course what you need to understand is that Oracle are not in the same 
> fortunate position as we are here in c.l.j.p
> 
> They don't *really* understand Java like some of the infallable geniuses 
> we are privileged to have here.

Figure 1.1 illustrates a bytecode interpreter.
Figure 1.3 illustrates a Java compiler.

Conclusion: 
Generally the Oracle architecture compiles Java and interprets assembler, I mean bytecode, although it also compiles bytecode.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#32774 — I don't remember JIT-ing for JDK 1.1 (Was: Translator, Compiler, Interpreter and Java)

Eternal Hope schrieb:
> Of course what you need to understand is that Oracle are not in the same
> fortunate position as we are here in c.l.j.p

What bogs me a little bit that JIT-ing is described
in connection with JDK 1.1. But history has it that
it wasn't there at that time:

Initially available as an add-on for Java 1.2,
HotSpot became the default Sun JVM in Java 1.3.
https://en.wikipedia.org/wiki/HotSpot

Or can somebody of the genuises here highlight
why Sun JIT-ing is mentioned for JDK 1.1 by Oracle?
Was there some JIT-ing before HotSpot by Sun?

Or was there a backport to some arcane
JDK 1.1? Or is this just an annoucement which
only materialized for JDK 1.2? Or should we
just ingnore the reference to JDK 1.1?

Bye

[toc] | [prev] | [next] | [standalone]

#32776 — Re: I don't remember JIT-ing for JDK 1.1 (Was: Translator, Compiler, Interpreter and Java)

On 10/2/2015 10:56 PM, Jan Burse wrote:
> Eternal Hope schrieb:
>> Of course what you need to understand is that Oracle are not in the same
>> fortunate position as we are here in c.l.j.p
>
> What bogs me a little bit that JIT-ing is described
> in connection with JDK 1.1. But history has it that
> it wasn't there at that time:
>
> Initially available as an add-on for Java 1.2,
> HotSpot became the default Sun JVM in Java 1.3.
> https://en.wikipedia.org/wiki/HotSpot
>
> Or can somebody of the genuises here highlight
> why Sun JIT-ing is mentioned for JDK 1.1 by Oracle?
> Was there some JIT-ing before HotSpot by Sun?
>
> Or was there a backport to some arcane
> JDK 1.1? Or is this just an annoucement which
> only materialized for JDK 1.2? Or should we
> just ingnore the reference to JDK 1.1?

There are plenty of references to JIT for Java 1.1
in old SUN docs.

https://singztechmusings.wordpress.com/2011/07/03/java-what-is-jit-compiler-and-how-does-it-work/

claims:

<quote>
The JIT compiler was first made available as a performance update in the 
Java Development Kit (JDK) 1.1.6 software release
</quote>

so maybe the Wikipedia article is not 100% correct!?!?

My guess is that the article is correct about when HotSpot was
released but wrong about it being the first JIT compiler
and SUN had an earlier SUN JIT compiler.

Arne

[toc] | [prev] | [next] | [standalone]

#32777 — Re: I don't remember JIT-ing for JDK 1.1 (Was: Translator, Compiler, Interpreter and Java)

On 10/2/2015 11:11 PM, Arne Vajhøj wrote:
>> Or can somebody of the genuises here highlight
>> why Sun JIT-ing is mentioned for JDK 1.1 by Oracle?
>> Was there some JIT-ing before HotSpot by Sun?
>>
>> Or was there a backport to some arcane
>> JDK 1.1? Or is this just an annoucement which
>> only materialized for JDK 1.2? Or should we
>> just ingnore the reference to JDK 1.1?
>
> There are plenty of references to JIT for Java 1.1
> in old SUN docs.
>
> https://singztechmusings.wordpress.com/2011/07/03/java-what-is-jit-compiler-and-how-does-it-work/
>
> claims:
>
> <quote>
> The JIT compiler was first made available as a performance update in the
> Java Development Kit (JDK) 1.1.6 software release
> </quote>
>
> so maybe the Wikipedia article is not 100% correct!?!?
>
> My guess is that the article is correct about when HotSpot was
> released but wrong about it being the first JIT compiler
> and SUN had an earlier SUN JIT compiler.

To further confuse everybody then:

https://en.wikipedia.org/wiki/Java_performance

claims that Symantec had a JIT compiler for Java 1.1
that SUN used.

But it seems to be for Windows not Solaris.

So maybe SUN did one for Solaris and bought the Symantec
one for Windows and then later replaced it with HotSpot on both
platforms.

Mostly speculation.

Arne

[toc] | [prev] | [next] | [standalone]

#32787 — Re: I don't remember JIT-ing for JDK 1.1 (Was: Translator, Compiler, Interpreter and Java)

On 10/2/15 10:14 PM, Arne Vajhøj wrote:
> On 10/2/2015 11:11 PM, Arne Vajhøj wrote:
>>> Or can somebody of the genuises here highlight
>>> why Sun JIT-ing is mentioned for JDK 1.1 by Oracle?
>>> Was there some JIT-ing before HotSpot by Sun?
>>>
>>> Or was there a backport to some arcane
>>> JDK 1.1? Or is this just an annoucement which
>>> only materialized for JDK 1.2? Or should we
>>> just ingnore the reference to JDK 1.1?
>>
>> There are plenty of references to JIT for Java 1.1
>> in old SUN docs.
>>
>> https://singztechmusings.wordpress.com/2011/07/03/java-what-is-jit-compiler-and-how-does-it-work/
>>
>>
>> claims:
>>
>> <quote>
>> The JIT compiler was first made available as a performance update in the
>> Java Development Kit (JDK) 1.1.6 software release
>> </quote>
>>
>> so maybe the Wikipedia article is not 100% correct!?!?
>>
>> My guess is that the article is correct about when HotSpot was
>> released but wrong about it being the first JIT compiler
>> and SUN had an earlier SUN JIT compiler.
>
> To further confuse everybody then:
>
> https://en.wikipedia.org/wiki/Java_performance
>
> claims that Symantec had a JIT compiler for Java 1.1
> that SUN used.
>
> But it seems to be for Windows not Solaris.
>
> So maybe SUN did one for Solaris and bought the Symantec
> one for Windows and then later replaced it with HotSpot on both
> platforms.
>
> Mostly speculation.
>
> Arne

I recall there were JITCs for Java bytecode before any called HotSpot.

We had a Unix machine that ran Java 1.1. This was over a decade ago and 
I don't recall which Unix flavor it was, but I do remember its chip was 
not Intel. DEC, maybe. From some non-Java programs (written in the Baan 
programming language), I concluded it had machine-level support for 
integers longer than 32 bits. Anyway, from its speed of execution, I 
conclude its Java was using a JITC.

FWIW, the functional definition of an interpreter that I use is
"An interpreter reads a program, from human-readable source or from 
bytecode or other symbolic representation, but not machine instructions, 
and does what that program says to do. Note that all the machine 
instructions executed are in the interpreter and existed before the 
source was read."

"A compiler reads one representation of a program, which may be 
human-readable source or bytecode or other symbolic representation, and 
puts out an equivalent program in another language, typically machine 
instructions or bytecode, but does not do what the program says to do."

Mike Amling
SWYgeW91IGZlZWwgeW91IGhhdmUgdG8gY29ycmVjdCBldmVyeSBlcnJvciB5b3Ugc2VlIG9uIHRo
ZSBJbnRlcm5ldCwgeW91IHdpbGwgbmV2ZXIgaGF2ZSB0aW1lIHRvIGRvIGFueXRoaW5nIGVsc2Uu

[toc] | [prev] | [next] | [standalone]

#32826

On 09/25/2015 06:37 AM, Jeff Higgins wrote:
> I'm so confused.
> Will someone please clearly explain to me how the terms
> translator, compiler, and interpreter relate to the Java language?

I fail to understand the heat of the discussion here, since there is 
nothing really subjective about this all.

For decades the word compiler has been used for a system that translates 
input in language S1 to output in language S2.
Mostly (but necessarily) compilers translate from more "abstract" 
languages to less abstract ones and in many cases S2 has been something 
that can be executed by directly by a micro-processor of some sort.

Interpreters process input programs written in some language S and 
execute them directly. They are the software counterpart of a 
micro-processor.
How they execute the programs is irrelevant and if they use some form of 
compiler internally to transform their input into something more suited 
for rapid execution than they are interpreters no less.

The standard (Sun, OpenJDK) Java compiler conforms in every way to what 
a compiler is. No discussion possible, it is a compiler that translates 
Java source code to (JVM) Bytecode.

Analogous the standard JVM (Sun, OpenJDK) is in all aspects an 
interpreter. It is a very fast one that internally compiles Bytecode to 
native instructions for faster execution. So it embeds a compiler but as 
a whole it is still an interpreter.

However, there are also compilers that can translate Java source code or 
JVM Bytecode into native executable code.

Java is in all common implementations a compiled language. Bytecode can 
be a compiled language and an interpreted language, depending on which 
translation system is used.

I have used a Pascal compiler that produced native Z80 executable code 
with a Z80 emulator (interpreter) on an Intel system. What does that say 
about Pascal or even Z80 native code? Nothing!

Every input programming language can be either compiled into some 
different language or interpreted directly.

Silvio

[toc] | [prev] | [next] | [standalone]

#32827

... (but NOT necessarily) ...

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web