This question already has answers here:
What are advantages of bytecode over native code? [closed]
(8 answers)
Closed 7 years ago.
As I read is bytecode an intermediate language which is used by a virtual machine which has to be installed on the computer to run the program. Wikipedia says, that a VM either executes the bytecode directly or generates machine code for better performance. The article also says, that bytecode is a set of instructions. For me it sounds like normal machine code, except that only the VM can understand it (Am I right?).
So what is the purpose of bytecode? If a VM can also compile it to machine code why can't the compiler do it directly and we don't need the VM and have better performance?
This may not be the best place for this question, but it depends. In the case of Java, portability is king.
Windows applications have the advantage that you can rely on many of the system libraries not being compiled with the program. It also extends portability since the code will not depend on architecture (generally.)
More generally, you can generate byte code compilers that can generate code to the same byte code standard in many languages, providing easy interoperability between modules. (like in. NET a c# library can be referenced in a VB project)
There is certainly a much more in depth explanation, but generally these are the advantages.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have a query in which I cannot give a satisfactory answer. Java is notorious for its independence over machine architectures grace to JVM. I 've understood the following:
Different JVM implementations are sitting on different machines as to produce the appropriate output (different for any different architecture) from the same input(.class files).
Let's now consider C++. Why not to do the same with Java? Namely, implement different C++ compiler versions for different architectures, feed them with the same source and make every compiler produce the appropriate output; just make C++ compiler to mimic JVM!
This is my query since I cannot understand why Java is unique in that...
The C++ compiler already does that. The difference is that whereas class files are interpreted by the JVM, C++ applications aren't (usually) distributed as source files.
This of course also requires that you use standard libraries which are available for all the platforms. There's nothing very magical here. You have compiled languages such as C++, partially compiled like Java and interpreted such as Ruby.
As far as I know this is exactly what happens (as Kayaman said). You write one source, and compile it for different platforms, for example gcc/mingw or visual for Windows, gcc for Linux etc.
The difference between C/C++ and Java is that from C and C++ it is much easier to do direct system calls, to directly work with the filesystem, with sound devices etc. These system calls will differ for each system, which is what makes the code not portable. This means that portability for C++ code is the choice of the programmer.
Because if you do that you have Java. If C++ doesn't have a direct connection with the low level resources than lots of advantages of this language disappear. It's kind of the same thing with C++ and assembling language. Creating a more high-level language will have a negative effect on the control of the machine's resources.
Read this about Java: Java Architecture
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is Java a Compiled or an interpreted programming language?
Why is Java both compiled and interpreted language?
We first compiles the java program using javac(compiling) and the run the program using java(interpreting). What is the advantage of that?
Also, where does JIT role come into the picture?
Compile once and run anywhere is one of the reasons.
JVM is OS specific. So, JVM interprets compiled .class (byte code) file and converts into machine specific instruction set.
The Java compiler typically compiles source code into an intermediate language, expressed generically as "byte code". That itself is not machine code for your native hardware, but in a sense it is "machine" code for the Java virtual machine.
The benefit of this separation is that (in theory) you can implement a VM on many different platforms, but all of them will be able to run the same compiled Java byte code.
A just-in-time compiler is part of a hypothetical VM, and actually translates bits of byte code dynamically into real, native machine code, as and when needed. This grew out of the observation that running a Java program purely in a VM was a lot slower than equivalent native code. JIT compilation has made the Java VM competitive in terms of performance when compared to natively compiled code.
Java is "compiled" into byte code
The byte code is "interpreted" as the program executes
A JIT compiler and "precompile" byte code into native machine code, optimizing execution time
Here is an article giving more details about Java JIT:
http://en.wikipedia.org/wiki/Just-in-time_compilation
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Java is designed to run in a “Sandboxed” environment in contrast to C which is not constrained. Discuss the implications of this from a security point of view.
I have done a bit of research in regards to the concept. What I found was if it's sandboxed where Java runs on, it goes through a more controlled door to retrieve information from different parts of memory. However, in C, it doesn't where it is uncontrolled.
Can someone please explain if there is anything else that I can add?
Edit:
This is what I have added:
Java programming language is an object-oriented language specifically designed to have as few implementation dependencies as possible. Java is write once deploy many times model. It is superficially like C/C++/C# but have different underlying object model. There are many versions of Java such as Java Standard Edition (Java SE), Java Mobile Edition (Java ME), Java Enterprise Edition (Java EE) etc.
The applications written in java are compiled to Java byte code which is an intermediate language independent of any platform. Thus, compiler can work multi platform.
The Virtual Machine model of compilation and execution works by running the compiled code (Java byte code) on Java Virtual Machine (JVM). Java Virtual Machine interprets java byte code and provides an environment in which Java byte code can be executed. The use of the same byte code for all JVMs on all platforms allow Java to be described as a “write once, run anywhere”.
This is better model than the compiler that generates native code due to following reasons:
Mobile devices come in various shape and sizes and with varying processor speed and architecture. Therefore, the virtual machine model of compilation and execution allows all java apps to run on various different mobile platforms once JVM is implemented on a device.
The virtual machine mode of compilation provide a platform-independent programming environment that abstracts away details of the underlying hardware or operating system, and allows a program to execute in the same way on any platform.
Performance comparable to compiled programming languages is achieved by the use of just-in-time compilation (a method to improve the runtime performance of computer program).
Compilation from byte code to machine code is much faster than compiling from source.
The deployed byte code is portable, unlike native code.
Since the runtime has control over the compilation, like interpreted byte code, it can run in a secure sandbox. Compilers from byte code to machine code are easier to write, because the portable byte code compiler has already done much of the work.
Don't mix languages and virtualisation.
Google's Native Client (NaCL) is a sandboxed environment for C/C++ (and everything else) programs, for example.
Here is a 'quick sampling' of the most common security challenges for sand-boxed code, off the top of my head.
In a sand-boxed app. restrictions will be added in the areas of:
Printing.
Cross-domain resource access.
Copy/Paste.
Import/export of resources from/to the local file system.
Applet calling System.exit(n).
Call applet methods from JavaScript..
Warnings attached to free floating elements. Which can even apply to tool-tips of apps. using 3rd party PLAFs.
Access to a variety of properties (e.g. user.*, any number of java.* props)
Load and use natives (that should be obvious).
Start processes.
Redirect output or error streams.
Record sound or video.
Access to the Robot.
..
If this question is about 'security', you have a lot of research to do. ;)
Java is inherently "sandboxable", whereas C++ et al are not. In Java there is no way to get outside of an object -- you can't freely cast an object pointer to char*, for instance, and you can't address beyond the end of an array.
Access to system facilities is limited by in several ways (some of which I forget just now). But basically one can run a Java program that loads secure class loaders and the like, and then any application that is loaded in that environment is "corralled" and cannot do anything that you don't wish to let it do.
(In fact, the "classic" JVM on IBM iSeries made use of these features to prevent even the "main" Java program from running amok. Java code ran in the same address space as the OS, but still the OS was protected by Java's inherent security.)
In C++ et al, in order to accomplish the same thing, you either have to make use of storage protection hardware or else have a compiler that compiles in checks of every access.
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
After reading the Java White Paper, I have a question on my mind and it might not be a very smart question but here it is anyway:
From what I gathered, Java attempted to improve an a number of fallacies associated with C++ such as redundancy, confusion with pointers, full-object orientation etc.,
If Java managed to overcome these issues, why would it be incorret to say that Java can replace C++.
There are many situations where C++ is a better option than Java. Comparison here.
Specifically:
In addition to running a compiled Java program, computers running Java
applications generally must also run the Java Virtual Machine JVM,
while compiled C++ programs can be run without external applications.
Early versions of Java were significantly outperformed by statically
compiled languages such as C++. This is because the program statements
of these two closely related languages may compile to a few machine
instructions with C++, while compiling into several byte codes
involving several machine instructions each when interpreted by a JVM.
Certain inefficiencies are inherent to the Java language itself,
primarily:
All objects are allocated on the heap. For functions using small objects this can result in performance degradation as stack
allocation, in contrast, costs essentially zero. However, this
advantage is obsoleted by modern JIT compilers utilising escape
analysis or escape detection to allocate objects on the stack. Escape
analysis was introduced in Oracle JDK 6.
Methods are by-default virtual. This slightly increases memory usage by adding a single pointer to a virtual table per each object.
Also, it induces a startup performance penalty, because a JIT compiler
has to do additional optimization passes even for de-virtualization of
small functions.
A lot of casting required even using standard containers induces a performance penalty. However, most of these casts are statically
eliminated by the JIT compiler, and the casts that remain in the code
usually do not cost more than a single CPU cycle on modern processors,
thanks to branch prediction.
Array access must be safe. The compiler is required to put appropriate range checks in the code. Naive approach of guarding each
array access with a range check is not efficient, so most JIT
compilers generate range check instructions only if they cannot
statically prove the array access is safe. Even if all runtime range
checks cannot be statically elided, JIT compilers try to move them out
of inner loops to make the performance degradation as low as possible.
Lack of access to low level details does not allow the developer to better optimize the program where the compiler is unable to do
so.[10]. Programmers can interface with the OS directly by providing
code in C or C++ and calling that code from Java by means of JNI.
Also as an iOS/Mac dev, and strong background in DSP, and lover of many open source C++ and Objective C libraries, I could go on and on as to why Java is not better...
Java didn't have the same goals and so doesn't serve the same function as C++. In other words, Java may have made some improvements, but also some regressions in things that are important for C++ applications.
Therefore Java cannot simply replace C++.
Your question is kind of off-topic for this forum (it's not about a programming problem). Nevertheless, here's my two cents.
Java and C++ serve different needs. For instance, while pointers in C++ (as in C) are certainly complicated, it is precisely because of pointers that one can manipulate specific addresses in memory. This is quite valuable for certain applications and impossible to do in Java (without resorting to native methods—often implemented in (ahem) C++).
C++ is compiled into machine code native to the machine. Java is compiled into machine-independent byte code. Thus C++ tends to have a speed advantage. This is offset somewhat, but not entirely, by just-in-time compilers for Java.
I'm sure others here will post additional differences between the two.
Java is a reasonably good application development platform.
It is not a systems development platform. It can't provide direct access to hardware. It can't be used to implement a Java Virtual Machine (chicken and egg problem).
So you will always need a language that compiles to native code in order to bootstrap your high-level runtime.
Because C++ is often still a factor faster in applications and the JRE hasn't been ported to all platforms/OS's.
Other than that, not everyone agrees that, just from a design perspective, Java is an improvement on C++.
The main answer is probably that the language syntax is not what matters the most. C++ is designed to be compiled as native applications, while Java is designed to be compiled as Java bytecode applications, which run on a Java Virtual Machine.