Re: What makes Java so special? -- JAVA400-L

** Reply to note from Buck Calabro <mcalabro@commsoft.net> Mon, 1 Dec 1997 
10:09:11 -0500

> The client interface cannot exist without the server interface. (I can't
> write the client to use data queues and the server to use ODBC and
> "parameter" files...) What's the benefit of writing a great OO client and
> not writing an equally great server interface? (The "what-if" is a bit
> farfetched...) 

That's my point. You stated that you would have a clean/easy interface to
the server if the client was written OO. I think that it would depend on the
interface the server was written with.

> Yup! But if I'm writing the client and the server, why wouldn't I extend
> my OO  design to the common interface?

No reason not to, if you are writing both. Also, you might look to using an
industry standard object model in case you might add different clients in
the future. 

> Re-compiled is one thing. I certainly don't expect my machine code to run
> on multiple machines! I'm talking about re-use here. If I can simply(!)
> re-compile my source to run on another platform, then I am reusing that
> application,  component, source, whatever. If I have to re-write,
> re-debug, re-test, re-document and re-compile, then I'm not re-using my
> code, component, application, bean, whatever. Re-compiling doesn't violate
> platform independence, re-writing does. 

But again that has nothing to do with OO. C, Basic, Forth, Fortran, etc. can
all be written to an ANSI standard which will allow recompile on the new
machine. None of them are OO. 

> OK. You're talking about "byte-code", "P-code", "MI code", "object code"
> or whatever  the Java folk call their version of the interactive code
> interpreter. The fact that the "object code" can physically execute on
> many hardware platforms doesn't mean anything at all if that code calls a
> VM BAL program that will only run under MVS.

Well, this is the "Yes and no" part of it. Using the network model, when the
Java program executes on the NT server, it may still call that VM BAL
program on the MVS host. 

The same is true with data queue useage. I can write my client to stuff data
in an AS/400 data queue. The client can float anywhere on the network and
from wherever it is, stuff that data into the AS/400 data queue. The server
reading the data queue can also be anywhere in the network,
reading/processing/writing. 

> A _very_ similar situation exists with REXX. REXX runs on OS/2, AS/400, VM
> and MVS.  This is great as long as I don't write any OS/2 specific code in
> my REXX proc and then try to run it on my 400. It'll "run", but it won't
> work!

I think it is more a BASIC analogy. You can take the source, but not the
rest of the required components. With Java, you take the object code and it
still points to the original required components. It still works fine.

> OO=re-use. Re-use=ability to execute application (after re-compile) on
> multiple machines and obtaining the same results without re-writing the
> app.

OO has to do with the coding techniques and has nothing to do with the
re-use of the application (other than as a component for another
application). 

Platform independance allows you to move the app to multiple platforms
without recompile and run the app. Network computing model means you can
access objects across the network as if they were local. The combination of
these allows you to move your client anywhere and use the same components.
   
> If my Java code talks to some AS/400 specific widget, then it's not
> portable. If it's not portable then I can't very well re-use it, no matter
> that the byte code can be  interpreted by another hardware platform.

The point is, yes you can. 

> As you point out so rightly, one _can_ write a "server independent"
> application for a specific client hardware platform. What Java _should_
> bring to the table is to allow us the freedom to take this "server
> independent" application and run it on *any* client hardware platform. 
>   
> What's the down-side of that? A client application that can run on many
> client platforms and talk to many server platforms... sounds like heaven
> to me!

It is what Java offers. 

> My fear about Java still centers around putting code, beans, whatever that
> only work if they talk to an AS/400. Now, my much-vaunted Java
> independence means only that I can pick any client platform to run on, as
> long as the server is an AS/400... I gotta tell you that we need to talk
> to other boxes as well as the /400. Even IBM has figured this out by now
> (NT on the IPCS, etc...)

No. As long as the code is 100% Java, you can choose your client platform.
The nit you are picking has to do with choosing to talk to a specific
server. There is no requirement to.

As far as I can see, what you are saying is that you don't think anyone
should use the AS/400 Toolbox for Java. Then don't. But if you wish to add a
component to an existing AS/400 installation that uses data queues, you are
probably not making the wisest choice. 

You don't NEED that toolbox for Java apps to run on/work with AS/400s. It
just helps to integrate new java apps into an existing framwork of
applications/objects. 

Some people might not want to just toss out all they have running right now
and rewrite it.

The things that hobble Java are things like Activex components. These
require the client run on a 32 bit Windows machine. Then, your client is
stuck on one platform. 

> If you're the designer, and you have the opportunity to write both sides
> of the application, why would you write platform limited, um, I mean
> platform specific code?

That would depend on the requirements of the application. If you are writing
from scratch, you would obviously start out wanting the most independant
code possible. 

But I think that not too many AS/400 shops are starting from scratch. 

> Buck Calabro Commsoft
 

Chris Rehm
Mr.AS400@ibm.net

How often can you afford to be unexpectedly out of business?
Get an AS/400.
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "JAVA400-L@midrange.com".
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---