What differs between "writing a specific JRE for each platform" for Java developers and "writing a C++ compiler for each platform" for C++ ones?
0
Comments disabled on deleted / locked posts / reviews
|
12 Answers
Java is compile once run anywhere. C++ is write once compile anywhere.
-
3Well you've obviously not had much experience with GUI development. (Waiting for Qt...)– user7007Sep 27, 2011 at 15:58
-
27Anyone who claims that C++ is "write once compile anywhere" has never had to port a C++ program... Sep 27, 2011 at 18:03
-
7I agree with BlueRaja. Porting a C++ program means so much more than porting the compiler. C++ is most widely present in critical environments where things like the size of an int or the implementation of a file system can make such a big difference. Porting does NOT simply mean recompiling.– rahmuSep 27, 2011 at 18:20
-
8@Pubby8 no, portability issues also come from pretty standard code that makes nonportable assumptions, like assumptions about endianness (which mind you, you can also suffer from in Java), alignment, and sizeof fundamental types. Sep 27, 2011 at 21:20
-
5
"writing a specific JRE for each platform" is not something you do everytime. Porting the JRE to a new platform is something you need doing only once. This task is generally done by the core maintainer/developers of the program and/or the platform. A lot of factors may come into play when deciding who and how the JRE would be ported. Among other things, it depends on the licensed it's published under (I hear Java is Open Source, so I guess anyone could do it). Funny anecdote, Steve Jobs made a big deal about not wanting to take care of the porting of Java on Mac, around a year ago.
The point is not how or who ports the JRE, but the fact that once it is ported, every Java application should now theoretically run easily on the new machine. In that sense, the JRE forms an abstraction layer, completely hiding the machine, allowing easy porting.
However, reality is not always pretty like this. I won't go as far as calling portability a "myth", but it's true that it's not so perfect. For instance, Java has a package called JNI that allows sending native calls, bypassing the JRE, thus preventing the perfect seamless portability, what Java fans like to call "Write once run everywhere".
As mentioned in the comments, C++'s approach to portability is different. On the one hand, it's a compiled language, and those binaries are almost always platform specific. So c++ executables will never be portable (unlike Java). On the other hand, porting the compiler can sometimes be enough. The community has found that by porting the compiler as well as some core libraries of the language, source codes (and not binaries) could be portable.
However, C++ is widely used in critical systems like compilers, kernels, real-time systems,embedded systems, ... There's a "low level" aspect of C++ that cannot be overlooked, when talking about portability.
-
4
-
"his is where Java is very different from C++, where each application is "machine-specific", and cannot be ported without modifying the code." That's not true, it depends on the dependencies. If you only use the standard library and libraries with sources portable to your targets, you code once and compile on each target. If you code something that can be ported without modifying the code in C++ then the only thing you might need to modify are the build scripts. That's not even true in all cases.– KlaimSep 27, 2011 at 20:13
-
Let's not forget that C++ can be used as both a high-level and a low level language. A lot of C++ code is used in programs where a 32bit int is very different from a 64-bit int. High-level will always be portable, of course. But it's far from a C++ generalization– rahmuSep 27, 2011 at 20:25
-
I think you might have misunderstood what I'm saying : you can write correct C++ with int or any standard type without bothering with low-level stuff. Just take a look at boost libraries, most are only high level code, and that's true for a lot of C++ open source project. You "can" go low level, and if you do you can also avoid any specific code until you need to use platform specific API. But if you don't need to, then you can write C++ that works everywhere. Dependency to platform can be avoided and often is in library code.– KlaimSep 27, 2011 at 22:03
-
Just to be sure I'm clear : I don't say that all C++ code is portable, I'm saying that as is, your statement is wrong. You might want to fix it with something like : "This is where Java is very different from C++, where each application is "machine-specific", and cannot be ported without modifying the code or, if the code really is portable and the build scripts manage the new target, without at least one compilation."– KlaimSep 27, 2011 at 22:08
It's not just the language -- it's the libraries.
Both Java and C++ provide cross-platform libraries. Java provides a richer set.
-
2Java provides a richer set by default. The same libraries can be found for C++ they are just not part of the standard libraries and you just have to decide which ones to use (which is not trivial especially if they are not installed). Sep 27, 2011 at 15:51
-
Comparing the standard libraries of Java to the universe of libraries for C++ is not really a valid comparison. Java provides a richer set, whether you're comparing the standard libraries of each, or you're comparing the universe of libraries of each. Sep 27, 2011 at 16:18
-
3Definitely disagree with that. Anything in the Java library is available is already available for use by C++ in some library. I like the fact that Java has it all in one place but to say it is richer is just not true. Maybe the adjective you are looking for is `more integrated' Sep 27, 2011 at 17:23
-
1+1 would upvote again. I think the libraries are the biggest factor in portability. If you're working in C/C++ and doing anything other than pure computation, there will be libraries (in particular, parts of the system library) that are radically different between Windows and Unix, and subtly different between different flavours of Unix. That makes porting hard. Java basically doesn't have that problem. Sep 27, 2011 at 17:33
-
1@Andy Thomas-Cramer: I am not comparing anything (you seem to be). I am saying your statement is inaccurate. One of the advantages Java has (and we all love it for that) is all the standard libraries in one place. Saying they are richer is just not accurate. Sep 27, 2011 at 20:00
The difference is that Java will run on any platform without recompiling. Having a C++ compiler for each platform isn't the same at all.
answered Sep 27, 2011 at 15:42
All the answers starting with "The difference is...", or anything very similar, are basically wrong (sorry, but such is life). There are really two separate differences between the two.
One (that's been mentioned a lot) is that a compiled Java program can (or least should) run on any conforming implementation of Java, so even after being compiled, you can still move a Java program from one platform to another without re-compiling. C++ (at least normally) requires re-compilation for each target platform.
The other is that Java (at least attempts to) assure that all correctly written Java will be portable. At least in theory, you shouldn't be able to write any code that isn't portable.
C++ allows you to do quite a few things that aren't portable. The C++ standard contains "warnings" about a lot of things that aren't portable (e.g., telling you that you'll get implementation defined behavior or undefined behavior), but it doesn't necessarily try to stop you from doing them at all. Just for example, if you want to write an operating system for hardware that uses a PCI bus, you're probably going to need to read/write the PCI configuration memory. This obviously won't be portable to systems without a PCI bus, but if you're writing an operating system for hardware with a PCI bus, it's pretty much necessary. C++ allows it even though it obviously won't be portable.
answered Sep 27, 2011 at 16:51
-
-
of course it doesn't, those are platform specific things that will have to be included in platform specific libraries. Just as Java can have platform specific libraries if needed.– jwentingSep 28, 2011 at 8:05
-
1@Nikko: It knows nothing anything about it, but it allows you to use what you know about it. Sep 28, 2011 at 13:04
-
@jwenting: The difference being that you can write the platform-specific libraries in C++, but you generally can't write them in Java. Sep 28, 2011 at 13:05
You have misunderstood the premises. Java programs are very portable, because the JVM provides a standard behaviour guaranteed to be the same. C++ programs have a less standardized environment closer to the actual hardware, so the program needs to be able to handle the various platform specific details - like size of an int, word alignment etc etc etc.
The JVM itself is not very portable. It is a herculean task to port a high-performant JVM to another platform or CPU architecture.
The difference is that Java (it's not an acronym) programs can be distributed in a form that can be run on any computer with a JVM installed, but C++ is normally distributed as either source code, which is very user unfriendly, or as a bunch of different binaries for different platforms.
-
Huh? There are C++ compilers which target the JVM and there are Java compilers which target native code. Can you cite the specific section of the C++ language specification which says that C++ programs must be distributed as either source code or platform-specific binaries? Sep 28, 2011 at 0:37
-
One of the reasons Java is considered portable is that it has specific rules for how arithmetic expressions must be valuated and forbids implementations from evaluating them any other way, even when evaluating them in the mandated fashion would require slower code than evaluating them in a more accurate fashion.
For example, given
long thing1(int x) {
return (x+1)-1L;
}
double thing2(int x, float y) {
return x/y;
}
The values of thing1(2147483647) and thing2(1123456700,11234567.0f) are required to be -2147483649L and 99.9999923706054688, respectively, even though the arithmetically correct values would be 2147483647L and 100.0, and even though on some platforms code to generate the numerically-incorrect results would be slower than code to generate the correct results (on some 64-bit platforms, forcing the wrapping behavior after (x+1) would require an extra instruction, and on the 8x87 platform, forcing the value of 1123456700 to be rounded to a float would require an extra instruction compared with simply loading it directly to an extended-precision register).
-
1For once a new answer on an old question that actually adds something of value: Java has very precise arithmetic requirements, and of course the primitive data types have specific sizes and semantics compared to C++. No other answer as of this date mentions this.– user22815Nov 7, 2014 at 16:32
-
@Snowman: How do you like the particular examples chosen? Personally if I were designing a language I would not have made the either example return Java's value without the use of narrowing casts to
(int)for the first example's(x+1)subexpression in the first example, tofloatthe second example'sxparameter, but obviously I didn't design the language.– supercatNov 8, 2014 at 12:39 -
I think they make sense. The important thing for any language is to have well-defined semantics. Regardless of whether one agrees with a given language design decision, the important thing is being able to look at the code and know how it works. Java generally does that, with few cases of undefined behavior.– user22815Nov 9, 2014 at 20:11
The amount of work for the supporting tools is indeed similar, the difference lies elsewhere. Once a C++ program has been compiled for a platform, you have to compile it again if you want to use it on a different platform. However, when a java program has been compiled, you can move it to any other platform with a runtime environment without having to recompile it.
Answering the title "Is portability a myth ?", instead of "Which is better at portability, Java or C++", I'll say that partial portability is possible, but full portability it's does a myth.
Something that I insist to write, and it applies to this question, is that developers are not longer working with just programming languages, but, with full programming frameworks.
And those frameworks, include libraries, databases, graphical interfaces.
Which programming language, or which programming framework is more portable ?
Well, it depends, on what your app. is trying to achieve.
The thing is "you" don't write the JRE you write the Java code which runs on any JRE. "You" do write the C++ code which can require changes by you before it will compile on another platform.
answered Sep 28, 2011 at 1:33
Many people forget or do not take into account the reality of Java when they say that "it's 100% portable" or phrases like that .
Pretty much all the major Corporations / Software house had at least 1 home-made implementation of Java with an associated JRE in the recent past and some still do maintain it, Microsoft, IBM and Apple for example all had their own version of Java reflecting their own ideas and thoughts on where the industry and such language should go .
How is that for "portable" ? A JRE anywhere you turn .
And this is without considering what Sun/Oracle was doing.
An example on why Java code is not really far from C and C++ in terms of portability are the GUIs and the graphical servers, Apple had a non-standard implementation of the GUI framework for its own JRE, as a consequence there were a lot of headaches and double work for anyone who wanted to create/port a GUI using Java for Apple machines and they were basically forced to deal with Quartz ( how is that in terms of "leverage" and high level languages ?).
Sometimes even the most common used words don't really reflect the meaning that people usually give them, to me the term "portability" in the Java world is more like "outlook" in the common sense; in commercial and financial terms there is a better outlook for you if you adopt Java rather than other languages ( at least at the time when Java was born ) because you have a lot of work already done on one side ( you get a JRE on anything that can be considered a "computer" ) and your codebase is likely to be portable as it is, you need less resources to port your program, that's it, whether said resource is money, time or manpower doesn't matter, it's a lower threshold compared to other technologies and that's what Java is for, it is lowering that threshold .
Of course this is true if you accept the premises of Java, which means a virtual machine with garbage collection, which means it consumes more resources if compared to native languages, if you really want to squeeze the maximum out of your CPU or server farm I don't think that you can adopt Java unless you are really low on resources or your company is really small .
I still have to find a single non-trivial Java application that contains only 1 version for each line of code or functionality ( aka without any platform specific stuff ) and it's 100% portable among all the major JREs.
