Which is true and why they created the JIT Compiler in Java 2.
Now days in a standard JVM process a lot of byte code is assembled to machine code. And a large part will be heavily optimized and recompiled to better machine code at runtime. That's why a JVM program quite often outperforms "native" languages, unless they are optimized by hand. (or after gathering enough trace information).
But calling Java an interpreted language is wrong. A common characteristic of interpreted languages is executing part of the code before running into a compile error.
I've been in this conversation about a dozen plus times now. Every person tries to make the same claim, "Java isn't interpreted," but then they have to move the targets and shuffle the definitions around to prove it.
If Java were an assembled language, the end result of your compilation would be a standalone executable binary consisting purely of machine code, which could be run by itself on any machine of the matching architecture. Java doesn't do this; end users have to have some sort of runtime on their machine which executes the .JAR file they shipped. Either the process was made arbitrarily more complex than it needs to be, or Java is not an assembled language. (Please pick one.)
It's a compiled-interpreted, purely on merit that it isn't an assembled language. Just because its compile/interpret process is so complicated that practically every Java developer has their own unique understanding, doesn't mean that it isn't compiled-interpreted.
And, it's worth mentioning, interpreted does NOT mean slow, bad, or unprofessional! I think a lot of people are afraid if they admit that Java is compiled-interpreted, they'd be admitting it's somehow "bad," but that is most assuredly not the case.
A common characteristic of interpreted languages is executing part of the code before running into a compile error.
Nope. That's an interactive language...so, I guess that's another entry to this list?
If your claim was that an assembled language has as shippable artefact hardware machine code, then I would not make a big point out of it. But...
C and C++ programs also depend on a common runtime. They do not work without it.
You can include the Java runtime with Java application if you want.
The runtime for .Net applications is included with Windows these days, so can ship your compiled C# program without users needing to get a runtime. By your definition is it then an assembled language or an interpreted language.
Sun made hardware which natively runs Java bytecode. It was nog a big success, but it could run your .jar directly on the CPU. So it's an assembled language after all.
The runtime for .Net applications is included with Windows these days, so can ship your compiled C# program without users needing to get a runtime. By your definition is it then an assembled language or an interpreted language.
C#, C++, and C are three different languages, btw.
As to C++ and C, they often rely on dynamically linked libraries, but dependencies are an unrelated issue for any language. You'll note I never brought it into the Java discussion; going into dependencies is another moving-the-target distraction tactic (don't worry, I won't blame you for inventing it...it's been in use for a while.)
C++ and C can produce binaries which require no dependencies, simply by avoiding the standard library.
That said, I will admit to using the wrong term a moment ago; runtime is a dependency library, whereas what I'm referring to with Java is the software responsible for executing the bytecode on the target machine.
Dependencies shouldn't enter into this discussion, all languages (practically speaking) have to be able to resolve dependencies.
Sun made hardware which natively runs Java bytecode.
Also a case of moving-the-target. I already stated earlier that there were impractical means by which virtually any assembled languages can be interpreted, and virtually any interpreted/interpreted-compiled languages can be assembled. This does not count because it has no bearing on standard deployment.
The inescapable point: Java is, for all practical intents and purposes, never assembled to a machine code binary file, such that it can be shipped to an end-user (w/ or w/o dependency libraries compiled to the same), and executed directly on a standard Intel, AMD, or ARM processor without needing an additional program to interpret (or, if you want to get pedantic, AOT/JIT-compile) the (byte)code.
An interpreted language has a software layer between the final, shipped result of compilation and its ultimate execution on the target machine.
Ergo, Java is compiled-interpreted. It is NOT assembled. It is also NOT interactive. (But, yes, it's still a real language.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Which is true and why they created the JIT Compiler in Java 2.
Now days in a standard JVM process a lot of byte code is assembled to machine code. And a large part will be heavily optimized and recompiled to better machine code at runtime. That's why a JVM program quite often outperforms "native" languages, unless they are optimized by hand. (or after gathering enough trace information).
But calling Java an interpreted language is wrong. A common characteristic of interpreted languages is executing part of the code before running into a compile error.
Sigh
I've been in this conversation about a dozen plus times now. Every person tries to make the same claim, "Java isn't interpreted," but then they have to move the targets and shuffle the definitions around to prove it.
If Java were an assembled language, the end result of your compilation would be a standalone executable binary consisting purely of machine code, which could be run by itself on any machine of the matching architecture. Java doesn't do this; end users have to have some sort of runtime on their machine which executes the .JAR file they shipped. Either the process was made arbitrarily more complex than it needs to be, or Java is not an assembled language. (Please pick one.)
It's a compiled-interpreted, purely on merit that it isn't an assembled language. Just because its compile/interpret process is so complicated that practically every Java developer has their own unique understanding, doesn't mean that it isn't compiled-interpreted.
And, it's worth mentioning, interpreted does NOT mean slow, bad, or unprofessional! I think a lot of people are afraid if they admit that Java is compiled-interpreted, they'd be admitting it's somehow "bad," but that is most assuredly not the case.
Nope. That's an interactive language...so, I guess that's another entry to this list?
If your claim was that an assembled language has as shippable artefact hardware machine code, then I would not make a big point out of it. But...
C and C++ programs also depend on a common runtime. They do not work without it.
You can include the Java runtime with Java application if you want.
The runtime for .Net applications is included with Windows these days, so can ship your compiled C# program without users needing to get a runtime. By your definition is it then an assembled language or an interpreted language.
Sun made hardware which natively runs Java bytecode. It was nog a big success, but it could run your .jar directly on the CPU. So it's an assembled language after all.
C#, C++, and C are three different languages, btw.
As to C++ and C, they often rely on dynamically linked libraries, but dependencies are an unrelated issue for any language. You'll note I never brought it into the Java discussion; going into dependencies is another moving-the-target distraction tactic (don't worry, I won't blame you for inventing it...it's been in use for a while.)
C++ and C can produce binaries which require no dependencies, simply by avoiding the standard library.
That said, I will admit to using the wrong term a moment ago; runtime is a dependency library, whereas what I'm referring to with Java is the software responsible for executing the bytecode on the target machine.
Dependencies shouldn't enter into this discussion, all languages (practically speaking) have to be able to resolve dependencies.
Also a case of moving-the-target. I already stated earlier that there were impractical means by which virtually any assembled languages can be interpreted, and virtually any interpreted/interpreted-compiled languages can be assembled. This does not count because it has no bearing on standard deployment.
The inescapable point: Java is, for all practical intents and purposes, never assembled to a machine code binary file, such that it can be shipped to an end-user (w/ or w/o dependency libraries compiled to the same), and executed directly on a standard Intel, AMD, or ARM processor without needing an additional program to interpret (or, if you want to get pedantic, AOT/JIT-compile) the (byte)code.
An interpreted language has a software layer between the final, shipped result of compilation and its ultimate execution on the target machine.
Ergo, Java is compiled-interpreted. It is NOT assembled. It is also NOT interactive. (But, yes, it's still a real language.)