[Sorry if this is a duplicate; got my email sending ability back!]
-------- Original Message -------- Subject: Re: Performance tools and JAVA Date: Sun, 20 Nov 2005 12:37:53 -0600 From: Kirk Wolf <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> While it might resonate on this list, I find your argument somewhat specious. Under consideration we have a large Java app of dubious quality that requires a specific version of Java. You compare that to some code that you wrote that still runs and your conclusion seems to be that assembler is more version-portable than Java. Of course, it could be true, but other (possibly specious) reasons could be given: - The complexity of a typical java program and the large set of class libraries included in the JDK can lead to more compatibility problems. But that's my real point. As you say / imply: Java programs are typically complex and tend to have more compatibility problems. But that shouldn't / wouldn't be the case if you made a rule: if you change the properties of a class, you create a new class; you should not be allowed to change fundamental interfaces once they are in use. - Assember is more version-portable because you can't do much with it that you couldn't do 30 years ago :-) Yeah, yeah. But you can. You can, for instance, process Unicode in hardware instructions, you can create and use DLLs, you have more power in addressing data. But what is fair for any language: if you use new features, you have to re-write / re-compile / re-bind. What I understood of the original post, no changes were made to the app, but the new run time invalidated the app. - Assembler is better because bad programmers can't use it Oh yes they can. I think we agree that bad programmers can make a hash in any language. IMO, a somewhat better analogy would be to compare this java app to a large CICS BAL application written for 1.5 that won't work on the new version of CICS. Perhaps. But the selling point, the reason for using Java is time and again: code once / run anywhere. [Oh, and code reuse.] There are no caveats about currency and version level. Generally, it is rare to find Java apps that are written for one JDK level that won't work on a later level. In this particular case, it could be something as obvious as an application that checks for a specific version and won't allow any other that it wasn't specifically tested with. Its best to avoid vendors that can't keep reasonably current, no matter what language they use. Now that's specious. Code that works for long periods of time provides a better return on investment than code that has to be re-worked every year or two just because the run-time has changed. Kind regards, -Steve Comstock On 11/20/05, Steve Comstock <[EMAIL PROTECTED]> wrote:
Oh yes, JAVA: Write once, run everywhere. Unless you're down level. And levels change pretty quickly. I have some 30-year old Assembler code that was assembled and linked once and still runs. Even COBOL (although OS/VS COBOL and older are now not viable, well after 15 years from non-support) has a longer half-life than JAVA code, it seems. Kind regards, -Steve Comstock
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
