Unconfigured Ad Widget

**J.Pluta** · 03-30-2000, 04:37 PM

version control

We have decided to make Java our primary programming language. We have a couple of programmers who have learned Java and demonstated it on the AS/400 with some simple apps. We are now ready to re-train the entire staff and make the move to Java. Aieeeeeeeeee! Jim, you KNOW that I have "Java Joe" tatooed on the insides of my eyelids, but you're scaring me! What exactly do you mean by this statement? For example, how do you plan on doing I/O? (Please, please, PLEASE tell me you're not going to use JDBC!) Making "the move to Java" involves WAY more than simply retraining the staff! Are you going to teach them object-oriented design? Do you have OOA and OOD tools yet? Have you divided your programmers up by ability and expertise into class creators and class consumers yet? Who defines the corporate standards for object naming conventions? Who owns the definition of all your interfaces? WHO WRITES THE JAVADOC??? It's a brave new world out there... for example, in a true object design, almost NONE of your code is actually in the "apps" - application programs are just combination of existing software components. In fact, the concept of an application program loses much of its meaning, since it spends most of its time communicating with predefined business objects. NO application should do any database I/O, for example. Otherwise, you are simply moving your procedural code into Java, which will be much more trouble than it is worth. I personally know of a company that is in the process of dumping a $350,000 investment in the "move to Java" because at the end they found out that it was slow and unstable, and very difficult to debug and maintain. On the other hand, doing things "correctly" has a number of problems of its own. Take a good look at your programming staff and remember that, all things being equal, the ones who have been around for the longest are the ones LEAST likely to be able to make the jump to object technology - and make NO mistake, a good percentage of your programmers will never grasp objects. Finally, I really recommend taking a look at a gradual move to Java. I've been advocating a new approach called revitalization that has to do with putting a Java-based graphical front end on your existing systems, then slowly rewriting your business logic as needed. If you want more info, let me know. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

**Guest.Visitor** · 03-30-2000, 06:21 PM

version control

Joe When I say we are going to move to Java, I don't mean in a day. I am an old C++ programmer and know a bit about OO. I have spent two years training the staff about OO design. Two years ago we went to ILE and required the staff to use an object model for module naming. We simulated polymorphism. We also made rules about encapsulation. I have 12 people who need to be trained, and plan to take a year to get them all trained. I am trying to determine what IDE to use. Have you worked with the Visual Age Enterprise Edition? We have tried the Professional version on our system but this lacks a central repository and I would like to have a central repository. As for run time performance, we are testing this. Java on the client side is a winner to our users. They want everything to be GUI now. We are testing the batch side of things trying to determine hat to do about file access. JDBC is slow.

**J.Pluta** · 04-03-2000, 08:30 AM

version control

When I say we are going to move to Java, I don't mean in a day. I am an old C++ programmer and know a bit about OO. I have spent two years training the staff about OO design. Two years ago we went to ILE and required the staff to use an object model for module naming. We simulated polymorphism. We also made rules about encapsulation. I have 12 people who need to be trained, and plan to take a year to get them all trained. I grew up in C++ as well. Fortunately, I've unlearned most of the bad habits I got there . Not to be flip, but C++ is really "C with classes", just like Bjarne said it was. There are significant differences between C++ and Java. Some are obvious: no macro preprocessor (THANK YOU, SUN!). Others are less so. For example, have you learned to program to an interface (or at the very least an abstract class) rather than a concrete class? I'm just learning that myself, and it's going to take all summer to rework my classes for that. I'd be interested to see how you did your "object model module naming" in ILE. I can almost picture it in my mind; if done correctly, I can see it as an excellent conceptual tool for RPG programmers to cross the bridge from procedural to object. The best bridge to date has been Don Denoncourt's "RPG++". It's been very difficult not to steal it for my own seminars . I am trying to determine what IDE to use. Have you worked with the Visual Age Enterprise Edition? We have tried the Professional version on our system but this lacks a central repository and I would like to have a central repository. Right now, all my development is done by a staff consisting of me, so I haven't made use of the repository yet. I plan to play with it a little bit this summer; please let me know anything you learn about it, and I'll do the same. As for run time performance, we are testing this. Java on the client side is a winner to our users. They want everything to be GUI now. We are testing the batch side of things trying to determine hat to do about file access. JDBC is slow. JDBC is slow because it's JDBC, which is ODBC, which is CLI SQL (although I've heard rumors that the native AS/400 JDBC driver might be smart enough to use record-level access, I highly doubt it). If I could do any one thing in the world, it would be to convince business application designers that SQL is really, really inappropriate for business application development. RPG using native record-level access is, and for the foreseeable future will be, the best combination for business logic development on the AS/400, by a long shot. That's why, while I am a staunch supported of Java/400, I still say that server-side Java, other than servlets, is not ready for prime-time. On the other hand, I absolutely agree that Java is the best solution for user interface. Either thick client via Swing or thin client via JSP and servlets, Java is THE language of choice. My architecture is simple: Java client speaking to an RPG server. The connection is a Java "data model" (in the model-view-controller sense) which supports either thick or thin client. The nice thing is that the data model provides you a buffer as you move from traditional monolithic programming to client/server to object. Anyway, please keep us posted on how the move is progressing. I'm anxious to hear what you uncover during your work. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

**Guest.Visitor** · 04-03-2000, 10:35 AM

version control

Hi Jim, You may want to look for info about CVS: http://www.cyclic.com/cyclic-pages/cvsdev.html and especially JCVS: http://www.jcvs.org/ I really can't personally vouch for either ( although many projects, like Apache, use CVS, ) but, without disparaging VAJ, its repository is proprietary. If you decide at some point to change IDEs, or for your experts or outside resources that may not use IDEs ( or different ones, ) I think you're much better off with a more general solution, whether CVS type or otherwise. To just say "JDBC is slow," is like saying "Java is slow," in that there are so many variables involved that one can't really make a sensible reply without particulars. What is true is that a good knowledge of SQL and SQL engines is also required to make it run well. But, one perspective is that if one decides that record i/o ( or your favorite non-standard speed up ) is the way to go, keep in mind that portability is lost. As usual, there are tradeoffs that should be ( but often get lost in the whirl of development ) carefully weighed. Given your stated background, I'm sure you won't allow this to be the case, but there are a lot of people writing RPG in java syntax, similiar to all the C programmers self proclaimed as C++ gurus because they have a C++ compiler. Anyhow, if I decided to use record level i/o ( and I won't unless the client pays me LOTS without my having to take responsibility ;-) ) I would allow for a switchable data model that let me run record i/o, standard SQL or anything else so I could use the same apps on other platforms and engines with a change in preferences. IMO, etc. Best, Joe Sam Joe Sam Shirah Autumn Software Consulting/Development/Outsourcing Please Note New Email: jshirah@attglobal.net Visit our User Group at: http://www.jax400.com

**Guest.Visitor** · 04-03-2000, 10:55 AM

version control

Hi Joe, Given your C++ background, you should have little problem with abstract classes. Interfaces, OTOH, while not difficult, are a somewhat new concept. I would urge everyone who is anywhere past java basics to take the time to learn interfaces and understand their uses and implications. They provide answers to a number of dilemmas and otherwise questionable programming practices. Best, Joe Sam

**J.Pluta** · 04-03-2000, 01:10 PM

version control

Given your C++ background, you should have little problem with abstract classes. Interfaces, OTOH, while not difficult, are a somewhat new concept. I would urge everyone who is anywhere past java basics to take the time to learn interfaces and understand their uses and implications. They provide answers to a number of dilemmas and otherwise questionable programming practices. Actually, I don't have any problem with either concept. They are, in a way, points on a continuum, with interfaces on one end and concrete classes on the other. A concrete class is a completely implemented interface, while an interface is a signature with absolutely no implementation. An abstract class falls somewhere in between, because it has some implementation (although you can have an abstract class with no implementation - all methods abstract - or completely implemented - no abstract methods). What becomes interesting is the actual application of the concept in a development environment. Only through a couple of years of experience can I see why there is a dictum: program to the interface, not the class. This is because of the incredible benefit of using interfaces to define your system, which isn't obviously apparent in a multiply inheriting environment such as C++ (where interfaces tend to play a lesser part, since you can simply inherit from multiple concrete classes whenever you want to). By programming application code to an interface rather than to a concrete class, one can add additional peer classes (classes that conform to same interface) without changing the application code. This may be one of the most powerful features of an object approach, at least as far as business application programming is concerned, because it means that the business logic can be extended without so much as recompiling the application code. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

**J.Pluta** · 04-03-2000, 01:32 PM

version control

I really can't personally vouch for either ( although many projects, like Apache, use CVS, ) but, without disparaging VAJ, its repository is proprietary. If you decide at some point to change IDEs, or for your experts or outside resources that may not use IDEs ( or different ones, ) I think you're much better off with a more general solution, whether CVS type or otherwise. I'm not sure that matters, really. In fact, none of the other tools I know of even uses a real repository... they use Java source files as their storage medium. If you need to switch to one of those, you can simply export from Visual Age. Not only that, VAJ has some nifty tools for repository access, even allowing you to write your own code generation tools. Repository-based programming beats any other form of source management. To just say "JDBC is slow," is like saying "Java is slow," in that there are so many variables involved that one can't really make a sensible reply without particulars. What is true is that a good knowledge of SQL and SQL engines is also required to make it run well. But, one perspective is that if one decides that record i/o ( or your favorite non-standard speed up ) is the way to go, keep in mind that portability is lost. As usual, there are tradeoffs that should be ( but often get lost in the whirl of development ) carefully weighed. That's simply not true. There is no way to make an ANSI-standard SQL implementation perform as well as a record-level access system when doing sophisticated transaction processing, which is the primary requirement of business applications. It requires a high degree of SQL tuning expertise and a fair amount of stored procedure programming (the typical SQL non-standard speedup)to come close, and at that point, your standardization has gone out the window. I suppose when the next ANSI standard comes out (and they include what looks to be an entire procedural language within the stored procedures) that SQL may begin to come close, but that will still depend on the host engine. At the same time, exactly what is the benefit of being able to move your host processing to a new machine? How often do you replace your host platform? WORA in and of itself is not necessarily a good thing... as you've pointed out, one needs to weigh all the benefits, and WORA is simply one of them - and an ephemeral one at best in the server market. It is absolutely NOT worth a significant loss of performance on my server. I can accept it on my client, where there is no shortage of horsepower and the short lifespan makes a real requirement for platform independence, but my server is my bottleneck, and to make it gag on SQL just so that I might be able to move to another platform someday is a very, very poor business decision. If I'm an IS manager who can't tell today what platform my servers will be running on two or three years down the road, then perhaps I ought to be examining career opportunities outside the IS field. Given your stated background, I'm sure you won't allow this to be the case, but there are a lot of people writing RPG in java syntax, similiar to all the C programmers self proclaimed as C++ gurus because they have a C++ compiler. Anyhow, if I decided to use record level i/o ( and I won't unless the client pays me LOTS without my having to take responsibility ;-) ) I would allow for a switchable data model that let me run record i/o, standard SQL or anything else so I could use the same apps on other platforms and engines with a change in preferences. IMO, etc. Sorry, but that dog don't hunt. The so-called "requirement" for platform independence at all costs is an absolute myth, and in fact the promotion of that myth is as damaging to the industry and its reputation as the Y2K hype was. Especially in the real world of high-volume transaction processing. If you as a consultant come to me with an SQL solution for a OLTP engine, I'm going to put you in a special spot in my assessment list. And if you want me to fund you to develop a platform independent solution when I only need it to run on a single platform, I again have a special place for that solution. It's round and sits on the floor next to my desk. No, record-level I/O on the AS/400 accessed via messages is the right model for today's generation of business applications, especially when dealing with legacy systems. They give you performance while still providing a bridge to some future better-performing technology should that future technology ever materialize. Until then, anything else is overkill whose primary result is to make consultants wealthy. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

**Guest.Visitor** · 04-03-2000, 07:22 PM

version control

Hi Joe, I found this to be a rather, um, interesting response, especially since I thought there was little debatable here. Most of my comments were of the "check it out, think it through, then make an educated choice" variety, with my opinions, I hope, clearly stated. On much of this, it appears we should just agree to disagree. I do want to mention two things, though. First, I would appreciate it if you did not put words into my mouth; I'm very capable of inserting my own foot. This, which I said: "What is true is that a good knowledge of SQL and SQL engines is also required to make it run well." is not equivalent to this in your response: "That's simply not true. There is no way to make an ANSI-standard SQL implementation perform as well as a record-level access system when doing sophisticated transaction processing..." Again, there are many factors, including Good Enough, and the fact that client/server and n-tier apps depend on many factors, I/O being, as always, very important, but just one factor. And, I found this personally offensive as a response to my statements: "Until then, anything else is overkill whose primary result is to make consultants wealthy." I've been in this business long enough and from a number of different vantage points to understand that many so-called "consultants" engage, knowingly or, sadly, unknowingly in this practice. But I've also developed a new acronym, FIP ( Failure in Progress ) for many projects in new technologies in which those responsible will simply not put the time, education and money required to make the thing work. Then the technology is blamed. BUT, I refuse to accept that the above statement applies to me when I advocate standard practices, including switchable models for non-standard processing. We already have cases of processing moving completely off AS/400s, because RPG and other legacy written apps simply do not compute on other platforms and I will not contribute to that without full client awareness and responsibility for continuing on that course. Beyond that, I don't see much benefit in continuing the conversation. Joe Sam

**J.Pluta** · 04-04-2000, 06:06 AM

version control

"What is true is that a good knowledge of SQL and SQL engines is also required to make it run well." is not equivalent to this in your response: "That's simply not true. There is no way to make an ANSI-standard SQL implementation perform as well as a record-level access system when doing sophisticated transaction processing..." No, but I was responding to the following: To just say "JDBC is slow," is like saying "Java is slow," And that statement just isn't true. JDBC *IS* slow. And anybody who says it isn't hasn't run the simplest of benchmarks. I ran some a while back showing that INSERTs run a couple of orders of magnitude slower than record-level WRITEs. I'd be happy to re-run those benchmarks. In fact, I may just do that this weekend. The point is this: JDBC is incredibly slow for OLTP applications, and you suffer a huge performance hit by coding in SQL. There is absolutely no debate on this subject, and our clients need to be told that in no uncertain terms: JDBC FOR OLTP IS SLOW. Or do you disagree? And, I found this personally offensive as a response to my statements: "Until then, anything else is overkill whose primary result is to make consultants wealthy." (...) We already have cases of processing moving completely off AS/400s, because RPG and other legacy written apps simply do not compute on other platforms and I will not contribute to that without full client awareness and responsibility for continuing on that course. I'm sorry you take offense. But here's my concern with your position: what possible reason could you as a consultant give for moving off of the AS/400? Why is it important that "RPG doesn't compute" on other platforms? Do you think there is a better platform out there? Do you think there is a single platform that can replace the AS/400 as a server in terms of cost of ownership, performance and reliability? The answer is either yes or no, and to me, it seems you are saying, "Yes". You see, every time you tell a client they should code a system with their eyes towards changing server platforms you are, in effect, endorsing such a move. To tell a client they need to take a (relatively large) hit in both performance and price (because platform independent development costs more, if only in testing!) in order to support some future server platform means you believe their current platform won't meet their needs. So back to my question: what platform do you see that will be a better server than the AS/400? If the answer is "none", then investment in a platform-independent IMPLEMENTATION is an unnecessary cost. Note that I am not advocating a platform-dependent DESIGN... yes, you should code replaceable I/O modules. But there is absolutely no need for an AS/400-served site to spend ONE THIN DIME on an SQL-based implementation of that design, when record-level access is superior in EVERY WAY except portability. My bottom line? Code a design that COULD be implemented in SQL some day, if necessary, but don't spend a penny implementing the SQL solution until you decide you're going to dump the AS/400. Or am I wrong here? Beyond that, I don't see much benefit in continuing the conversation. Again, sorry if I offended. But to be honest, I'm far more concerned that the many people who read this forum realize that there is a reasoned opposing viewpoint to yours. If they free up the money that would have been spent on a needless implementation of SQL, perhaps there will be more money available for exploring the frontiers of e-commerce or XML or some other NEW technology, something that will continue to extend the architecture of the AS/400, not force it into some old paradigm from the 1970's (which is when SQL was introduced). We bemoan the lack of interest in the AS/400. Well, a lot of that is OUR fault, because we don't push the AS/400 to our clients. It's about time we stand up for the platform. There is no room for a wishy-washy, "whatever you think is best, Mr. Client" attitude. The AS/400 IS THE BEST BUSINESS APPLICATION SERVER ON THE PLANET, and we need to trumpet that statement to the world. I have absolutely no desire to write code that relegates the AS/400 to an also-ran status - if I truly want the AS/400 to succeed, then I need to make a strong, personal investment in its survival. If, on the other hand, I'm perfectly willing to get paid no matter what lump of iron I work on, then I can drop the whole "crusade" and start writing SQL for a living. The search for WORA is a Quixotic one, because a platform-dependent server-side solution is not an enemy if you have the right server platform. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

**J.Pluta** · 04-10-2000, 08:57 AM

version control

In the Data Access layer far more time seems to be spent on how to handle the changes in the Object Model. IMNSHO Application developers should be working with objects not data access. Tools like Top Link or VAJ Persistance Builder, which generate JDBC, will give this to your application developers. BTW I agree with your overall sentiment that JDBC can perform OK. I've seen some applications using JDBC with acceptable response times. You've hit all the nails on the heads this time, David. First, class consumers (the O-O term for application programmers) should have absolutely NO idea what the underlying database access method is (note that this means that application programmers should NOT be programming in JDBC!). Second, class creators (the guys who write the objects that the class consumers use) should be flexible enough to use either. If JDBC is fast enough for the application, then go for it. If not, be prepared to use a client/server approach or a record-level access approach. In any case, this code is completely invisible to the class consumers. The beuaty of encapsulation is that, if done correctly, all these dirty little details are hidden from the application folks, who can instead simply concentrate on business logic. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

Unconfigured Ad Widget

Announcement

version control

version control

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment