Re: What makes Java so special?

[Buck Calabro <mcalabro@xxxxxxxxxxxx>]

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

>I am pretty sure that part of this will be dependant on how the server is
>written.

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

>> Don't forget that code re-use is the end-goal.  It is re-use which drives 
>all the
>> other perceived benefits of using OO in any form.
>>   
>> 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.
>
>I must differ. Code re-use is not _the_ end goal. It is a major part of OO,
>but I think it's important to realize that component re-use is really what
>you are after. I am sure you know this, but your comment didn't make it very
>clear.

Toe-MAY-toe, toe-MAH-toe... <g>

>Using OO programming techniques you can develop and debug a component.
>Whether this component is an employee record or an AP sub-system. By using
>this component for all references of that object type, you re-use the code,
>and all the other work in developing it. 
>
>But this brings us to the part of your statement that I REALLY disagree with.
>OO programming has nothing whatsoever to do with platform independence.
>Smalltalk is OO, so is C++. Both of these languages have a much, much longer
>history than Java and can be very effective tools for OO programming. Both
>must be recompiled if the application is moved to another platform. 

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. 

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

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.

>To make a client "server independant", which seems to be what you are
>describing, the client should be object based and refer to it's server using
>a object model standard. But a "server independant" client can be written in
>assembly code on a 6502 with no hopes of porting it to any other client
>machine.

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!

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

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

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

Agree 1000% !!!

Buck Calabro
Commsoft

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