LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 09-25-2006, 09:01 AM   #16
taylor_venable
Member
 
Registered: Jun 2005
Location: Indiana, USA
Distribution: OpenBSD, Ubuntu
Posts: 892

Rep: Reputation: 43

Quote:
Originally Posted by slantoflight
And I supposed I don't even need to mention Linux, which outside ASM bootstraps is written completely in C and portable to many different archictectures. However if you need some commercials examples look no further than apple. They've just ported their operating system to a different CPU.
Look at NetBSD.

Quote:
Originally Posted by slantoflight
C is very portable. In fact its even more portable than Java. Which only has support for a relatively small number of platforms. Compared to C anyways.
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?

Quote:
Originally Posted by slantoflight
Plus you're relying on proprietary implementation. It might be a very a good implementation. But nothing is flawless.
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.

Quote:
Originally Posted by slantoflight
Even as a language, I find java is too remeniscient of C++. Outside of the convenient libraries, and memory management, I might as well be using c++.
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.

Last edited by taylor_venable; 09-25-2006 at 09:02 AM. Reason: who's -> whose
 
Old 09-25-2006, 11:08 AM   #17
jlliagre
Moderator
 
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris 11.4, Oracle Linux, Mint, Ubuntu/WSL
Posts: 9,783

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
Quote:
Originally Posted by taylor_venable
Actually, I think that Java and C are equally portable.
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.
 
Old 09-25-2006, 12:21 PM   #18
taylor_venable
Member
 
Registered: Jun 2005
Location: Indiana, USA
Distribution: OpenBSD, Ubuntu
Posts: 892

Rep: Reputation: 43
Quote:
Originally Posted by jlliagre
I strongly disagree.
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.

Quote:
Originally Posted by jlliagre
Programs written in C can only be portable if the programmer is very careful, and the fact is almost none is.
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.

Quote:
Originally Posted by jlliagre
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.
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.

Quote:
Originally Posted by jlliagre
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.
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.

Quote:
Originally Posted by jlliagre
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.
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.
 
Old 09-25-2006, 12:40 PM   #19
Randux
Senior Member
 
Registered: Feb 2006
Location: Siberia
Distribution: Slackware & Slamd64. What else is there?
Posts: 1,705

Rep: Reputation: 54
Quote:
Originally Posted by taylor_venable
After a couple years of hating Java, I eventually came to realise that it has its place.
After hating Java from the beginning, I eventually came to realize it will be a life-long hatred

Quote:
Originally Posted by taylor_venable
Sure, I don't care for it, but I also don't do a lot of stuff that Java is usually used for (the so-called "enterprise" applications, huge services connecting hundreds of users, etc).
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.
 
Old 09-25-2006, 12:47 PM   #20
Randux
Senior Member
 
Registered: Feb 2006
Location: Siberia
Distribution: Slackware & Slamd64. What else is there?
Posts: 1,705

Rep: Reputation: 54
Cool

Quote:
Originally Posted by halfpower
Exactly what type of programs would need to be run on any platform? I have a C++ book within arms reach and all the code in it will compile on just about any platform. Wouldn't that essentially make C++ platform independent as well? I can't code a GUI, but most algorithms will run okay.
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.
 
Old 09-25-2006, 12:57 PM   #21
Randux
Senior Member
 
Registered: Feb 2006
Location: Siberia
Distribution: Slackware & Slamd64. What else is there?
Posts: 1,705

Rep: Reputation: 54
Quote:
Originally Posted by jlliagre
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.
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

Last edited by Randux; 09-25-2006 at 01:48 PM.
 
Old 09-25-2006, 03:36 PM   #22
jlliagre
Moderator
 
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris 11.4, Oracle Linux, Mint, Ubuntu/WSL
Posts: 9,783

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
Quote:
Originally Posted by taylor_venable
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.
No problem. Along with Java, I'm actually a strong C language supporter too ...

Quote:
Yeah, but is that really a problem with the language?
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.
Quote:
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.
I wasn't referring to programming mistakes, neither C nor Java prevent them.
Quote:
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.
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.
Quote:
And some of the libraries found in the Sun classpath are not yet fully available in the GNU classpath.
Same comment here, the GNU classpath isn't yet done. So it's not technically Java compliant.
Quote:
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.
That makes the portability to be very different,. With Java, the programmer hasn't portability as his concern. With C, it is an issue.
Quote:
(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.
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.
Quote:
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! )
Sure Open Source is good, and java has a point here, as its classes are closer to source code than elf binaries.
Quote:
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. )
Nothing to add, I agree with you on these points.
 
Old 09-25-2006, 05:57 PM   #23
jlliagre
Moderator
 
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris 11.4, Oracle Linux, Mint, Ubuntu/WSL
Posts: 9,783

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
Quote:
Originally Posted by Randux
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.
Are you claiming Java is not used in these environments ? This is absolutely untrue.
Quote:
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.
Please clarify this "Java can't perform" statement.
Quote:
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.
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.
Quote:
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.
You seem to be missing what java enterprise edition is all about, and how widespread is its use in large companies.
 
Old 09-25-2006, 07:31 PM   #24
k1ll3r_x
Member
 
Registered: Sep 2004
Location: Laredo, TX
Distribution: Debian 11
Posts: 164

Rep: Reputation: 30
Quote:
Originally Posted by bigearsbilly
mainly for filling up RAM

java.lang.HowMuchMoreBloodyMemoryMustiPurchaseException
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
 
Old 09-25-2006, 09:18 PM   #25
taylor_venable
Member
 
Registered: Jun 2005
Location: Indiana, USA
Distribution: OpenBSD, Ubuntu
Posts: 892

Rep: Reputation: 43
(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.

Last edited by taylor_venable; 09-25-2006 at 09:20 PM. Reason: Extraneous words eliminated.
 
Old 09-26-2006, 06:12 AM   #26
jlliagre
Moderator
 
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris 11.4, Oracle Linux, Mint, Ubuntu/WSL
Posts: 9,783

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
Quote:
Originally Posted by taylor_venable
Certified Java VMs are only available for Solaris, Windows, Mac OS X, and Linux.
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.

Quote:
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.
Okay, but tell me what O/S you are missing ?

Quote:
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.
You do not need to write the JVM, but just port it.
Quote:
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.
Correct, but that would mean you are in a niche business.
 
Old 09-26-2006, 07:46 AM   #27
Randux
Senior Member
 
Registered: Feb 2006
Location: Siberia
Distribution: Slackware & Slamd64. What else is there?
Posts: 1,705

Rep: Reputation: 54
Thumbs down

Quote:
Originally Posted by jlliagre
Are you claiming Java is not used in these environments ? This is absolutely untrue.
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.

Quote:
Originally Posted by jlliagre
Please clarify this "Java can't perform" statement.
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.

Quote:
Originally Posted by jlliagre
You seem to be missing what java enterprise edition is all about, and how widespread is its use in large companies.
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.

Last edited by Randux; 09-26-2006 at 07:57 AM.
 
Old 09-26-2006, 08:10 AM   #28
taylor_venable
Member
 
Registered: Jun 2005
Location: Indiana, USA
Distribution: OpenBSD, Ubuntu
Posts: 892

Rep: Reputation: 43
Quote:
Originally Posted by jlliagre
Certified JVMs exist too for AIX, HP/UX, z/OS, OS/400, OS/390, OpenVMS, tru64, FreeBSD, and certainly many more.
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.
 
Old 09-26-2006, 09:41 AM   #29
jlliagre
Moderator
 
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris 11.4, Oracle Linux, Mint, Ubuntu/WSL
Posts: 9,783

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
Quote:
Originally Posted by Randux
Java is only used as a front end
This is incorrect, Java is mostly used as middleware in large companies.
Quote:
it's too slow
It's fast enough for them.
Quote:
and has too many other problems to be used elsewhere.
This is FUD.
Quote:
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.
Unix is competing with mainframes there.
Quote:
No performance sensitive software has been deployed in Java.
The fact you haven't deployed performance sensitive s/w in Java doesn't means nobody does.
Quote:
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.
Correct.
Quote:
UNIX has been ported to tons of platforms- IBM none.
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.
Quote:
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.
Virtual Machine is not that bad ...
Quote:
You cannot do systems programming in IBM land with C and certainly not with Java, and you never will.
You neither do system programming with Unix in Java. Java doesn't pretend to support that.
Quote:
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.
Interesting.
Quote:
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.
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.
Quote:
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
I understand what you mean.
Quote:
Java cannot, and cannot ever be made, to perform. I can't imagine that any further clarification should be required.
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.

Quote:
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.
Well, IBM is supporting that too, being the number one vendor of Java EE with WebSphere.
Quote:
As I said, it's a second rate choice for a GUI front end, and that's about it.
You need to learn a lot there. This was true 10 years ago, but it is no more.
Quote:
I'm very familiar with data processing operations at the largest corporations in the world, since they are virtually all our customers.
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.
Quote:
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.
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.
 
Old 09-26-2006, 10:41 AM   #30
xhi
Senior Member
 
Registered: Mar 2005
Location: USA::Pennsylvania
Distribution: Slackware
Posts: 1,065

Rep: Reputation: 45
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

Quote:
Java can't be faster than assembly language but nobody cares when Java is fast enough.
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.

Quote:
Java cannot, and cannot ever be made, to perform. I can't imagine that any further clarification should be required.
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Java plugin installed correctly for Firefox but not able to view any java applet tvn Linux - Software 10 04-15-2010 02:13 AM
Firefox refuses to load Java jnlp files - plugin and java ok Melsync Linux - Software 1 06-25-2006 04:09 PM
Synaptic Package Manager shows 'java-common' and 'java-gcj-compat' as Installed. swiadek Ubuntu 3 02-12-2006 11:54 AM
JAVA JRE installation to view java applet through browser dipenchaudhary Linux - Software 1 01-23-2006 09:20 AM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 07:01 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration