Look at NetBSD.

Actually, I think that Java and C are equally portable. For most user applications, you rely heavily on libraries to provide support. But as you get deeper into the libraries themselves, you get closer to the OS. In both languages, these differences in the OS need to be smoothed over by whatever implementation you're using (Linux-i386, Win32, etc). No matter whether this smoothing-over takes place in a virtual machine or in the library itself, it still needs to be done. So it's really a matter of whose responsibility it is to ensure portability - the library itself or the virtual machine. Right?

The Java trap, as elucidated by Richard Stallman. A worthy point to make, and thankfully there are other decent Java implementations out there now that are open source. My favorite is Jikes / Kaffe, which I've been using for a few months now and with which I'm very happy. Kaffe can even run Eclipse, albeit very slowly.

Well, outside of libraries, automatic memory management, true generic programming, multiple inheritance, builtin pre-processing, etc etc.

But hey, we're talking about different languages, here! No one is better than the other, they're just different. Now, we could argue about which is better in a specific domain (like portability), but even that is fraught with nuances, caveats, and subjectivity.

If you want my then I like C and C++ better than Java. I feel like Java, the language itself, makes some things too hard or even impossible; I feel like Java wants me to do it a specific way, and I don't like that. Flexibility, in other words, is why I like C and C++ better than Java. Now, that said, it sure would rule to have some of those Java libraries available in C++, just with the C++ language running underneath them.

I strongly disagree.

Programs written in C can only be portable if the programmer is very careful, and the fact is almost none is.

Consequently, porting from one platform to another, even from one linux distro to another, need often some work. Not to mention source code can rely to specific extensions from one C compiler unavailable to the target compiler.

On the other hand, programs written in pure Java, i.e. not relying on unbundled native libraries like SWT, are 99.9% portable to their target JVM version.

Another portability difference, C code need to be distributed in source form and recompiled on the target system, or binaries need to be built and tested for each target.

Java classes need not, being independant of the O/S and the hardware thanks to the JVM, thus Java application distribution is far easier.

That's alright. I shall now, with all due respect, attempt to address your comments. And I mean no offense here, because I know languages are a touchy subject for many, myself included.

Yeah, but is that really a problem with the language? Or does the fault lie with those who improperly use it? I wouldn't say that pointers are evil because they can cause problems when not used properly. Instead, I'd say that ignorant programmers are evil when they incorrectly use pointers.

That's true; the same can be said of Java virtual machines, though. For example, I don't believe that "generics" are supported in Kaffe. And some of the libraries found in the Sun classpath are not yet fully available in the GNU classpath.

Yes, but note that you rely upon the JVM. The Java virtual machine is operating system dependent, and must itself be ported across systems. Like I said above, it's not the portability itself that's different, but where the portability comes into play. (For C, it's in the libraries and some of the application code; for Java it's in the virtual machine.) Really the question is not "is it portable" but "who has to deal with portability". Both languages have the same portability issues, but different people are responsible in each language.

Here you are mostly right, depending on how portable something needs to be. Opera comes available for Linux, as a non-open source binary which contains raw executable code. It doesn't need to be compiled, but it does need certain libraries to run. In contrast, Java bytecodes are interpreted by the VM, giving an extra layer of abstraction which frees the programmer from a lot of portability headaches (and transfers them instead to the JVM writers). But because these bytecodes are generated from source, then interpreted to machine instructions, class files are half-way between source and instruction. The notion of "binary" versus "source" in this case is somewhat hazy. (Although, I concede that you're mostly right about this point. But open source is good, dammit! )

As I just had a good idea, I'm going to go on a little more.

Going back to my example: Opera has a binary for Linux. This relies on the local kernel and dynamic libraries to run -- this type of execution is directly analogous to how a Java class file needs a local JVM and classpath to run. In terms of portability, the JVM is like the kernel of an OS; they're dependent on what machine (or operating system) they're running under. Move up a level and you've got the classpath and the dynamic libraries. The dynamic libs are dependent on the kernel, and some members of the classpath (I believe) are dependent on certain features of the JVM. So in terms of the framework than an application runs on, they're very similar in design. And when you get to the bottom, you've got portability issues no matter which route you take. The thing is this: who has to worry about portability? Is it the application programmer? The person who wrote the libraries? Or is the hacker who worked on the virtual machine / kernel? For Java, it's almost all in the latter. For C, it's mostly in the latter, but somewhat in the former as well.

Alright, so you may take this to mean that Java is more portable than C. That's fine, but still, somewhere along the line, somebody has to think about portability issues. Java let's you get more portability out of your application code at the cost of speed when that interfacing to the OS is added by the JVM.

(Not that I'm trying to say Java is slow -- in most cases software is just as fast as it needs to be without a lot of tweaking. I love functional programming, for crying out loud, and I don't put as much stock into run-time efficiency as I do program design. )

Phew, OK. That's my <- lots of money. Good comments; thanks for putting up with my responses.

After hating Java from the beginning, I eventually came to realize it will be a life-long hatred

I do, and I write performance software- both software that measures the performance of systems and subsystems, and software that increases the performance of systems and subsystems- and Java has no place there. We process millions of transactions per day in critical environments where failures are very costly in real monetary terms. Since Java can't perform, and it can't be used to write systems software (at least not on any platform I've heard of) I have no use for it.

It's basically an overgrown scripting platform and as someone else said (I can't remember where) Java is the least portable of all languages. It runs on only one machine and that machine had to be ported to every other machine. It's funny, but if you think about it, quite true.

I'm sure for a GUI front-end it's an OK choice, but I think web scripts calling back ends in real programming languages are much better choices. I can't see any use for Java that something else doesn't do a better job at.

Broad platform compatibility is not really a sensible goal. If you're talking about x86 then sure, it's nice to write a GUI app and have it run on Linux, bloze, *BSD, etc. That might be reasonable with good coding techniques, good header files, and a cross platform X API.

But what about non-UNIX OS? It seems as though many people forget that most mission critical work is running on IBM large system hardware and software and this does not include Linux or UNIX (although those OS do run on IBM hardware).

It's easy to overlook the fact that most things are not needed to work truly cross platform. I don't want to run the same type of workload on my large IBM system as I do on my *BSD web server as I do on my Sparc workstation, as I do on my personal Linux workstation. Those boxes are all used for a lot of different types of workload and I really don't need anything to run on all of them, except maybe for some management app that provides a console, etc. There are too many other differences to make multi-platform compatability something that anyone needs.

Will your example compile and run on Cray? IBM mainframe? The world is a lot bigger (and older) than Linux.

I think saying that C has to be distributed in source and recompiled is certainly not true...it can be built on the target platform by the vendor and distributed in binary form. Ask me how I know this You're right, however, it must be built and tested for each target.

[Edit: you did say this! Bad day for me to give up coffee- my apologies! Now the rest of my post is suspect But this is really not a big deal. It's very common for software vendors to have a lot of hardware and software on site to do exactly this. In very rare cases where we don't have something installed locally we have agreements with other companies to let us use their systems remotely to test new or very old versions and combinations of hardware/OS, etc.]

But Java must be shipped in source, in an obfuscated form (like all other interpreted/scripting languages) and there are always people who can figure out how to write apps to extract the Java source. A prudent software vendor tests its apps on all potential targets to avoid surprises. Even if someone chooses not to do that, it doesn't mean that a Java app is guaranteed to run anywhere someone can find a JVM to run it on.

The most important thing about writing software that companies pay big money for is not how easy it is to distribute. That's an issue which is very far down the list of important things. The most important thing is that the product does what it is supposed to do, that it's robust and handles exceptional conditions well, that it performs within acceptable parameters at the job that it is expected to do, and that it is possible for the developers and tech support people to provide effective and correct service. After all that (and maybe a few more things) we begin to worry about how easy it is to distribute.

There is also the matter of how easy it is to provide fixes. In almost all cases, C and other higher level languages must be fixed by sending a source-level patch and then recompiling on site, or having the vendor rebuild the executable and sending that. Of course this is not a very big problem since we have ftp and sometimes we can even just attach something in an email. But in the old days, this was not possible. We had to invent other ways of providing fixes much more quickly. In this arena, assembler is the best choice (at least on IBM large systems) since we can (and do) send fixes in the form of utility control statements that can update the executable directly. We used to just fax those, and before fax existed we just explained what to do on the phone (yes really.) Before there were phones we didn't have any problems because computers weren't invented yet

No problem. Along with Java, I'm actually a strong C language supporter too ...

Yes, C doesn't requires the libraries used with it to be portable, Java does this with classes used.
For example, nothing prevents you to write a device driver in C (hopefully) but of course this driver will depend on hardware, a kernel interface and several other thing that will make it highly unportable. On the other hand, Java basically forbids you to write a device driver. The reason why I was disagreeing with your "Java and C" are equally portable.
I wasn't referring to programming mistakes, neither C nor Java prevent them.
I wrote "portable to their target JVM version". Hopefully, the language isn't locked, new features (here in 1.5) are allowed break downward compatibility.
Kaffe isn't just compliant with JVM 1.5 specs, nor even an earlier actually, Kaffe doesn't pretend to be Java but is currently an education/research project.
Same comment here, the GNU classpath isn't yet done. So it's not technically Java compliant.
That makes the portability to be very different,. With Java, the programmer hasn't portability as his concern. With C, it is an issue.
You are not talking about Java vs C, but C vs C here. The JVM being written in C, yes the JVM has to be written in portable C, just like standard and other C libraries need to.
Sure Open Source is good, and java has a point here, as its classes are closer to source code than elf binaries.
Nothing to add, I agree with you on these points.

Are you claiming Java is not used in these environments ? This is absolutely untrue.
Please clarify this "Java can't perform" statement.
This "least portable" conclusion is wrong, it is indeed true Java run only on one strongly specified virtual machine, but that makes it a very portable language on the opposite. The porting issue is simply removed as java code need not to be ported.
You seem to be missing what java enterprise edition is all about, and how widespread is its use in large companies.

haha that is so true, we used to do the ping of death in school, and leave it running in like half of the machines in the room

(In an attempt to create a proof so simple it obviously has no flaws, rather than my last attempt which was so complex it had no obvious flaws [except to jilliagre] )

I think the issue of portability boils down to this question: what do you need to do to get a program written on system X to run on system Y? Simple.

To run a C program, you need a kernel, some libraries, and a compiler. All systems have these available (barring weird examples like Lisp machines). What you need to do next is modify the source to remove code specific to system X and replace it with code for system Y. Then compile, link, execute. Done.

To run a Java program, you need a virtual machine. Sounds easy, except one thing. Certified Java VMs are only available for Solaris, Windows, Mac OS X, and Linux. You don't have to modify the source of the Java program, but if you've not got a JVM for your system, it doesn't matter.

What does it mean? Depends on your definition of portable: do you mean to almost any OS ever made? or do you mean to Solaris / Windows / Mac OS X / Linux?

Granted, modifying the system-dependent code of a C program might be almost as hard as writing a JVM for your OS of choice. But seriously, if you're a business that relies on an OS which isn't supported by a certified JVM implementation, you don't have much choice.

In most cases, a project written in Java is more portable within the target environment. But in some cases, Java simply isn't an option, and therefore C becomes the choice for portability. I think globally, over all cases, it balances out.

That is incorrect.

Certified JVMs exist too for AIX, HP/UX, z/OS, OS/400, OS/390, OpenVMS, tru64, FreeBSD, and certainly many more.

My Nokia cellphone is claiming to support Java, and I'm sure it doesn't run one of the O/Ses above. Okay, it is J2ME, but is anyway a certified JVM too.
J2ME certified implementations exist for a very large range of embedded/mobile devices, including Palm/OS, Windows CE and Mobile.

Okay, but tell me what O/S you are missing ?

You do not need to write the JVM, but just port it.
Correct, but that would mean you are in a niche business.

Java is only used as a front end- it's too slow and has too many other problems to be used elsewhere. Virtually every bank, insurance company, utility company, every large operation in the world uses IBM large systems hardware and either CICS and/or IMS and/or DB2 with COBOL and some assembler code for their core applications, and assembler is used in critical pieces. No performance sensitive software has been deployed in Java.

The IBM operating system (by this I mean Z/OS and previous incarnations) is very different from UNIX or anything else most people who don't have large systems experience are used to, because it's very closely coupled to the hardware. UNIX has been ported to tons of platforms- IBM none. If you notice, the way they got Z/OS to run on x86 was to port the hardware instead of the software because the whole OS is written entirely in PL/X (sort of an assembler on steroids) and assembler and all the header files and APIs are written in PL/X and assembler. You cannot do systems programming in IBM land with C and certainly not with Java, and you never will. There has been some systems software written in C for IBM systems but it has to be shielded with assembler wrappers. It's used (what little there is) for more algorithmic parts.

Since all of the OS and all of the teleprocessing and all of the data base support is in assembler, you can only measure it and tweak it from assembler.

I said it in my earlier post. I write both performance measurement software, and software which increases the performance of existing systems, and I write everything in assembler. Nobody who has any understanding at all about even the simplest concepts of interpreted vs. compiled languages vs. assembler could have any questions at all that in these absolute terms, Java cannot, and cannot ever be made, to perform. I can't imagine that any further clarification should be required.

That may be what Sun would like people to believe Java EE is about, but the simple fact is that Java is not, and never will be, deployed in performance critical environments. As I said, it's a second rate choice for a GUI front end, and that's about it.

I'm very familiar with data processing operations at the largest corporations in the world, since they are virtually all our customers. And what we sell them, and what they run, is all written in assembler and runs with their workload in the environments I mentioned above.

Hmm, I didn't know that. If that's true, then I guess I learned something today. Well, I suppose I'd better stick to discussions I actually know something about, then.

This is incorrect, Java is mostly used as middleware in large companies.
It's fast enough for them.
This is FUD.
Unix is competing with mainframes there.
The fact you haven't deployed performance sensitive s/w in Java doesn't means nobody does.
Correct.
That is exhibiting the good portability of C.
Actually, Unix was the first O/S designed with portability in mind. And the C language was created to support that vision.
Virtual Machine is not that bad ...
You neither do system programming with Unix in Java. Java doesn't pretend to support that.
Interesting.
Indeed, but what that has to do with the OP Java question, or Java vs C portability ?
Yes IBM mainframe architecture is extremely non portable, and considered to be archaic by many people. It mostly survives because:
- its huge legacy base,
- IBM pricey hardware allows it to still compete on performance,
- existing customers are locked in this architecture, trapped there due to its lack of portability.
I understand what you mean.
This is where you need to open your mind.

C has managed to replace assembly language in many areas, excluding some niches like the one you work. C can't be faster than assembly language but nobody cares when C is fast enough.
Java is replacing C (and other) languages is some areas, excluding O/S and low level drivers development. Java can often perform close to what C can offer but is usually slower. Java can't be faster than assembly language but nobody cares when Java is fast enough.

Well, IBM is supporting that too, being the number one vendor of Java EE with WebSphere.
You need to learn a lot there. This was true 10 years ago, but it is no more.
I don't know, what is that software your are selling ?

Anyway, the largest corporations in the world are certainly also virtually all Sun, Microsoft, Oracle and SAP customers, to name a few. Not to mention they all look at what linux can bring to them.

Being a market leader in some area doesn't mean you are the only piece of the puzzle that matter.
And Sun is selling them software written in C and Java, and Microsoft is selling them software written in whatever C/C++/C#/VB language they want, and Oracle, SAP sell them what they do too.

The fact is all the above companies are using more portable languages to develop their software than you do.

If your point is you can't beat Assembly Language in term of pure performance, then I agree with you, but this is at the expense of portability, ease of development, ease of debugging, library availability and skilled programmers availability.

wow this has evolved into quite an interesting read since my last visit.. (thats about 74% sarcasm, sorry)

not trying to jump into the middle of the discussion here, but its starting to sound a little ridiculous, so i cant resist adding a thought or two.

the first thing that i see is that the discussion is going away from Java and portability and heading towards Java and performance (like it always does). jlliagre, while i disagree with some of you earlier thoughts on making c portable, i completely agree with your statement

that is right on imo.. Randux, the fact is that no one is out there (or in here for that matter) is claiming that Java is outperforming well written c or assembly, and no one is claiming that Java is a systems programming language. so using these things to disprove the usefulness of java seems a little ridiculous to me. thats like saying my car is a piece of sh!t because it cant fly, well its not supposed to fly, because its a car. thats the same with Java, its not supposed to do multimedia encoding, or be used to write an operating system, or be used where execution speed it critical. everyone knows this.

the reason that Java *IS* so popular in business is because every single app out there does not need to run in the fewest cycles possible, assuming that they do is completely and utterly wrong. many times the speed that an application runs is far outweighed by the speed that it is developed at. java writes faster than c and c++, and it is cheaper to pay a java programmer than a c programmer. so you end up with a cheaper product that goes out the door faster, and when running you (as a human, not a benchmarking program) see no difference in speed. *and* (to get back to one of the original points), with no extra effort the java code *should* be portable to all popular operating systems. with c code you could make it portable, but it would require more work than the java code would.

it depends on what you are measuring performance for. if you are saying that it will never outperform assembly, or will never outperform c, you may be right on. it is running in a VM. but if you are saying that it will never perform well enough to steal away a large share of new development projects from compiled languages. then i think you are already wrong, and will continue to get wronger.