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

Buck

Here are more ramblings of one who is struggling with the same questions:

At 10:09 AM 12/1/1997 -0500, you wrote:
>>> If we use OO to design our client properly, then the client has a clear,
>>> well defined standard interface to the server.  It is this interface
which 
>>> makes the client application independent of the server platform. 
>>
>>I gotta be honest, I don't see what OO design in the client has to do with
>>the server's interface. What if the server was written by a maniac and the
>>interface is cumbersome and confusing?
>
>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...)  


As I see it, the client should know diddly about data queues, ODBC,
whatever. The client asks your server for the information it needs, and the
_server_ knows the best way to get it for whatever backend you're dealing
with. It sounds like you want _both_ the client and the server to retrieve
data. I don't advocate this approach. Rather, separate function more�the
client is essentially presentation, input, and some calculations (very
simplistic I know); the server is a middleman that retrieves data from a
database/backend machine and serves it to a requester, otherwise known as a
client.

A real-world analogy. You are a client of your local IGA or A&P. Would you
go to the trouble of talking to the rancher or farmer that provides what
the grocer sells? Usually not. You want to get a steak, you don't want to
buy a side of beef and then cut your own steak out of it. You don't need to
know the details of how the steak got there, just that the grocer (server)
has been found reliable and trustworthy in the delivery of what you want.

-snip-

>>> To that end, we try to make our OO app as machine-independent on the
client as 
>>> possible.  Why bother designing all those classes, etc. only to have to
re-write the 
>>> blasted things so they run on another client platform?  Likewise,
what's the point 
>>> writing an awesome OO system that can't talk to another server platform
without 
>>> a re-write?  In each case, we lose our prime goal of code re-use.


Don't forget polymorphism, which, along with inheritance, gives the ability
to have different methods of the same name and with different arguments.
This can be the basis for multiple system access in a server�each
additional platform is not a matter of having "to re-write the blasted
things"�rather, a matter of adding to what already exists.


-snip-

>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. 


Buck, you seem stuck on this "re-writing" thing. As far as I can tell, one
of the primary tenets of OOP is to eliminate "re-writing". As I mentioned
above, when new functionality is required, it is often "extending" rather
that "re-writing". But this depends on an appropriate _design_ in the first
place�a crucial aspect of OOP.


>>Platform independance is an advantage of Java. It has nothing to do with the
>>language being OO, but rather that it runs in a Virtual Machine. 
>
>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.
>
>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!
>
>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.


This is an inappropriate use of "re-use", IMO. This seems to me to define
"portability" more than "re-use".


>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.


True, but the operative phrase here is "my Java code". That is _not_ the
same as the concept of the portability of Java, as I see it.

-snip-

>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...)


This has intrinsically _nothing_ to do with Java qua Java. Sun never
promised to deliver what you're talking about, I think. Java is a
_language_, and that's all. The output of its compiler, according to Sun
specs, will be an object comprising so-called 'bytecodes', which can be
interpreted (and sometimes just-in-time-compiled) by any JVM on any platform.

As I see it, that is as far as the portability thing goes. This is much
farther, IMO, than Smalltalk or C or C++ have got, although they all
promise some kind of portability. In these latter languages, the
portability is there, to some extent, in the source code. It does not
extend to anything like an executable. You need separate compilers (or
enough options on the one you use) for _each_ destination platform. With
Java, you use one compiler, for all platforms.

There's always a line separating platform-dependent and
platform-independent parts of applications. With Java, the
platform-dependent parts are implemented in the JVM.

Now, I just read in _Core Java_, by Horstmann & Cornell (superb book,
well-balanced, a few typos),, there's a concept in Java of a 'toolkit',
which is something that gets at platform-specific data, for use in a Java
app. There's a Toolkit class already. I found this idea helpful in thinking
about the AS/400 Toolkit for Java. It's a set of tools to get at some
AS/400-specific information. That's its purpose, to provide other, possibly
more efficient, ways to get to data on an AS/400.

Does this take away from the portability of Java? Not a whit, when we
distinguish Java from _our use_ of Java. Should we _choose_ to use these
classes, that is our decision; should we _choose_ to use ODBC or JDBC to
accomplish the same thing, that, again, is our decision. These choices are
based on any number of things, including time to get the job done. If there
isn't as much time, go for the more generic solution. OTOH, if time is
sufficient, write the server piece that knows how to talk to various
platforms, and write the client to speak to the server, effectively
isolated from all concerns about platform specifics.


>>Obviously, the best combination would be a platform independant client
>>written in an OO language that addresses a CORBA standard interface. Say, a
>>Java client talking to a DSOM Java server object. 
>
>BINGO!

Fat Chance!!

>>> This idea of platform-specific client code goes against the grain of OO
>>> design, but I'm sure that they're out there...
>>
>>I would imagine that the largest amount of OO programs in existance are
>>platform specific. But I do know that there is a lot of work being done both
>>object based, and platform independant. 
>
>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?
>
>>Probably all this is is a little semantic confusion. Often, though, people
>>new to OO programming and object based systems get thrown off course by
these
>>semantic differences and so I think it's important to be clear. 


Eschew obfuscation!


>Agree 1000% !!!
>
>Buck Calabro
>Commsoft

Cheers

Vernon Hamberg
Systems Software Programmer
Old Republic National Title Insurance Company
400 Second Avenue South
Minneapolis, MN  55401-2499
(612) 371-1111 x480


+---
| 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
+---