I've recently been experimenting with Processing (https://processing.org/).
It's a sort of IDE used to make GUI design in Java easier. Since I'm not a fan of swing or AWT, I found it quite fun to use.
Something interesting to note though. When I "export" the Application for windows, it creates both a 32-bit and 64-bit version.
I'm a little confused as I thought after Java source code is compiled to Java bytecode, it can be run anywhere as long as that place as a JVM. (Write once, run anywhere).
So why are both a 32 bit and 64 bit version of the app created? Shouldn't the bytecode be platform independent and only be translated using Just-In-Time compilation to whichever architecture the JVM is on, during runtime? At least, I know that's how .NET does it with the CLR.
I'm going to attempt to answer my own question by saying since the applications created are .exe files, the translation to native architecture happened ALREADY, since windows was specified as a target-platform...I guess to increase efficiency?
Otherwise, I'm confused. The only time I've seen a compilation happen twice is when I was programming C++, and needed to compile twice for 32-bit and 64-bit.
Thank you!
Processing is built on top of JOGL which is (basically) a Java wrapper of OpenGL, which is a device-specific graphics library.
Also, Processing (can) include a whole JVM with its exported applications, so end users don't have to worry about downloading Java. The JVM itself is OS-dependent, so the exported application is as well.
You can confirm this by taking a look at the files that Processing creates. Specifically, notice these files:
jogl-rt-natives-windows-amd64.jar
jogl-all-natives-windows-amd64.jar
These .jar files contain the native files required by JOGL.
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.
I am fairly new to Java or programming in general. On my journeys through the internet to master this language I have come up the saying "write once run anywhere" multiple times.
But I have found many software that requires you to pick the right version for your OS. Sometimes there is only one version available.
Could you explain to me why that is so?
[expanded per the comments]
Java runs on a Virtual Machine, the JVM. In an ideal world this means that the Operating System is abstracted away behind this and you only have to make sure your code works with the JVM which will make it work with the underlying OS. This can already be undone by using the wrong path separators or line endings; it is not an absolute truth.
An application can use many Operating System-specific approaches/libraries/functions/etc that might make it not feasible to restrict yourself to one general codebase. Instead they might want to leverage some advantages provided by a platform and create a separate application with it.
The statement should probably be somewhere along the lines of "Write once in a general fashion, run anywhere" but that's not as snappy.
This statement is often linked to Java but there are also other languages that incorporate this: weblanguages like Javascript and HTML will run on any browser because the browser itself forms the abstraction between the language and the underlying OS.
Other languages don't have this (entirely?) since they work differently: C# will use the underlying .NET framework which as it is only exists for Windows. There exists a cross platform variant (Mono) but it would be an overstatement to consider C# truly cross platform.
The Java program or source code is compiled to generate "bytecodes" ( an intermediate binary format). Second, the bytecodes is executed by an interpreter which is part of the Java Virtual Machine (JVM).
"Write Once, Run Everywhere" refers to the fact that an application written is Java can be run on any hardware which has the Java Virtual Machine (JVM), and that the JVM is now licensed to hundreds of operating systems vendors systems including Microsoft for Windows.
Well, some stuff is really cross-platform (most of standard Java library), while some other stuff may need right version for the OS. Generally, this applies to software that uses dynamic libraries, that aren't written in Java. In this case, versions for different OSes are packed with libraries for this OS.
In case there's version only for one OS - it could be because required libraries don't exists for other OSes or developer didn't port it. There is still possibility that it's actually cross-platform, but developer tested it only under one OS.
Your question is more based on platform dependency/independency.
Java is a programming language which is platform independent which means the code which you write will produce the same output on all machines running Windows, Linus, Unix, etc... without any changes to the code. To run a Java program you need to have JVM (Java Virtual Machine) installed. Now what does JVM do.? Well, it translates your code into Machine code which the Operating System could understand. Therefore JVM is platform dependent since every OS has a different Machine code.
So, basically you write a Java Program only once and can be used/run everywhere.
you can write source code in one platform and run it any where.some times you can encounter problem if a new java version is available but still current version runs the code.
I'm reading Herbert Schildt's book "Java: The Complete Reference" and there he writes that Java is portable AND architecture-neutral. What is the difference between this two concepts? I couldn't understand it from the text.
Take a look at this white paper on Java.
Basically they're saying that in addition to running on multiple environments (because of being interpreted within the JVM), it also runs the same regardless of environment. The former is what makes it portable, the latter is what makes it architecture-neutral. For example, the size of an int does not vary based on platform; it's established by the JVM.
A portable C program:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
printf("Hello, World!");
return (EXIT_SUCCESS);
}
You can take that C program and compile it on any machine with a C compiler and have it work (assuming it supports printf... I am guessing some things out there may not).
If you compile it on Windows and try to run that binary on a Mac it won't work.
The same sort of program written in Java will also compile on any machine with a Java compiler installed, but the resulting .class file will also run on any machine with a Java VM. That is the architectural neutral part.
So, portable is a source code idea, while architectural neutral is an executable idea.
Looking around I found another book that describes the difference between the two.
For architecture neutral the compiler will generate an architecture-neutral object file meaning that compiled Java code (bytecode) can run on many processors given the presence of a Java runtime.
For portable it means there are are no implementation-dependent aspects of the specification. For instance in C++ an int can be 16-bit, or 32 bit depending on who is implementing the specification where as in Java an int is always 32 bit.
I got my information from a different book (Core Java 2: Fundamentals) so it may differ from his meaning. Here is a link: Core Java 2: Fundamentals
With architecture-neutral, the book means that the byte code is independent of the underlying platform that the program is running on. For example, it doesn't matter if your operating system is 32-bit or 64-bit, the Java byte code is exactly the same. You don't have to recompile your Java source code for 32-bit or 64-bit. (So, "architecture" refers to the CPU architecture).
"Portable" means that a program written to run on one operating system works on another operating system without changing anything. With Java, you don't even have to recompile the source code; a *.class file compiled on Windows, for example, works on Linux, Mac OS X or any other OS for which you have a Java virtual machine available.
Note that you have to take care with some things to make your Java code truly portable. If you for example hard-code Windows-style file paths (C:\Users\Myself...) in your Java application, it is not going to work on other operating systems.
I suspect that he means that code can run on many platforms without recompilation.
It is also possible to write code that deals with the underlying system without rewrites or conditions.
E.g. Serialized objects from a 32 bit Windows system can be read on a 64bit Linux system.
there are 3 related features in java.
platform independent -> this means that the java program can be run on any OS without considering its vendor. It is implemented by using the MAGIC CODE called "BYTE CODE". The JVM then either interprets this at runtime or uses JIT (Just in Time) compilation to compile it to machine code for the architecture that is being run on (e.g. i386).
architecture neutral -> it means the java program can be run on any processor irrespective of its vendor and architecture. so it avoids rebuilding problem.
portable -> a programming language/technology is said to be purely portable if it satisfies the above two features.
.class file is portable because it can run on any OS . The reason is , .class file generated by JVM is same for all OS. On the other hand JVM is differ as OS , but it generate same .class file for all OS, so JVM is architectural neutral.
What is difference between Architecture Neutral and Portable?
Architecture Neutral: Java is an Architecture neutral programming language because, java allows its application to compile on one hardware architecture and to execute on another hardware architecture.
Portable: Java is a portable programming language because, java is able to execute its application and all the operating system and all the hardware system.
In Terms of Java
Java Architecture Neutral - Here we are talking about the Operating System Architecture i.e the java Generate the Intermediate Byte-code(binary code) (handle by the JVM) and allow the java code to run on any O.S for which you have a Java virtual machine available( irrespective of its O.S architecture to handle memory allocation ,Cashing, register handling , bit code processing 32 bit or 64 bit while interpreting the code like each interpreter execute the code line by line - this is handle by jvm with respect to Hardware and O.S configuration) .
Portable (Generic meaning like transferable, Platform Independent, or even in terms of the Source code is fix for all i.e Simply means support to many)
Java Portable means java machine code write in one machine and will run on any machine that has proper JVM with respect to O.S.
I just started learning Java and I'm confused about the topic of platform independence.
Doesn't "independent" imply that Java code should run on any machine and need no special software to be installed? Yet the JVM needs to be present in the machine.
For example, we need to have the Turbo C Compiler in order to compile C/C++ source code and then execute it. The machine has to have the C compiler.
Could somebody please what is meant when Java is described as "platform independent"?
Typically, the compiled code is the exact set of instructions the CPU requires to "execute" the program. In Java, the compiled code is an exact set of instructions for a "virtual CPU" which is required to work the same on every physical machine.
So, in a sense, 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.
This requirement for a JVM is in contrast to your Turbo C example. With Turbo C, the compiler will produce platform dependent code, and there is no need for a JVM work-alike because the compiled Turbo C program can be executed by the CPU directly.
With Java, the CPU executes the JVM, which is platform dependent. This running JVM then executes the Java bytecode which is platform independent, provided that you have a JVM available for it to execute upon. You might say that writing Java code, you don't program for the code to be executed on the physical machine, you write the code to be executed on the Java Virtual Machine.
The only way that all this Java bytecode works on all Java virtual machines is that a rather strict standard has been written for how Java virtual machines work. This means that no matter what physical platform you are using, the part where the Java bytecode interfaces with the JVM is guaranteed to work only one way. Since all the JVMs work exactly the same, the same code works exactly the same everywhere without recompiling. If you can't pass the tests to make sure it's the same, you're not allowed to call your virtual machine a "Java virtual machine".
Of course, there are ways that you can break the portability of a Java program. You could write a program that looks for files only found on one operating system (cmd.exe for example). You could use JNI, which effectively allows you to put compiled C or C++ code into a class. You could use conventions that only work for a certain operating system (like assuming ":" separates directories). But you are guaranteed to never have to recompile your program for a different machine unless you're doing something really special (like JNI).
Technical Article on How java is platform indepedent?
Before going into the detail,first you have to understand what is the mean of platform?
Platform consists of the computer hardware(mainly architecture of the microprocessor)
and OS.
Platform=hardware+Operating System
Anything that is platform indepedent can run on any operating system and hardware.
Java is platform indepedent so java can run on any operating system and hardware.
Now question is how is it platform independent?
This is because of the magic of Byte Code which is OS indepedent.
When java compiler compiles any code then it generates the byte code not the machine native code(unlike C compiler). Now this
byte code needs an interpreter to execute on a machine. This interpreter is JVM. So JVM reads that byte code(that is machine indepedent)
amd execute it.
Different JVM is designed for different OS and byte code is able to run on different OS.
In case of C or C++(language that are not platform indepedent) compiler generate the .exe file that is OS depedent so when we
run this .exe file on another OS it will not run because this file is OS depedent so is not compatible with the another OS.
Finally an intermediate OS indepedent Byte code make the java platform independent.
It means the Java programmer does not (in theory) need to know machine or OS details. These details do exist and the JVM and class libraries handle them. Further, in sharp contrast to C, Java binaries (bytecode) can often be moved to entirely different systems without modifying or recompiling.
No, it's the other way around. It's because you use the virtual machine that the Java program gets independend.
The virtual machine is not independent, you have to install one that is specifically made for your type of system. The virtual machine creates an independent platform on top of the operating system.
The JVM is a "simulated machine" that can be installed on different systems. In this way, the same Java code can run on different systems, because it relies on the JVM, not on the operational system itself.
That is to say, this allows the programmer to communicate with the virtual system (JVM) and utilize its functions, instead of the specific machine and OS functions.
Since Java only relies on JVM, it is platform independent (if the platform has JVM installed).
So in short, Java is not platform independent as such, it requires a JVM-installation for all systems it should run on. However, it will run on all systems that has the JVM installed.
Java is platform-independent as it has JVM(Java virtual machine). Let us illustrate it with a real life example. Let's assume you are free to your family members. But why?
Because you know them well and they know you as well. But, you are not free to my family members. Because you don't know them and they don't know you either. But, if I'm your friend and when I can introduce you to my family members, hence you will be able to talk to them freely.
In a similar way, if you are a code and I am a JVM. Also, your family is windows platform and mine is the Linux platform. In the case you were a C or other platform-dependent languages, you only know your family members and vice versa. That's why only the platform on which you were written knows that Code and will support it. But if you are a JAVA code and when you come to my family viz. the Linux platform and if there you find me, JVM, then I can introduce you to my family, the Linux platform and you will be able to interact with it.
For platform-dependent languages, there isn't any friend like JVM available to them to introduce themselves to any platform family. That is how Java is platform-independent. :)
The JVM abstracts from the concrete platform. Your program relies only upon the JVM and since the JVM is available for different platforms like Windows and Linux, your program is platform independent (but jvm depended).
In c/c++ the source code(c program file) after the compilation using a compiler is directly converted to native machine code(which is understandable to particular machine on which u compiling the code). And hence the compiled code of c/c++ can not run on different OS.
But in case of Java : the source file of java(.java) will be compiled using JAVAC compiler(present in JDK) which provides the Byte code(.class file) which is understandable to any JVM installed on any OS(Physical System).
Here we need to have different JVM (which is platform dependent) for different operating Systems where we want to run the code, but the .class file(compiled code/Intermediate code)remains same, because it is understandable to any of the JVM installed on any OS.
In c/c++ : only source code is machine independent.
In Java : both the source code and the compiled code is platform independent.
This makes Java Platform(machine) independent.
java is not platform Independent, itself is a platform,based on that platform java apps runs,but java platform itself is platform dependent
1:jvm(i.e java virtual machine)is a collection of programs which contains lot of files which provides various functionatiles present on a folder(i.e collections of programs on middle level format)as called packages.jvm helps not to be overloaded on o/s where its helps to execute only the .class files or java applications only by itself only.It helps to make its equalities middle level format after compliation by the java compiler then its provide the byte code (.class file)reprsentation which is not specific to o/s and processor .
2:jvm makes byte code to .exe file for proccessor to understandable and prsents memory allocation for every functions after recieving frm byte code.
3:jvm also releases memory alocation from ram after control makes finishes thier execution .
JVM is os dependent.
for every os JVM different.
".class" is same for all JVMs.
so, every JVM understand that ".class" file data.
windows dependent JVM give windows dependent instruction to windows
linux dependent JVM give linux dependent instruction to linux.
that's like it for other operating systems.
so,java runs on any operating system.
that's why java is os independent.
In simple terms:
Java programming language is platform independent.
JVM is platform dependent
Java is not platform independent in that it runs on the JVM. Having said that, you gain platform independence via programming against a single abstract machine that has concrete realizations on most common OS platforms (and some embedded appliances).
A related idea is the hardware abstraction layer present in many operating systems that allows the same OS to run on disparate hardware.
In you original question, Turbo C is analagous to the javac program, and the JVM is the OS/HAL.
Doesn't independent means that Java code should be able to run on any machine and would need no special software to be installed (JVM in this case has to be present in the machine)?
With Java, you can compile source code on Windows and the compiled code (bytecode to be precise) can be executed (interpreted) on any platform running a JVM. So yes you need a JVM but the JVM can run any compiled code, the compiled code is platform independent.
In other words, you have both portability of source code and portability of compiled code.
Like, for example, we need to have Turbo C Compiler in order to compile C/C++ source code and then execute it.. The machine has to have the C compiler.
The machine doesn't have to have a C compiler, the machine has to use a platform specific binary. With C or C++, the compiled code is specific to each architecture, it is platform independent.
In other words, with C / C++ you have portability of source code (with some discipline) but not portability of compiled code: you need to recompile for each architecture into platform specific binaries.
JVM will be platform dependent.
But whatever it will generate that will be platform independent. [which we called as bytecode or simply you can say...the class file]. for that why Java is called Platform independent.
you can run the same class file on Mac as well on Windows but it will require JRE.
bytecode is not plateform independent, but its JVM that makes bytecode independent. Bytecode is not the matchine code. bytecodes are compact numeric codes, constants, and references (normally numeric addresses) which encode the result of parsing and semantic analysis of things like type, scope, and nesting depths of program objects. They therefore allow much better performance than direct interpretation of source code. bytecode needs to be interpreted before execution which is always done by JVM interpreter.
Just a side note to the discussion about JVM and JIT Compilation.
This is the same principle as with C# and the CLR and to some extent in Python, and when somebody says that the code runs "directly on hardware" that is actually true in that instructions that is already compiled will be able to take advantage of optimization on the machine/cpu it's being run on. So even if the initial compilation of a module is rather slow, the next time this module is run, the code being executed runs at native speed and thus runs directly on hardware so to say.
Java is platform independent in aspect of java developer,but this is not the case for the end-user, who need to have platform dependent JVM to run java code. Basically, when java code is compiled, a bytecode is generated which is typically platform independent. Thus, the developer has to have write a single code for entire platform series. But, this benefit comes with a headache for end-user who need to install JVM in order to run this compiled code. This JVM is differnt for every platform. Thus, dependency comes into effect only for end-user.
Javac – compiler that converts source code to byte code.
JVM- interpreter that converts byte code to machine language code.
As we know java is both compile**r & **interpreter based language. Once the java code also known as source code is compiled, it gets converted to native code known as BYTE CODE which is portable & can be easily executed on all operating systems. Byte code generated is basically represented in hexa decimal format. This format is same on every platform be it Solaris work station or Macintosh, windows or Linux. After compilation, the interpreter reads the generated byte code & translates it according to the host machine. . Byte code is interpreted by Java Virtual Machine which is available with all the operating systems we install. so to port Java programs to a new platform all that is required is to port the interpreter and some of the library routines.
Hope it helps!!!
When we compile C source data, it generate native code which can be understood by current operating system.
When we move this source code to the other operating system, it can't be understood by operating system because of native code that means representation is change from O.S to O.S.
So C or C++ are platform dependent .
Now in case of java, after compilation we get byte code instead of native code. When we will run the byte code,
it is converted into native code with the help of JVM and then it will be executed.
So Java is platform independent and C or C++ is not platform independent.
well good question but when the source code is changed into intermediate native byte code by a compiler in which it converts the program into the byte code by giving the errors after the whole checking at once (if found) and then the program needs a interpreter which would check the program line by line and directly change it into machine code or object code and each operating system by default cannot have an java interpreter because of some security reasons so you need to have jvm at any cost to run it in that different O.S platform independence as you said here means that the program can be run in any os like unix, mac, linux, windows, etc but this does not mean that each and every os will be able to run the codes without a jvm which saysspecification, implementation, and instance , if i advance then by changing the configuration of your pc so that you can have a class loader that can open even the byte code then also you can execute java byte code, applets, etc.
-by nimish :) best of luck
{App1(Java code)------>App1byteCode}........{(JVM+MacOS) help work
with App1,App2,App3}
{App2(Java Code)----->App2byteCode}........{(JVM+LinuxOS) help work
with App1,App2,App3}
{App3(Java Code)----->App3byteCode}........{(JVM+WindowsOS) help work
with App1,App2,App3}
How this is happening ?
Ans: JVM have capability to read ByteCode and Response In Accordance with the underlying OS As the JVM is in Sync with OS.
So we find, we need JVM with Sync with Platform.
But the main thing is that the programmer dont have to know specific knowledge of the Platform and program his application keeping one specific platform in mind.
This Flexibility of write Program in Java --- compile to ByteCode and run on any Machine (Yes need to have Platform DEPENDENT JVM to execute it) makes Java Platform Independent.
when we compile java file the .class file of that program is generated that .class file contain the byte code.That byte code is platform independent,byte code can run on any operating system using java virtual machine. platform independence not about only operating system it also about the hardware.
When you run you java application on a 16-bit machine that you made on 32-bit, you do not have to worry about converting the data types according to the target system. You can run your app on any architecture and you will get the same result in each.
Edit: Not quite. See comments below.
Java doesn't directly run on anything. It needs to be converted to bytecode by a JVM.
Because JVMs exist for all major platforms, this makes Java platform-independent THROUGH the JVM.