Re: Re[2]: What makes Java so special? -- JAVA400-L

** Reply to note from Buck Calabro <mcalabro@commsoft.net> Mon, 1 Dec 1997 
18:40:19 -0500

[snip]

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

Well, here you do identify that making a client server independant is one
step further than making it platform independant.

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

.. if both systems are running identical data bases (ie, files, fields,
data format, security, etc. Otherwise, there will be one method
written to access one, and a different method to access the other. 

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

But here we're back to server dependance being the same as platform
dependance. If you wrote that Java app as carefully as you wrote the C++
app, then you didn't have to recompile when you moved it from one box to the
other. 

However, you probably discovered when you tried to port the C++ app that the
class libraries you were using to write your application were developed by a
third party company. That company probably limited the platforms they ported
those class libraries to, and if one of them was a Unix platform it does not
mean it is portable to all Unix platforms. 

So, what you learned is that it takes the same amount of care to make any
client server independant, but for portability Java has other languages beat
by a mile. 

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

C was never purported to be server independant. C was touted as portable
because it was standardized across multiple platforms, primarily different
versions of Unix. Most implementations were to an ANSI standard, but
Microsoft add a large number of enhancements to their compiler and since
they controlled the desktop development market this affected the resulting
applications.

C++ is OO, but since it relies on class libraries which may or may not be
ported to other platforms it may or may not be portable. Developers which
already gave up platform independance to use compiler enhancements could
still take advantage of OO coding.

But you are still comparing apples and oranges. You have indicated that Java
applications should be server independant, and as example you point out
difficulties with platform portability. These are two very different goals.

To compare with the problems of platform dependance, I think you should look
more to native method calls. This would be the way that a Java app can call
a native application on it's local machine. So, let's suppose you wrote a
great C++ app that talked to any server. Now, you compile the C++ app on
your NT pc and write a Java app. Instead of recoding, you just call the C++
app as a native method. Now, you have a server independant Java app that is
platform specific. This would be a comparison to the C portability issue.

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

Try to remember that it is doubtful you will be writing code just for the
sake of writing code. If you are out coding a solution, then the problem
being solved will probably contribute to the equation. 

If the problem being solved has something to do with a GUI client that talks
with AS/400 based existing applications, then a data queue might likely be
your best solution. If you are simply writing a new application from
scratch, then you might decide to simply code using completely standard
object brokering and JDBC calls to the data base. This will let you decide
when the product is finished what hardware you want to run it on (and evolve
that as time goes by). You will have to live with the fact that your end
result is not as fast as it might be, but your trade off should be worth it.

> Buck Calabro
 

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