I'm just starting to learn Java (as the second language from Python), but I can't understand the very first point of it. From my understanding, it says:
"Making each kind of compiler (e.g. of C/C++) to each kind of CPU is too much of a hassle. Java, on the other hand, works universally once JVM is installed, because its intermediate code is interpreted by JVM, rather than making a specific native code."
...but don't you need to implement each kind of JVM to each kind of CPU? Is this really an advantage of Java over C/C++?
I think there's a duplicate about this in SO or elsewhere on the internet, but sorry, I couldn't think up any good search word.
each kind of JVM to each kind of CPU is implemented by folks from oracle and other JVM vendors: in case of C/C++ you have to compile YOUR application code for each CPU/OS
Yes, someone has to make a JVM to be able to run on different platforms, but that someone isn't you.
If you go to the download link for Java https://java.com/en/download/manual.jsp you can see there are various JVM builds for Windows, Mac, Linux and Solaris etc
As a programmer, you just have to write your own code and compile it into .class files. Then it's someone else's problem to provide a JVM to run those class files on a specific machine.
Yes someone need to implement each kind of JVM to each kind of CPU? And if this JVM is going to be used, it will also contain a jit compiler, so not much benefit compared to just writing a compiler.
But it might be talking about using the jvm as a target for your own compiled language.
Imagine this: You want to make your own language. Lets call it MyLanguage. Normally you would have to write a compiler, for each cpu, and lots of support code for each operation system you want to support.
But if you just write one compiler which compiles MyLanguage to java bytecode, then the user can run the java byte code on a JVM.
Your language can then be used on any processor/operation system currently supported by a JVM. And you only had to write one compiler.
This is for example what the developers of Scala did.
Related
Someone told me there was more overhead for Java because you can essentially run it on most operating systems and that C# doesn't have that overhead so then it can execute at near C++ speeds.
So is there more overhead in Java, or does each OS has it's own overhead for it's JVM implementation?
C#, Java (and I'll toss it in there too - JavaScript) are languages. Languages are not fast or slow, they just are specifications for how we humans write things that are to eventually be handled by a computer.
The JVM is the Java Virtual Machine. But there are several different versions of it. There's HotSpot (the original), OpenJDK, And then one can look at JRockit from BEA, Apache Harmony and a bunch more.
For C# there is the CLR, but there's also Mono's runtime. There are also others that have been abandoned over time.
JavaScript (because I'm tossing that in there) has an entire army of runtimes. Some of those runtimes are faster than others.
It is the runtime that is faster or slower than another - even possibly for the same language. But that one is 'cross platform' and another is not is not enough of an indication to say that one is faster than the other. There are a great many other things at work and benchmarks can be constructed that show one combination being faster than another for each one.
Going even further, one can look at languages that span multiple runtimes. You've got Python with CPython as its default implementation - but there's Jython that runs in the JVM and IronPython that runs in the CLR. Similar examples can be found with Ruby, IronRuby, and JRuby or Clojure which can be compiled to JavaScript via ClojureScript and then run on one of the JavaScript runtimes rather than a JVM.
Again, its not the language that is fast or slow - but rather how its implemented in its runtime.
The Java language and the Java Virtual Machine (JVM) are completely separate entities. Oracle has done an excellent job of separating the two, so that other languages (like Scala or even Ruby) can run on the JVM.
The Java language itself is definitely written with the intent of targeting the JVM, but, so far as I know, there is no actual requirement that it must. So far as I know it's completely possible to write a Java compiler that generates native code, rather than Java bytecode. (This is all completely hypothetical. I've never heard of anyone actually doing that - there would be very little point. Current implementations of the JVM tend to be almost as fast as native code, and any benefit gained by this would be greatly outweighed by the loss of portability it would entail.)
The situation is further complicated by the fact that C# doesn't exactly have a VM, as discussed here. So the best comparison you can make is "does this implementation of the JVM run this Java code faster than that implementation of the .NET framework runs that C# code?"
In the end, unless there is a remarkable speed difference for very similar code, the comparison just isn't that compelling because there are too many variables. Use a different JVM, or a different Java compiler, or a different .NET implementation, or a different C# compiler, or run the same code on a different machine, and the numbers change.
How come code written in Java needs to be compiled in byte-code that is interpreted by the JVM, but code written in a language like JavaScript does not need to be compiled and can run directly in a browser?
Is there an easy way to understand this?
What is the fundamental difference between the way these two languages are written, that may help to understand this behavior?
I am not a CS student, so please excuse the naivete of the question.
Historically, JavaScript was an interpreted language. Which means an interpreter accepts the source code and executes it all in one step. The advantage here is simplicity and flexibility, but interpreters are very slow. Compilers convert the high level language into a lower level language that either the native processor or a VM (in this case, the Java VM) can execute directly. This is much faster.
JavaScript in modern browsers is now compiled on the fly. So when the script is loaded, the first thing the JavaScript engine does is compile it into a bytecode and then execute it. The reason the entire compilation step is missing from the end user's perspective is because browser developers have (thankfully) maintained the requirement that JavaScript is not explicitly compiled.
Java was from the getgo a language that always had an explicit compile step. But in many cases that's not true anymore. IDE's like IntelliJ or Eclipse can compile Java on the fly and in many cases remove the explicit compilation step.
JavaScript and Java are not the same thing. They might share a similar name, but I refer you to the JS guru - Douglas Crockford to help clear up the fact that they are really not related at all.
The reality is that there is nothing stopping Java being an interpreted language, and there's equally nothing stopping JavaScript being a compiled language (Chrome's javascript engine does do compilation to improve speed, and does a very good job of it).
In the context of the browser, Java runs in the same way as Flash or Silverlight - a plugin is required and the browser acts as a host to that plugin; which hosts a Java runtime environment.
Javascript was designed to be a scripting language for the browser, and that's why the browser can understand it natively. How the browser actually achieves the running of that code, however, is entirely up to the browser. That is - it can operate purely at a script level, assuming zero-knowledge of the next line of code and running a purely software-based stack; or it can perform some JIT to get the code closer to the hardware and (hopefully) improve speed.
Any language can be compiled and interpreted. In both cases, a piece of software has to read the source code, split it up, parse it, etc. to check certain requirements and then assign a meaning to every part of the program. The only difference is that the compiler then proceeds to generate code with (almost) the same meaning in another language (JVM bytecode, or JavaScript, or machine code, or something entirely else) while the interpreter carries out the meaning of the program immediately.
Now, in practice it's both simpler and more complicated. It's simpler in many languages lend themselves better to one of the two - Java is statically-typed and there is relatively little dynamic about the meaning of a program, so you can compile it and thus do some work which would otherwise need to be done at runtime. JavaScript is dynamically-typed and you can't decide a lot of things (such as whether + is addition or concatenation) until runtime, so compilation does not afford you much performance. However, a mix of compiler and interpreter (compile to simplified intermediate representation, then interpret and/or compile that) is increasingly popular among dynamic language implementations. And then there's the fact that modern JavaScript implementations do compile, and in fact V8 never interprets anything.
Because of the being complexity of compiling level between Java and Javascript, there are some limitations in Javascript. Since bytecode is executed on JVM platform which is written for specific OS and Hardware bytecode execution has more advantages to access system resources. Even C code can be embedded into Java bytecode aswell. On the other hand Since Javascript is only run on browser there is less to do with it.
there are two main part at Java platform. Java programming Language and JVM. It makes each part focus only their own area. That is why JVM doesnot dedal with Java programming syntax. It is similar to that when running C code linking does not deal with C code but assembly.
Bytecode in JVM platform is likely an assembly in C.
Eventually all representations are converted into binary representation and then the electirical signals somehow. It proves that we need programming levels.
So up until about 6 months ago, most of my work (big graph processing) consisted of Python and C++. Up to that point, and even now, I had not written any Java whatsoever.. I had seen the language and was familiar with the syntax (having come from a C/C++ background), and liked the idea of the JVM, but never actually written any substantial amount of Java.
When I picked up Scala, I loved it, OOP and functional programming features all in one, and it being on the JVM was great. I've been constantly striving to improve my Scala and have been playing with Akka, and still loving it. However, at times, perhaps it is just me overthinkng it, but I feel I should learn some more about Java and/or the JVM.
I've heard from many that Scala should be considered a separate language from Java, much like C++ to C. Perhaps you may feel the same way, and perhaps learning Java is more or less disjoint from learning Scala, but I'm feeling learning more about the JVM (e.g. JIT compilation, type erasure) would be helpful?
Thoughts?
The JVM executes Bytecode and it is definately helpful to know how this works, just as it is sometimes helpful to know how C/C++ method invocations work or how classes are initialized; because sometimes it matters and cannot be abstracted away.
Java is the prime language for the JVM, and it is helpful to be able to read Java to some extent if you need to use Java classes directly. And this may happen quite often; only a few examples:
you need to use some third party Java library (and there are tons)
working with Properties
you need to do something special in Swing which is not supported by the Scala-Swing wrapper
also sources explaining stuff for 1) will most probably use Java examples
But my advice is not to study it in advance - you'll pick it up when you need it.
Buy this book now: Java Performance. It was only released last October and is a treasure trove of information for anyone who wants to understand the JVM. If you're going to be a Scala developer, you must understand garbage collection and JVM runtime parameters at the very least.
Off top of my head
primitives, autoboxing, and how java arrays are special;
erasure and manifests
how logically tail recursive calls in scala source are compiled
installing -client, -server on your platform and when you want to try 32 bit: e.g. JAVA_HOME and "Java preferences" in OS X. I think openJDK should work anywhere you use same version of Oracle JDK, but IntelliJ warns you to use only official Oracle JDK. I've seen very isolated reports that 3d graphics libs have had problems with openJDK, and also parts of openJDK like the fonts have licensing issues.
setting classpaths in REPL, as compiler option, and in SBT
Hotspot switches, XMX, XMS (heap settings), most common garbage collectors, inlining method calls
java.util.concurrent
possible binary compatibility issues with java and scala code compiled in JDK 6 and 7.
I don't know exactly what you need, but there are several similar questions on SO, look it.
Understanding JVM Better
Understanding the Sun JVM
Also, here good articles for Java Memory Model
Java theory and practice: Fixing the Java Memory Model, Part 1
Java theory and practice: Fixing the Java Memory Model, Part 2
My thought it's better to dig in Java language, write some code, read Java-specific books for better understanding how all things works.
There are a lot of tools surrounding the JVM. If you want to understand how your programs are running (for performance or other reasons) then it's worth being au fait with these. Two useful tools are:
jstack
visualvm
Both are particularly useful for monitoring and interrogating long-running processes.
I think you will know more about JVM when you program Scala. I mean you will have more questions like 'Why this solution is slow and that is fast?' - one way to answer this question is to check the bytecode
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Why isn't more Java software compiled natively?
I know that Java is byte code compiled, but when using the JIT, it will compile the 'hotspots' to native code. Why is there not an option to compile a program to native code?
There is an option to compile Java source code files in binary code it is called GCJ and come from Free Software Foundation.
It is not officially supported by Sun/Oracle but i've used the compiler and it do a great job ;)
Java, as a language, can be implemented, like any language, in many ways. This include full interpretation, bytecode compilation, and native compilation. See Java language specification
The VM specification defines how bytecode should be loaded and executed. It defines the compiled class format, and the execution semantics, e.g. threading issue, and what is called the "memory model". See Java VM specification
While orignally meant to go together, the language and the VM are distinct specifications. You can compile another language to Java bytecode and run it on top of the JVM. And you can implement the Java language in different way, notably without a VM, as long as you follow the expected semantics.
Of course, both are still related, and certain aspects of Java might be hard to support without bytecode interpretation at all, e.g. custom ClassLoader that return bytecode (see ClassLoader.defineClass). I guess the bytecode would need to be JIT'ed immediatly into native code, or maybe are not supported at all.
Which platform native code should it compile to?
Windows, Mac, Linux?
What if the developer works on a different platform than the application is going to run on?
What if the application platform changes, either in the server room or on the desktop?
I don't see the benefit, the JVM's nowadays seem to be to be fast enough for very general purpose needs.
There are several products out there to compile java programs to native code, however they are imperfect, and not at all like the JIT compiler. Some differences include:
Write Once Run Everywhere - it will only work on the target you compile it for.
Dynamic code - you cannot load jars or other Java code at runtime, which is often a feature of application servers, GUI builders and the like.
Runtime profiling - a lot of JIT compiler action involves understanding what the code is doing at runtime, not what it could potentially do under a static analysis, meaning that JIT can outperform a natively compiled application in the right circumstances.
Cannot support all Java features. Things like reflection aren't going to be very meaningful in a compiled program.
Large footprint - when it is compiled to native code, all of the libraries the JVM gives you have to be bundled into the package, causing a very large footprint. It is a tricky problem to figure out what can be left out.
So it is possible, for a certain subset of applications, to compile to native code, but as VMs have gotten faster and faster, and issue #5 above has not really been improved (although project Jigsaw should help with that), it is not a very compelling option for real world applications.
Because it is enough to have byte-code compiled.
If you would compile your own code - you had also compile all libraries.
And it is real problem from two point of view:
1. licensing - most of the code wouldn't be changed
2. you had 'recompile' megatons of code :-)
This was a decision made by Sun to not allow this because they wanted to position Java as being inherently multi-platform. As such, they wanted to ensure that any Java application compiled would run on any platform with a JVM. This prevents there from being Java binaries available on-line which don't run on certain hardware or operating systems.
I have been hearing a lot lately regarding Scala, Clojure, etc which is supposed to run on JVM.
Does this means that those languages are implementing the Java API underneath?
What does it mean for a language to run under JVM?
Thanks.
It means that these languages can be compiled into Java bytecode, which the JVM executes.
It means that the language compiles down to JVM byte code at some point. The language doesn't need to implement the Java API; the Java API is already there (more or less all the time).
It just means if you have a JVM you should be able to run the language without another VM (although you'll need whatever class files the language compiler and libraries need, obviously).
There is a Virtual machine that java runs one (JVM ),which abstracts away more machine level worries. These languages just use it as an intermediate language oppose to writing architecture specific instructions.
Usually, it just means that you have to install JRE to make sure they can execute.
And usually they don't require JDK, which is used to compile .java code into .class byte file. Instead, they provide their own compiler which runs on the JRE you have installed.
So in summary, you just need a runtime support Java (some specific version).
if you need an in depth information: normabmcclelland#linuxmirroreast.com