When I used C++ programs, I needed Turbo C complier; and when I have a Java program, I need to have JVM. Still C++ isn't platform independent, but Java is!
If any Java program require a JVM running in order to execute, why does Java is said to be Platform Independent?
Java is operating-system independent because it runs on the Java platform (the JVM): The mantra is "write once, run anywhere" because you write your code using the JDK API, compile that once, and it runs on any operating system that has a JVM available. You write your code, wrap it up in a jar, and that jar runs wherever you want to use it, within reasonable bounds. The job of the JDK and JVM are to abstract away the differences in environments.
In contrast, particularly back when Java was created, writing C or C++ for multiple operating systems was a big pain and usually required additional toolkits (of course, the JDK and JVM are a toolkit of sorts), and even today still requires at least recompiling for the target system.
There's nothing magic about Java's OS-independence. It would be entirely possible to build the same thing for C or C++: Compile to an intermediary form, provide a runtime that knows how to interpret or recompile that intermediary form for different environments and provide a library that abstracts away environmental differences. Java just...did that, with its own spin on the language. Later, so did the .Net platform.
No software is really "independent". Eventually, your program has to call the underlying OS in order to make some basic operations, like allocating memory, create new threads etc.
The way to achieve an executable which is "cross platform" is to create specific executable for each OS. Common practice is to write different code for each OS, and then "hide" it in a cross platform interface and compile the relevant code to the relevant OS. For example, std::thread is "cross-platform" to the user who uses this class, but behind the scenes it will call different functions based on the OS which was specified on compile time (such as CreateThread on Windows, but pthread_create on *nix OS's).
So basically, the JVM is a C/C++ executable that was written with different set of functions for each OS, and was compiled separately for each OS. A JVM executable which works on Linux, will not work on Windows, and vice-versa.
That JVM compiles .class files to machine code based on the OS and CPU it currently operating on, so that's why Java programs can "run anywhere".
But basically, it's a lie. It's like saying a human being can live on Mars....
if he lives inside a sealed spaceship with proper temperature, water, food, air and sunlight supply
So Java program can run anywhere.... if the JVM already is installed and running on the computer.
Firstly, I'd like to link to this question which has a lot of good information.
https://softwareengineering.stackexchange.com/questions/85175/what-is-the-exact-meaning-of-platform-independence
In the question above are comments about what it means to be "Platform independent," but the one thing I wanted to mention, but is summed up nicely here is
You're right, platform independence means that the same program works on any platform (operating system) without needing any modification.
The code we write is known as "Write once, run anywhere" or as someone else said "run once, test everywhere."
Our Java code SHOULD run everywhere, but sometimes there are little native bugs that cause issues i.e., someone was having issues with printing on Mac OSX with JavaFX-8 Printing, while it works fine on Windows. There was also a bug report on this to fix this "Mac specific Java issue."
So.... For the most part, the underlying JavaSE code SHOULD work across all platforms.....
** however, if you do have an Application running on multiple computers and work with the File System, you will have to do checks to understand which OS you are working with i.e., (System.getProperty("os.name").contains("Windows")); **
more info on that here https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html
There is also another thing to note.
Certain components do not work cross platform, i.e., JavaSE vs JavaEE. JSP/JSF is what is used in JavaEE, on the web, that is specific for running code on a server, and in a webpage, but cannot be used in the Desktop (to my knowledge).
However, JavaSE has GUIs such as Swing, and JavaFX, which also cannot work on the web, either in the Client, or in the Server.
Android has it's own set of commands and things it can/cannot do, and other "Platforms" have specifics to it as well.
Overall, the underlying Java Architecture is what is used across all platforms, where certain "Java Specifics" are used in certain platforms i.e., JSP.
So what does Java do differently?
In the case of Java the application runs in a Java Virtual Machine which itself isn't platform independent. This has to be the interface between the actual machine (operating system) and the Java code you've written.
I am not really knowledgeable that much of the JVM, but it seems that each JVM is specifically tailored to each "Platform" (Which is why there are soo many versions to install), and does a lot of heavy lifting in the background, whereas C you might have to do this all yourself (not really sure how it works), for each OS.
Want a JVM for Windows? Np... Linux? Np.... That new car you just bought with all that fancy tech in it? JVM for that.... Or how about that new parking meter where you just parked your car? Yeah, there's one for that too...
For example, here is an Answer from this site on how Java is converted to Dalvik for Android.
https://stackoverflow.com/a/24570735/3599960
Hope this helps and makes sense.
C or C++ program gets compiled into native-code which is close to the metal where metal is the OS (earlier it could be hardware also in DOS era). There is no further re-compilation necessary to run the executable on target platform. But, a developer must build executables for all platforms he/she indents the program should run on.
It doesn't just mean different OSes, but bit-ness of particular OS. For example a 64-bit binary (EXE) cannot run on a 32-bit OS (vice-versa is possible, mostly, however). Here Java/.NET and other platform virtualization engine are boon for the developers - they just build once (for example "AnyCPU" for C# module), and don't need to give multiple binaries (EXE files). The runtime installed on given OS would re-compiler (JIT - Just In Time compilation).
I'm not sure about Java, but a.NET program can be compiled into specific platform. It is also possible by the .NET engine to JIT compile the intermediate (or byte-code in Java) into native format just once (and keep the EXE for direct run). The advantage is that .NET JIT compiler can take advantage of current hardware and latest CPU instructions, which C++ program cannot (it won't have JIT/re-compilation).
I'm planning to update the JRE to the latest version for Java application on windows. The application runs on windows 7 and JRE 7u17.
While I updated it without any issues. I just have these two questions:
Are there risks I should consider while upgrading? Is there a better way to test if the application still runs the same as on JRE7.
Thanks in advance,
Best
There are no risk but there are things to take care of while upgrading from 7 -> 8
In my personal experience I found following things
In my personal experience I had to update all the frameworks which deal with class level operations (spring, tapestry-plastic, etc.. ) and some of them had API changes as well making a huge change in code base
apart from language side there are some changes in VM too, for example: metaspace is introduced and no more permgen space, some stuff from permgen moved to heap, so you might have to re-tune your JVM, there are other things in new JVM you could take advantage of as well
It seems to be a simple question, but I wasn't able to find a meaningful answer, only a lot of speculations.
Also, if an answer is yes, which JVM would it be, Oracle's or again something patched by Microsoft?
Specifically: I have a Java desktop application, running on JRE 7, would it run on WinRT?
I mean, can I install JRE 7 on WinRT? Would it run without problems?
Yes and no.
It would certainly be possible to implement a Java Virtual Machine, or at least a substantial portion of one, using the Windows Runtime APIs and the portions of the Windows API that are usable from a Windows Store app. However, such a JVM would need to be an interpreting JVM, not a JIT compiling JVM. JIT compilation requires the ability to change memory protection (to allow execution of generated code), but the APIs to change memory protection (VirtualProtect and friends) are not callable from user code in a Windows Store app.
So, could you implement an interpreting JVM usable in a Windows Store app? Probably. Whether or not it would be possible to implement a JVM that performs well enough to be usable is another matter altogether, though.
I was wondering if anyone have gotten Java up and running on a BeagleBoard or Cubox? I'm thinking about buying one for a project I'm working on on my spare time, but as parts of this project is written in Java I first wanted to know if these tiny computers can run a JVM at all?
From what I read on http://www.oracle.com/technetwork/java/embedded/downloads/javase/index.html there are editions for ARM, and Solid-Run (the manufacturer behind Cubox) have also written some info on their wiki: http://www.solid-run.com/mw/index.php/Oracle_Java_on_CuBox.
However, what I would need to know is:
Can I consider ARM JVM == x86/x64 JVM in terms of functionality (a.k.a. "will my code run without changes") (my code is pretty non-graphical, mainly a HTTP API)?
Are there any license "problems" with JVM on ARM (compared to JVM on x86/x64)? That is, if I suddenly want to mass-produce my little spare-time hobby project and sell Cuboxes, will Oracle sue me?
Anyone have any experience with Hibernate/HSQLDB on ARM?
Perhaps too many questions in one, but I think they're all related enough to be put in the same thread. In general, I want to know more about JVM on ARM and how developed and mature it is.
Thanks!
Answers to 1 and 2 are on the Oracle page. "development is free, but royalties are required upon deployment on anything other than general purpose systems. In all cases, these products are fully Java SE compliant"
As for 3, I don't know about Hibernate (which shouldn't be a problem), but HSQLDB has been used on ARM by Symbian and others at least since 5 years ago.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Need guidance on alternative JVMs for Apple OS X
So that's it, Apple may not be producing a JVM themselves nor shipping it with OS X anymore:
http://www.infoq.com/news/2010/10/apple-deprecates-java
We've got a huge Java application running on Windows, Linux and OS X (and OS X is a big part of our [rich] userbase), what will, as developers, our options be?
Will it be realistic to run our app on another OS X JVM (an Oracle one)?
Or is a move away from Java to be considered? If so, what would that technically mean? Try to use some automated porting tool (not unlike Excelsior Jet for Windows, is there anything similar for OS X?)? Rewrite our entire app (which would be huge) to Objective-C and maintain two different versions? (a Java one and an Objective-C one?).
We may decide to drop OS X support altogether too, at least as long as Microsoft or Oracle do not kill Java on Windows.
Will it be realistic to run our app on another OS X JVM (an Oracle one)?
That depends on how GUI intensive your application is, and how much you / your users care about having a fast GUI and the Mac "user experience" for the Mac version of your app.
But yes, it could be totally realistic. Wait and see what Oracle does, and in the meantime, try out Soy Latte.
Or is a move away from Java to be considered?
Depends how much effort you have to burn. And how much effort you can justify for supporting Mac users. No matter how you do it, you'll end up having to support two codebases.
We may decide to drop OS X support altogether too ...
That's realistic.
... at least as long as Microsoft or Oracle do not kill Java on Windows.
That's ridiculous FUD-mongering!
Microsoft can't do it, because they have no control of the Java codebase. (If they tried to do it by backdoor means, they'd be up against the wall for anti-trust violations ... all over the world.)
Oracle would be insane to try to do it for many reasons. Besides, they can't (in theory) because the OpenJDK for Windows codebase is open source and there other existing high quality Java implementations for Windows (e.g. IBM's).
But since we're into FUD-mongering, a more likely scenario (compared to "the end of the world" for Java on Windows) is:
Oracle does a deal with Apple to take over Apple's rights to the Java-on-Mac codebase.
Oracle "monetizes their investment" by selling Java-on-Mac licenses to developers or end-user.
That would certainly be "in character" for Oracle, and they'd be within their rights to do this. It wouldn't make them popular with the open-source community, but the signs are that they don't really care about that.
This strongly depends if Apple will make it an optional download (like Rosetta) or completely leave it.
If it is an optional download, you are in the same situation as under Windows.
If abandoned, then you must consider if OS X is a supported platform anymore.
You may in any case strongly consider supporting the OpenJDK project which currently is the best bet for filling the void Apple is creating here.