Re[2]: What makes Java so special?

[Buck Calabro <mcalabro@xxxxxxxxxxxx>]

Vern,

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

Oh, no!  I hope I didn't say that!  I want the client to ask for data and for 
the
server to provide it.  Chris and I have been talking about 2 different ways
for the server to present data to the client:

1.  Client sends request to a server program via data queue.
     Server returns data to client via data queue.
2.  Client sends "request" to server database via SQL (ODBC/JDBC...)
     Server "returns" data to client via standard SQL.

I was really wondering how client number 1 would be able to make the
same request to a Unix box, considering that Unix doesn't have
data queues...  Quite an education from such a simple question! <vbg>

-snip-

>> To that end, we try to make our OO app as machine-independent on the

-snip-

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

Good point.  I had, indeed forgotten polymorphism.  For whatever 
reason, I simply didn't link "data access" and different arguments
together.

-snip-

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

Hmmm.  You're right, of course.  Here's what I was thinking:
In the larger world of client-server, Java will increase portability
to multiple client platforms: why not extend  that line of thought
to cover multiple server platforms?

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

How can we disassociate "my Java code" from "Java is portable?"
The C folks have portable code in theory, too.  But there's so much
client-platform specific code in there, that it's portable only in theory.
Java is one step further down the portability road, providing API's
(call them what you may) that isolate the app from the client.  Why
not take that extra step and *try* to isloate the app from the server?

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

I understand that, and I think it's a good idea.  I'm not expecting Sun to
do anything about embedding server-specific code into Java apps; I'm
expecting *me* to do that!  That's why I weighed in against data queues:
it's embedding platform-specific code into what *could* be portable code.
Granted, it's specific to the server, but when there are generic, standard,
non-server-specific ways to get the data to the client, why, oh, why would I
nail my code to one server?

Even using polymorphism, I'd still be taking one client task:
"Tell me the history of order number 7." and developing 2 ways to
do it:
1. Client to data queue; data queue to server pgm; server pgm to data queue;
    data queue to server.
2. Client to ODBC; ODBC to database; database to ODBC; ODBC to client.
Yes, I'd have one method "Get_Order_History", but I will still
have to do the work twice, when I don't really need to...

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

If I carefully write my Win 3.1 C++, I can re-compile it and run it on 
a Unix box, right?   Why isn't this a common occurance?  
Performance of "standard API's?"  How will Java be any different?
We've already heard that data queues are the fastest way to 
talk to the AS/400: performance is clearly a reasonable issue to
worry about.

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

Well said, well said. 

My entire point was (and is) that if I (the programmer) choose to use
server-specific interfaces, then the resulting application will not be
portable.  This isn't a calumny against Java; it's a warning about 
history being repeated again, a la C and it's purported portability.

Perhaps extravagantly, I linked portability and code re-use.  It's hard
for me to seriously consider that the current AS/400 is the only server
I'll ever talk to.  Without true portability (Can I talk to multiple server
platforms?  Can I run my client on multiple client platforms?), I'll be
doing the System/3 CCP conversion.  Again. 

For those of you who have been so patient with me, I'd like to say
THANKS!  I realise that what I say can sound like arguing for the
sake of argument, but I'm really trying to nail down the basic
ideas of doing client server with Java (as opposed to C, Delphi,
VB or any other client language...)

Chris and Vern especially get my thanks, because they've helped 
me through some interesting, if philosophical, questions.

Thanks!!!!!

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