What you really need for .. systems development is something other than Java ... Java is really no stronger than VBasic .. and has no data base support either ... but I guess you like to just play with toys... not real programming .. -------- <laughing> Don't beat around the bush, Gene! Tell me how you REALLY feel! Okay, this is a decent little subject for a quick recap. While I know most of the readers of this forum are committed to Java, it probably doesn't hurt to review some of the strengths of Java versus other languages. First, let me indulge my own ego for a moment to point out my qualifications. I've been programming for over 20 years. In that time, my primary focus has been distributed systems for IBM midrange computers, starting with a S/3 model 15D, going on to the Series/1, and then the S/3x and AS/400. I used RPG and COBOL, which should pretty much fit your definition of a "real" language, Gene. At the same time, I was was developing code for microcomputers (which is what we called PCs before there were PCs). I've written in assembly, Pascal, C, C++, BASIC, dBase and Java, on chips ranging from 8080 and Z-80 to Pentiums. I'm one of the few people I know who has written an operating system that is still in use today (it's on a device called Access Telecom, which is a multi-protocol communications controller). I developed the first distributed national credit card system on a System/38 for Navistar, and I was the architect of the first commercial client/server ERP application, the Assistant products for BPCS. Okay, that's enough horn-tooting. If that's not enough to establish my credentials, Gene, then I don't know what else to tell you. In all my experience, I have never seen a better transaction processing machine than the IBM midrange, and the AS/400 is simply the latest exceptional entry in that line. Unfortunately, no matter how hard I've tried, I have been unable to create a commercially viable graphical client/server package for the S/3x-AS/400, for two reasons: until fairly recently IBM insisted on speaking SNA in a TCP/IP world, and there was no standard graphical client we could write to. IBM handled the communications issue by pretty much shifting their entire focus to TCP/IP, to where the AS/400 is (according to those who know way more about these things than I!) one of the most full-featured TCP/IP hosts currently available. BTW, if anybody knows area where IBM comes up short in TCP/IP, I'd like to know. One of my pet projects is to see if it's possible to develop an entire network using only an AS/400 and Linux boxes as workstations. As to the graphics problem, well, there have been efforts along the way which simply haven't panned out, and every one has the exact same problem: you have to either tightly control the workstation hardware and software, or you have to write some sort of generic graphics. At SSA, we attempted to control the hardware environment by telling our clients exactly what hardware they needed (and since we wre using OS/2 as the operating system, they were pretty hefty clients), but we still had problems. Our Japanese clients needed special double-byte capable terminal, which ranan operating system called JOS/2 (Japanese OS/2). The subtle (and not-so-subtle!) differences between platforms made it necessary to have different versions of the code. Then we had to write an NT version, because OS/2 lost the operating system war. And of course, there were different versions for each release of the various operating systems. Well, I began the job of encapsulating the logic in the Assistant products and isolating it from the presentation. While I didn't know it at the time, I was moving towards the MVC architecture (Model/View/Controller). By the time I left SSA, there was a product which made generic graphics calls to an underlying grahics engine. The engine was ported from machine to machine. In effect, we had developed our own virtual machine, although I was nowhere near bright enough to realize it at the time. For the next several years, I concentrated on the Y2K issue and developed a highly successful Y2K remediation product. But I kept dallying with graphics and of course, the newly emerging World Wide Web. Something told me the WWW would be somethng a little more important than personal home pages and cybersex sites. And then I started working with Java, and I realized that this was the graphical front end the AS/400 had been waiting for. Why? For a number of reasons: 1. Java is truly object-oriented, rather than object-based. You can easily extend the language, and its powerful object-oriented features make code development quick and productive. Proper use of polymorphism, inheritance and encapsulation are way too longwinded to go into even in this rambling post, but it means that properly designed system objects can be used very easily by application programmers and shared throughout the system. 2. Java is platform independent. Completely and totally. If you write 100% Pure Java code, you can be assured that it will run on any JVM anywhere. This includes the graphics, which is to me one of the single most impressive programming feats of the 90's. 3. Java completely separates presentation from data. Every widget in the Swing toolbox uses the MVC architecture, which means it is easy to change your presentation without touching your logic. And if you follow that design with your own classes, it's amazing how flexible and powerful your designs become. As the ultimate expression of this philosophy, one line of Java code can change an entire application from looking like a Windows application to looking like a Macintosh application. 4. Java supports alternate input devices from the ground up. This is a sign of the "good human nature" aspect of Sun Microsystems. Java is designed to support any sort of special input device, from breath controllers for the paralyzed to Braille controllers for the blind. Sun didn't have to do this, but they have. I've seen no other major corporation make this depth of a commitment. 5. Sun is committed to keeping backwards compatibility, which means that in most cases, your program object will run on any JVM, now or in the future. This single ability makes it a million times easier to support distributed software management; you can upgrade your users' JVM for speed and bug fixes, but you don't have to change their client software until it's convenient. 6. Java has built-in support for JDBC, which supports any ODBC capable database. At the same time, more and more vendors are writing JDBC-specific drivers to up the performance. And if that's not enough, IBM's Java Toolbox for the AS/400 provides sophisticated record-level access support (which I've encapsulated into some pretty simple classes that make it easy for RPG programmers to access AS/400 data). I could of course go on and on (as many who know me can attest to). I've written tens of thousands of lines of Java code, and I'm quite comfortable that I will write many tens of thousands more. I've released four packages, and am about to release four more, all of which provide robust, flexible access to AS/400 resources for graphical workstations. I write the code and test it on a Wintel workstation, then copy the code directly to the AS/400 for system testing. That simply can't be done with any other language. Anyway, I thought it would be a nice end-of-the-year thing to recap where we are, and why I personally think that Java, and especially Java/400, may well be the most significant advance in distributed processing, especially for IBM midranges, of the 20th century. Joe Pluta www.java400.net +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: firstname.lastname@example.org +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.