Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Jerry Stuckle Newsgroups: comp.lang.java.programmer Subject: Re: questions re Javascript Date: Fri, 2 Oct 2015 16:24:26 -0400 Organization: A noiseless patient Spider Lines: 263 Message-ID: References: <83722e36-4afe-4077-b936-229450613698@googlegroups.com> <3552aa8f-51c1-46f1-9029-b28208c76ee8@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Injection-Date: Fri, 2 Oct 2015 20:22:15 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="8b88f1819ae50b8afa97a5cef254b303"; logging-data="9180"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1//QhCoTZm9vcTVyugIL8fJpBBMXWQbzcw=" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: Cancel-Lock: sha1:NGPXjIBC3bWailJzlVlUQfhhWWc= Xref: csiph.com comp.lang.java.programmer:32766 On 10/2/2015 4:02 PM, Lew wrote: > On Thursday, September 24, 2015 at 4:40:21 PM UTC-7, Jerry Stuckle wrote: > >>>> A Java compiler takes source code as input and produces output that >>> >>> A Java what? What was that word? Wait, was it "compiler"? A Java "compiler"? So what does a Java "compiler" do? Could it be that it *compiles* the Java language source code? As a result of which the Java code is what? Compiled? And yet Java is not a compiled language? >>> >>> WTF? >>> >> >> The Java compiler changes source code into byte code. It does NOT >> create machine-readable code. >> >> A compiler simply changes one version of code to another; in this case >> it converts source code into byte code. But that does NOT mean it is >> the same as compiled code - which (until Java pundits have tried to >> change the definition) has always referred to code directly executable >> by the machine. It does NOT refer to "assembler code" - which actually >> is just a text representative of machine code. >> >>>> requires interpretation by a platform specific machine that 'looks up' >>>> the relevant platform specific instruction and it is that that is >>>> executed on the underlying hardware. >>> >>> So bytecode is interpreted. Bytecode is not Java, in case you hadn't noticed. >>> >> >> Yes, in case you haven't noticed - Java Bytecode IS Java - as opposed to >> bytecode in other languages. > > Bytecode is not Java. The specs are different. The rules are different. languages other than Java compile (!) into bytecode. > And how are the rules and specs different? And what do other languages have to do with it? > So Java bytecode is bytecode in other languages (Python, Scala, JavaScript, ...). > OK, if bytecode is bytecode, then I can execute Java bytecode with a Python interpreter, and vice versa. I don't think so! >>> Compilers don't compile into machine code. They compile into assembly code of some kind. The assembly for Java is called "bytecode". >>> >> >> See above. But you've already shown you understand neither assembler >> nor machine code - much less the difference between the two. > > You don't need to attack me. It shows weakness in your argument. > > I assert that I understand those things perfectly. > You have shown no understanding of either. And you've just shown that once again. >>> Notice that the C compiler produces ".o" files, which are not directly runnable. >>> >> >> No, they have to be linked to the libraries, first. But that does not >> change the fact the .o code is machine executable code; it's just > > Yes, it does. > Once again you show you don't understand machine code. >> missing necessary libraries. But the code itself is executable machine >> code. > > Except that you cannot execute it. > Except it only needs to be linked to the appropriate libraries. That does not change the fact it is machine code. >>> You are right that *bytecode* is interpreted. What did bytecode get emitted by again? What was that tool called? A "compiler"? Which does what to Java code again? >>> >> >> Bytecode is generated by the Java Compiler. > > The Java what, again? "Compiler", you say? > > What is it that the Java *compiler* does to Java, again? > Yes, I do agree it is mistakenly called a compiler. If you have two horses and a cow, and call the cow a horse, how many horses do you have? The answer is still two. Just calling a cow a horse doesn't make it a horse. A better term for it would be a Java Translator, because it translates Java source code to byte code. >> But that does not mean the >> result is "compiled code" as is generally recognized by experts in the > > Yes, actually, it does. > >> computer community. Only those with limited Java experience consider it >> that. > > Again with the /ad hominem/. Your arguments must truly be weak. > No, just the truth. Only those in the Java community with no experience in real compiled languages make statements like you do. > >>> Again, not to put too fine a point on it, the *bytecode* that gets interpreted (which is NOT Java) is produced by what tool? >>> >> >> And what is the bytecode if it is not compiled Java? Can it be >> interpreted by a Basic interpreter? > > It can be interpreted by a bytecode interpreter. Certainly not by a Java interpreter, since bytecode isn't Java. And why couldn't you compile BASIC into bytecode? > > > > Hm? > So, your python interpreter can interpret the output of the Java compiler? Or a BASIC interpreter? No, I'm not talking about "jvm basic" - I'm talking about a BASIC interpreter. Do you know the difference? >>>> It doesn't really matter though does it? I mean it's not going to make >>>> any difference to the future of mankind is it? I'm more concerned with > > If that mankind is working with the JVM, yes, it will matter. > Not my post - or can yo not tell the difference? >>>> preventing this solid state Asus thingy from being forcibly updated to >>>> the Pay As You Spy As You Go platform called windows 10. > > Then why post here? > Not my post - or can yo not tell the difference? >>>> Thank god for the gcc compiler and the Linux kernel :-) >>>> That is still the compiler of choice isn't it? >>>> >>>>> To me, the fact that Java has to be run in a JVM is not relevant to this >>> >>> Java is not run in a JVM. >>> >> >> Then what is it run in? A BASIC interpreter? > > It is not run at all. It is compiled. > So it runs just fine without a jvm? I don't think so! >>> Java is compiled. The output of the compiler is run in the machine, JUST LIKE WITH C. >> >> No, Java is not compiled into machine code. Although there are > > Yes, actually, it is. It is compiled into machine code for the JVM. > Bytecode is not machine code. > This machine code is described in a separate, completely different specification from Java. It supports code compiled from many languages (including BASIC). > Bytecode is not machine code. >> third-party tools which will convert Java into machine code. the Java >> compiler creates byte code. > > Which is machine code. > Bytecode is not machine code. >> If Java were compiled into machine code, it could not run on multiple >> platforms under multiple OS's. The fact it can do that proves it is not > > Actually, it doesn't run on any machine. Only bytecode runs on various machines. > Ah, so now you admit bytecode is not machine code? >> machine code - because every platform and every OS has a different >> machine code interface. > > For bytecode. Not for Java. The interface for Java is identical for all those machines, hence the famous slogan, "Write once, run everywhere". > Bytecode is not machine code. >>>>> argument: nobody ever claimed that UCSD Pascal was interpreted despite >>>>> the face that its compiler output P-code that needed a runtime translator >>>>> to execute it. If you count Java and P-coded compilation systems as >>>>> 'interpreted languages' then you must also include, say, 6800 assembler >>>>> as an 'interpreted language' if its being run on an Intel box with the >>>>> air of a 6800 emulator. >>> >>> WTF? >>> >>> I point out again that Java code is not interpreted. It is process through a tool called a "compiler", program name "javac", which "compiles" the Java source code. That makes Java "compiled". >>> >> >> And once again you are wrong. > > Saying so doesn't make it so. > And saying you're right does not make it so. >>> Java is not interpreted. Show me where it is. Not on the JVM; the JVM doesn't run Java code. >>> >> >> The fact it requires a JVM to run, and the same compiled code runs on > > The same *what* code? > >> multiple platforms with no change is proof. > > That Java is compiled, is what it proves. > A better term for it would be a Java Translator, because it translates Java source code to byte code. >> But there are always noobs who think they know more than the experts. >> unfortunately, Java seems to have more than its fair share. I guess >> that's because java noobs don't need to understand the difference. >> >> Those of us who have worked for years on multiple platforms in multiple >> languages understand better. > > Those of us who have worked on multiple platforms over many decades do indeed know better. I don't know what your derogatory attitude toward "noobs" has to do with anything. > Obviously not - or you would understand there is a difference between bytecode and machine code - which you do not. > Even in your own post you refer to "compiled" Java code, yet you claim Java is not compiled. You contradict yourself. > A better term for it would be translated code. > The final proof is this: Java code is not executed on the JVM. At all. Therefore it is impossible that Java code is interpreted. > Then it runs just fine without a jvm? I don't think so. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================