Binary Portability With Tweaking Discussion
- You said "...there is some tweaking to be done". I rest my case...
- Surely, you can't be serious. If I have to a bit of tweaking to get a binary that runs on Linux, Windows, AIX, and Solaris then this means that my binary is not truly running on Linux, Windows, AIX, and Solaris?!?
- No, your binary is running on them -- but 'write once run anywhere' really meant 'write once, test everywhere, tweak and repeat
- So? At least its possible. What's your point, that it was a drag that you actually had to test the systems your were going to deploy your binary on? You'd be foolish not to do that regardless. -- rad
- No, it's a drag that the so-called 'binary portability' provided by the virtual machine didn't accomplish anything more than pure source portability would have provided, other than a larger set of standard libraries. It would be folly not to test everywhere, but Java didn't save any (serious) work... Other people provide cross platform standard libraries. If one has to "tweak" the source to make the binary run everywhere, one might as well have used C++ -- it's available on more platforms anyway. True 'binary portability' wouldn't require source tweaks.
- If you don't see a difference between that and porting source I don't know how we can even have a discussion. How could one use C++ to create mobile client-side application in a heterogeneous distributed system? There is a huge difference between a few minor tweaks to get a binary that runs on many platforms and C++ source which requires a lot of work just to recompile, and then must be recompiled for each platform and even then cannot be dynamically deployed. What is it about this concept that is so hard to grasp?
The really disturbing answer would be "compile servers", but that's just sick. :-) An alternative answer would be squirting python around -- but that's not using C++. C++ doesn't always require a lot of work to recompile, either -- it depends upon how it is written. Java *almost* lives up to its promises, and that's the frustrating thing. We *want* to be able to use Java, but it's *just not portable enough*. There are at least three voices in this discussion, and at least two of them weren't talking about distributed heterogenerous environments, just shipping the program to somebody and expecting it to work. How can one test everywhere if you don't have *every* configuration? The JVM *should* have been the answer to this problem. Anything less is just "good binary portability", not "binary portability". Sigh.
- Vendors accomplish Portability A by supplying multiple binaries on the same CD.
- So, exactly how does this work with a distributed or parallel system?
"Close" only counts in horseshoes, hand grenades, and atom bombs. Not in software.
Aren't we being a little bit too precise and philosophical here? Close matters a great deal in porting software. You will port to operating systems close to your baseline and not to ones which differ greatly. The bottom line is the cost to do the port versus the benefit.
Yeah, it would be nice if the cost could be zero, but I can't even get that with different versions of the same operating system or JVM.
Finally, how does Java byte code qulaify as binary? It's really non-ASCII source which is compiled on the target, not that much different than BASIC.
This still sounds a little too philosophical to me. If your point is that there is no complex code which can be run as is on everything from a Commodore to a Cray, point conceded. Now, does your cost of development go up as you increase the range of targeted operating systems and versions? Yes, but the key question is whether the cost slopes upward, but how steeply it slopes upward. It is kind of self defeating to argue that "I want software to run on platforms with a wide variation of characteristics, but I don't want the platforms to exhibit any variation in characteristics." Remember the key issue is what is the cost of extending software to run on another platform versus what is the benefit received from running the software on said platform. The format and packaging of the software is really immaterial. --WayneMack
I think I see the misunderstanding: "tweaking" Java code doesn't mean writing an ifdef or separate classes to swap in depending on platform. Instead I might rewrite a method to avoid a non-portable construct, and put in a comment explaining what bug it's working around. Worst case, I might need an if statement to test which platform the program is running on and call the correct code at runtime. In any case, I still have one source tree and one binary, no branch in source control, and only one release to download. It's up to you to decide how significant this is, but I do think it's quite convenient.