I have simple java programm that will just print Hello World.Can it be possible to print without using JVM installed in a machine ?But compiler is there.
You can compile Java Byte Code to Machine Code using something like this:
http://en.wikipedia.org/wiki/GNU_Compiler_for_Java
Or you can use any of the MANY Java to C/C++ converters out there to make a C/C++ version, and compile that. (Search Google for "Java C Converter")
Warning: I have never tried any of these, including the linked GNU Compiler, so I cannot make any attestations to their usefulness or quality.
#SplinterReality already pointed you to some compilers (googling "java bytecode to native code compiler" will show you some more options).
I will just expand on that seeing some people are a bit confused:
The JVM is a program that takes java bytecode, which you get by running javac on your java source code (or you generate it in some other fashion). Bytecode is just a set of instructions that the JVM understands, it's there to give you a consistent set of opcodes which are platform independent. It's the JVM's job to then map those opcodes to native instructions, that's why JVMs are platform dependent. That's why when you compile your java source code to java bytecode you can run it on every platform.
That's why, whether you have java source or bytecode, you can take it and just compile it directly to native code (platform dependent, actually sometimes that's exactly what the JVM, and to be more precise the JIT, does - it compiles stuff to native code when it sees the need to). Still there's more to the JVM than just bytecode interpretation - for instance you need to take care of garbage collection.
So the answer is: yes, but do you really want to do it? Unless you want to be running it on some embedded systems I don't really see any reason to.
Yees, it is possible to run a java program without a JVM, albeit with limitations. Aside from the http://en.wikipedia.org/wiki/GNU_Compiler_for_Java , there is the GraalVM native-image generator, which could be used : https://www.graalvm.org.
If that program is a one file source code (not compiled in bytecode) then you can ;)
Here or here. Here will be fine as well ;)
Just put it there and press compile and run.
But it will work only with simple stuff only, and you have to have source code.
I would not be surprised if there would be a site that would allowed to upload class from users PC
Related
I studied somewhere that to execute on different processor architectures Java is interpreted. If it would use compiler then there would be some (Machine Code) instructions which would be specific to processor architectures and Java would be platform dependent.
But since java use interpreter it is processor architecture independent.
My question is how can the java use JIT (Just In Time) Compiler? Doesn't the processor's architectures affect it? If it doesn't affect it, then why doesn't it affect it?
There isn't just one JIT compiler. There is a different one for each architecture, so there's one for Windows 32-bit, one for Windows 64-bit etc.
Your Java code is the same across all platforms. That is compiled into byte code by the Java compiler. The byte code is also the same across all platforms.
Now we run your Java program on Windows 32-bit. The JVM starts up and it interprets the byte code and turns that into machine code for that architecture. Note that that JVM is specifically for this architecture.
If we run your program on another architecture, another variation of the JVM will be used to interpret the byte code.
That's why you see all these different download links when you download the JRE:
Your java code is interpreted to byte code and is not platform dependent. But to run your machine code you need a JVM, the JVM is platform dependent, you cannot download an x86 JVM and run it on an ARM processor and vice versa.
The idea is that the JVM is platform dependent but your code is not.
The java program life cycle goes as follows.
Source code is compiled into Java Byte Code (aka .class files),
Java Byte Code is then interpreted by the JVM which performs the Just In Time compilation sending instructions your specific processor architecture can understand.
Its important to understand that compilation is just another way to say "translation", and does not always mean compiling to binary. Also, interpretation is similar, but is done per instruction, as needed by the program.
But more specifically in your question, JIT is the interpretation done by the JVM, which is coded specifically for each processor architecture.
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 6 years ago.
Improve this question
I am new to java and bit confused about the role of compiler and JVM . I have read couple of resources and to name few
What-are-the-functions-of-Java-Compiler ?
Is the JVM a compiler or an interpreter?
Compiler
As i save the file .java file in system, computer internally saves it in bytes 0 and 1's. I understand compiler is validating whether written java program
confirms to java standard or not. If not throws the error otherwise jenerate the class file.
My question is what is need of generating .class file.
Can't
JVM interpret it directly (from bytes generated corresponding to .java file) without needing .class file? Does compiler(javac) do any kind of optimization here ?
JVM :- This question is other way around. Can't compiler generate the byte/machine code which can be interpreted by CPU directly? so why JVM is needed here ?
Is JVM required to interpret the byte code specific to platform for example windows or linux ?
The compiler generates byte code, in a Java meaning, which is a .class file, containing the byte code, which is not made of 1 or 0, no matter what OS you are running on.
And JVM interprets byte code to run it on specific OS
The main point of having these two stages and intermediate representation ("byte code" in Java) is platform-independence.
The Java program, in a source code, is platform-independent (to a degree). When you compile it into byte code, the Java compiler basically does (almost) all of the things it can do while still maintaining the platform-independence:
validates syntax
performs static type checks
translates human-readable source code into machine-readable byte code
does static optimizations
etc.
These are all things, that:
maintain platform-independence
only need to be performed once, since they don't rely on any run-time data
take (possibly long) time to do so it would be waste of time to do them again each time the code is executed
So now you have .class files with byte code, which are still platform-independent and can be distributed to different OS or even hardware platform.
And then the second step is the JVM. The JVM itself is platform-specific, and it's task is to translate/compile/interpret the byte code on the target architecture and OS. That means:
translate byte code to the instruction set of given platform, and using target OS system calls
run-time optimizations
etc.
What-are-the-functions-of-Java-Compiler ?
'Javac' is a Java compiler which produces byte-code(.class File) and that code is platform-independent.
Is the JVM a compiler or an interpreter? Ans- Interpreter
JVM is Java Virtual Machine -- Runs/ Interprets/ translates Bytecode into Native Machine Code and it internally uses JIT
JIT Compiles the given bytecode instruction sequence to machine code at runtime before executing it natively and do all the heavy optimizations.
All the above complexities exists to make java compile once run anywhere or Platform independent Language and Because of that bytecode or JAVAC Output is platform-independent but JVM executing that bytecode is Platform-dependent i.e we have different JVM for Windows and Unix.
A JVM, is an implementation of the Java Virtual Machine Specification. It interprets compiled Java binary code (called bytecode) for a computer's processor (or "hardware platform").
JVM is the target machine for byte-code instead of the underlying architecture.
The Java compiler ,'Javac' produces byte-code which is platform-independent. This byte-code is, we can say generic, ie., it does not include machine level details, which are specific to each platform.
The instructions in this byte-code cannot be directly run by the CPU.
Therefore some other 'program' is needed which can interpret the code, and give the CPU machine level instructions which it can execute. This program is the 'JVM' (Java Virtual Machine) which is platform specific.
That's why you have different JVM for Windows, Linux or Solaris.
I think first we should discuss the difference between executing an interpreted runtime vs a machinecode runtime vs a bytecode runtime.
In an interpreted runtime the (generally human readable) source code is converted to machine code by the interpreter only at the point when the code is run. Generally this confers advantages such that code is platform independent (so long as an interpreter exists for your platform) and ease of debugging (the code is right there in front of you) but at the cost of relatively slow execution speed as you have the overhead of converting the source code into machine code when you run the program.
In a compiled runtime the source code has been compiled into native machine code ahead of time by a dedicated compiler. This gives fast execution speed (because the code is already in the format expected by the processor), but means that the thing you distribute (the compiled binary) is generally tied to a given platform.
A bytecode runtime is sort of a halfway house that aims to give the advantages of both intepretation and compilation. In this case the source code is complied down into an intermediate format (byte code) ahead of time and then converted into machine code at runtime. The byte code is designed to be machine friendly rather than human friendly which means it's much faster to convert to machine code than in a traditionally interpreted language. Additionally, because the actual conversion to machine code is being done at run time, you still get all that nice platform independence.
Note that the choice of whether to intepret or compile is independent of the language used: for example there is no reason in theory why you could not have a c intepreter or compile python directly into machine code. Of course in practise most languages are generally only either compiled or interpreted.
So this brings us back to the question of what the Java compiler does- essentially it's main job is to turn all your nice human readable java files into java bytecode (class files) so that the JVM can efficiently execute them.
The JVM's main job, on the other hand, is to take those class files and turn them into machine code at execution time. Of course it also does other stuff (for example it manages your memory and it provides various standard libraries), but from the point of view of your question it's the conversion to machine code that's important!
Java bytecode is an intermediate, compact, way of representing a series of operations. The processor can't execute these directly. A processor executes machine instructions. They are the only thing that a processor can understands.
The JVM processes stream of bytecode operations and interprets them into a series of machine instructions for the processor to execute.
My question is what is need of generating .class file. Can't JVM interpret it directly (from bytes generated corresponding to .java file) without needing .class file? Does compiler (javac) do any kind of optimization here ?
The javac generate .class file which is an intermediate thing to achieve platform independence.
To see what compiler optimized, simply decompile the bytecode, for instance with javap or JD.
This question is other way around. Can't compiler generate the byte/machine code which can be interpreted by CPU directly? so why JVM is needed here ? Is JVM required to interpret the byte code specific to platform for example windows or linux ?
The designers of the Java language decided that the language and the compiled code was going to be platform independent, but since the code eventually has to run on a physical platform, they opted to put all the platform dependent code in the JVM. Hence for this reason we need JVM to execute code.
To see what the just in time compiler optimized, activate debug logging and read the disassembled machine code.
I'm confused about the advantage of an interpreted language like java, over a compiled language.
The standard explanation for the advantage of an interpreted language, such as java, over a compiled language is that the same .class file can run on different types of machine architectures. How doe this save you any work?
For each different machine architecture, wouldn't you need a different compiler to interpret the same .class file into the machine language? So if you need a different compiler for each different machine architecture to interpret the same .class file into machine code, how does this save you any work?
Why not just makes a compiled language where the .java source file is compiled into machine language right away. Sure this would require a different compiler to compile from the java source file to machine language for each machine architecture, but how is this any more work than having to have a different compiler for each machine compile from a .class file to machine language?
I mean this is the same as with a compiled language -- you need a compiler for each machine architecture whether it's compiling a java source file into machine code or a class file into machine code.
thanks.
First, the claim that "Java is interpreted", while it has some basis in truth, is pretty misleading, and it's probably best if you simply delete that notion from your head.
Java is compiled from source code to an intermediate representation (classfiles, bytecode) at build time. When a class is first loaded, most JVM implementations (including Oracle HotSpot, and IBM J9) will go through a short-lived interpretation phase, but if the class is going to be used with any frequency, a dynamic compiler (JIT) will run and compile to native code. (Some JVMs, like JRockit, go directly to native with no interpreter.)
I think "Why isn't Java compiled directly to native code" is the real question here. The obvious answer, as others have suggested, is portability. But its more subtle than that: dynamic compilation yields higher quality code than static compilation. When the code is compiled dynamically, the JIT knows things that no static compiler could know: characteristics of the current hardware (CPU version, stepping level, cache line size, etc), as well as properties of the current run (thanks to profiling data gathered during interpretation.) The quality of your decisions is dependent on the quality of your information; a dynamic compiler has more and better information available to it than a static compiler ever could, and so can produce better code.
Further, dynamic compilers have the possibility to perform optimizations that no static compiler could dream of. For example, dynamic compilers can do speculative optimizations, and back them out if they turn out to be ineffective or if their assumptions later become incorrect. (See "Dynamic Deoptimization" here: http://www.ibm.com/developerworks/library/j-jtp12214/).
For each different machine architecture, wouldn't you need a different
compiler to interpret the same .class file into the machine language?
So if you need a different compiler for each different machine
architecture to interpret the same .class file into machine code, how
does this save you any work?
The above statement is your core misunderstanding.
Application developers write Java code that is compiled to byte code that can run on any compliant Java Virtual Machine.
The Java Virtual Machine interprets (and possibly compiles) this bytecode and executes the application. These JVMs are developed for the major architectures and operating systems, such as Windows/Mac/Linux on Intel. The JVM developers are a relatively small group of engineers, such as those from Oracle and Sun.
From the application developers' point of view, he or she only has to compile once because the byte code (in the .class file) can be executed on compliant JVMs. Application developers do not need to worry about the underlying architecture or OS; they only need to target the architecture of the JVM. The JVM developers are the ones who deal with the underlying layer.
I like answer of sowrd299. My two cents:
you have technically endless different target architectures
and therefore compiling your code for all targets at the same time and packing it together would result an infinite big executable
therefore compiling Java against a virtual machine byte code is a better solution: since it has the footprint of only one target architecture
while developers can separately add JVMs for all new and old architectures, allowing total new stuffs (such as a Raspberry PI) run your java code compiled in the previous century.
On the other hand, the "compile for multiple targets in advance" is not a totally insane thing. Afaik Windows Universal Apps works this way: it is the same application in the same exe file, but actually the exe contains the code compiled for a 80x86 as well as for an ARM target. This way one application looks to be portable amongst windows mobile and desktop solutions without any further interpreting.
First, Java is a compiled language as well an interpreted language, because you have to compile from .java to .class.
To get the meat of your question, the advantage Java gains by being (somewhat) interpreted is you only need to compile each program once, and it can run on any computer, because the Java Runtime Environment (JRE), which is compiled in advance to match the local OS and architecture, can bridge that gap without (or with minimal) further compiling.
In an uninterpreted language, however, you must compile each program for each OS and each Architecture you want it to run on, which entails much more effort and total compile time than just compiling the JRE once for each OS and architecture and only compiling each individual program once.
It would be impractical to have a language that compiles for the local architecture each and every time it runs, because compiling is a rather intensive process. Python does compile each time it runs (though, like Java, it compiles for a Runtime Environment, not the local architecture) and it is one of the slowest languages out there.
Hopefully that helped clear things up.
Why we do we say that Java is a compiled and interpreted language?
What is the advantage of this (being compiled and interpreted)?
Java is compiled to an intermediate "byte code" at compilation time. This is in contrast to a language like C that is compiled to machine language at compilation time. The Java byte code cannot be directly executed on hardware the way that compiled C code can. Instead the byte code must be interpreted by the JVM (Java Virtual Machine) at runtime in order to be executed. The primary drawback of a language like C is that when it is compiled, that binary file will only work on one particular architecture (e.g. x86).
Interpreted languages like PHP are effectively system independent and rely on a system and architecture specific interpreter. This leads to much greater portability (the same PHP scripts work on Windows machines and Linux machines, etc.). However, this interpretation leads to a significant performance decrease. High-level languages like PHP require more time to interpret than machine-specific instructions that can be executed by the hardware.
Java seeks to find a compromise between a purely compiled language (with no portability) and a purely interpreted language (that is significantly slower). It accomplishes this by compiling the code into a form that is closer to machine language (actually, Java byte code is a machine language, simply for the Java Virtual Machine), but can still be easily transported between architectures. Because Java still requires a software layer for execution (the JVM) it is an interpreted language. However, the interpreter (the JVM) operates on an intermediate form known as byte code rather than on the raw source files. This byte code is generated at compile time by the Java compiler. Therefore, Java is also a compiled language. By operating this way, Java gets some of the benefits of compiled languages, while also getting some of the benefits of interpreted languages. However, it also inherits some limitations from both of these languages.
As Bozho points out, there are some strategies for increasing the performance of Java code (and other byte code languages like .Net) through the use of Just in Time (JIT) compilation. The actual process varies from implementation to implementation based on the requirements, but the end-result is that the original code is compiled into byte code at compile time, but then it is run through a compiler at runtime before it is executed. By doing this, the code can be executed at near-native speeds. Some platforms (I believe .Net does this) save the result of the JIT compilation, replacing the byte code. By doing this, all future executions of the program will execute as though the program was natively compiled from the beginning.
Why do we say Java is compiled and interpreted language.
Because source code (.java files) is compiled into bytecode (.class files) that is then interpreted by a Java Virtual Machine (also known as a JVM) for execution (the JVM can do further optimization but this is anoher story).
What is the advantage over this(being compiled/interpreted)
Portability. The same bytecode can be executed on any platform as long as a JVM is installed ("compile once, run anywhere").
This is a long topic and you'd better read about JIT. In short, Java is compiled to bytecode, and the bytecode is later compiled (in the JVM) to machine code.
Java is considered a "compiled" language because code is compiled into bytecode format that is then run by the Java Virtual Machine (JVM). This gives several advantages in the realm of performance and code optimization, not to mention ensuring code correctness.
It is considered an "interpreted" language because, after the bytecode is compiled, it is runnable on any machine that has a JVM installed. It is in this way that Java is much like an interpreted language in that, for the most part, it doesn't depend on the platform on which is is being run. This behavior is similar to other interpreted languages such as Perl, Python, PHP, etc.
One theoretical downside to the fact that Java programs can be run on any system in absence of the source code is that, while this method of distribution ensures cross-platform compatibility, the developers have one less reason to release their source code, driving a wedge between the ideological meanings of the phrases "cross-platform" and "open source".
Java is compiled, into byte code not binaries. The byte codes are not executable directly, they need the Java Virtual Machine to do a just in time compile and compile them again into machine code at runtime.
At a very basic level, it separate the code that programmers write from the local machine where the JVM operates on, hence better portability. While compiling to bytecode helps the performance of just in time compile, reduce file sizes, and more or less help conceal real code. (it also eliminates some compile time error)
Compiled: Your program is syntactically a correct Java program, before the program starts.
Interpreted: Run on different platforms the same (byte-)code.
Compiled: When your program has compiled correctly you can be shure to have 80% of software bugs under control. And your code will not stop because you have not correctly closed a code block, etc.
Interpreted: You know what Applets are ? It was the "killer" application when Java came out. Your browser downloads the applet from the website and run the applet code in your browser. That is not very cool. But, the same applet runs on Windows, Linux, Macs, Solaris, ... because runs/interpreted an intermedium language: the byte code.
I was briefly reading about Maxine which is an open source JVM implementation that written in Java. This sounds circular to me. If java requires a virtual machine to run in, how can the virtual machine itself be written in Java (won't the VM code require a VM in which to run, and so on?).
Edit: Ok, so I see I overlooked the fact that Java doesn't have to run in a VM. How then does one explain how a LISP compiler can be written in LISP? Or should this be a new question altogether?
Your assumption that Java requires a virtual machine is incorrect to begin with. Check out the project GCJ: The GNU Compiler for the Java Programming Language.
You are asking about the chicken and the egg.
Read: http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29
The JVM that you need to bootstrap a JVM written in Java probably does not need a lot of features (such as garbage collection and JIT), could be very simple. All the more advanced features could then be implemented in Java (which seems to be exactly the point of Maxine, to experiment with new ideas in JVM technology).
Also, Maxine does contain C code, which I guess makes up a minimal runtime environment that is used to get the rest of Maxine going. I take it that the interesting bits (JIT compiler, garbage collection) are then completely implemented in Java.
See bootstrapping.
Java code can be compiled directly to machine code so that a virtual machine is not needed.
I had a look at Maxine last week and was wondering the same :)
From the Maxine documentation:
1 Building the boot image
Now let's build a [boot image]. In
this step, Maxine runs on a host JVM
to configure a prototype, then
compiles its own code and data to
create an executable program for the
target platform.
2 Running Maxine
Now that Maxine has compiled itself,
we can run it as a standard Java VM.
The max vm command handles the details
of class and library paths and
provides an interface similar to the
standard java launcher command.
You can have a look at the well-established method of bootstrapping compilers. I think it started in the 70s...
It is kinda 'whooaoaa man, how can that work???' - but I think you are describing the phenomenon known as 'self-hosting':
Languages (or toolchains/platforms) don't start out as self-hosting - they start off life having been built on an existing platform: at a certain point they become functional enough to allow programs to be written which understand the syntax which it itself happens to be written in.
There is a great example in the classic AWK book, which introduces an AWK program which can parse (a cut-down version as it happens) other AWK programs: see link below.
There is another example in the book "Beautiful Code" which has a Javascript program which can parse Javascript.
I think the thing to remember on this - if you have (say) a JVM written in Java which can therefore run Java Byte code: the JVM which runs the Java JVM itself has to be hosted natively (perhaps this JVM was written in 'C' and then compiled to machine code) : this is true in any case of a self-hosting program eventually - somewhere along the line.
So the mystery is removed - because at some point, there is a native machine-code program running below everything.
It kinda of equivalent of being able to describe the English (etc) language using the English language itself....maybe...
http://www.amazon.co.uk/AWK-Programming-Language-Alfred-Aho/dp/020107981X/ref=sr_1_fkmr0_3?ie=UTF8&qid=1266397076&sr=8-3-fkmr0
http://www.amazon.co.uk/gp/search/ref=a9_sc_1?rh=i%3Astripbooks%2Ck%3Abeautiful+code&keywords=beautiful+code&ie=UTF8&qid=1266397435
http://en.wikipedia.org/wiki/Self-hosting
I know this post is old but I thought I might add a little to the discussion as they are points that have been missed. So future readers may find this helpful.
I wonder if everyone is missing the point here. You can write most any kind of compiler, interpreter, or virtual machine in almost any language. When using C to write a C compiler a C compiler is needed to compile the new compiler. However, the output is native code that runs on the designated platform. Just because the JVM is written in the language that runs on the JVM doesn't mean the output must result in code that runs on the JVM. For instance you can write C, Basic, Pascal Compilers or even assemblers in Java. In this case you will need the JVM to create the compiler or assembler but once created you may no longer need the JVM if the initial code resulted in native code. Another approach is to write a translator that takes an input language and converts it to a native machine language so that you write your program in language A which compiles into language B which which is then compiled into machine code. In the micro controller world you see this a lot. Someone wants to write programs in Basic or Java so they write the Basic/Java compiler to produce C code for an existing C compiler. Then the resultant C code is compiled into machine language providing the native Basic/Java compiler. This approach is usually easier than writing the Basic/Java compiler directly in machine code.
Many years ago I wrote BasicA and GWBasic programs that produced assembly code to 6800 and Z80 micros. My point is that the output need not be of the same ilk as the input or target. I.E. Just because you're writing a JVM in Java doesn't mean the final result must be ran under a Java JVM.
Here is a good paper on bootstraping a self-hosted VM. It's not Java, but javascript, but the principles are the same.
Bootstrapping a self-hosted research virtual machine for JavaScript: an experience report
Note that while bootstraping a self-host compiler and bootstraping a self-hosted VM are somewhat similar, I believe they do not raise the exact same challenges.