Re: Re[2]: What makes Java so special?

[Vern Hamberg <hambergv@xxxxxxxxxxxxxx>]

Buck

At 09:01 AM 11/17/97 -0500, you wrote:
>[snip]
>
>>> The Redbook on writing Java applications spends a lot of time describing
>>> the Visual Age development environment and how to write applications
>>> that use Data Queues, etc. on the AS/400. Since data queues are only
>>> supported on the AS/400 how will these Java applications really be
>>> platform independent? A Java application that is 100 percent Java on the
>>> client but not on the server is of questionable value, I would think..
>>
>>Well, yes and no. 
>>
>>First, there are a couple of reasons for the Redbook to spend a lot of time
>>on Data Queues, one being that it is a topic you are not likely to find
>>covered elsewhere. Another reason that Rochester would like you to pay
>>close attention to those areas is ... so that you'll need an AS/400!
>>
>>But this is not quite the same as platform dependance (it's just close)..
>>The application you are writing will not need to run on an AS/400, it will
>>just need one around to talk to. 
>>
>>What you are given is a way to talk to an AS/400 in a native fashion. If
>>you have an AS/400 and you want to write to it's data queues, you can do
>>that with Java. But you don't have to. What would be a big mistake is for
>>IBM to NOT have a way to talk to AS/400s via data queues, as this is the
>>fastest way to converse with your AS/400. 
>>
>
>Chris,
>       This is more than a mere semantic difference.  This means that
>I cannot transport my Java client to other platforms without re-work.  This
>utterly defeats the much-touted "portability" gain.  
>Why should a development house write a killer Java app twice?  Once 
>for all the PC platforms and then again for the AS/400.  Clearly, the
>PC market is way bigger than the AS/400 market for such software.  
>Remember, we're not talking about Java for the AS/400, we're talking
>about Java that runs on my Win95 PC.  If it uses DTAQ's to talk to the
>AS/400, I'm not going to be able to pick it up and re-use it to talk to my 
>Engineering division's Unix box unless I re-write the C/S 
>communications over.  Did I overlook something?

You're right—you can't use a DTAQ approach with a Unix box. But I think you
did overlook something here. As I see it, anyway, the issue of portability
must divide somewhere, at least along the client & server divide.

1.      The client app, written in Java, will _run_ on any platform with a JVM.
        This is portable to other _clients_.

2.      Portability to other _servers_ requires 1 of at least 2 approaches:

        a.      Use non-proprietary means of communicating with servers—
                ODBC or JDBC, e.g.

        b.      Write the app so that it knows, by whatever means, what kind
                of server it's talking to. Then write analogous code for each
                server platform where needed. The idea of stored procedures,
                it seems to me, can fall into this approach.

Cheers

Vernon Hamberg
Systems Software Programmer
Old Republic National Title Insurance Company
400 Second Avenue South
Minneapolis, MN 55401
(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 MAJORDOMO@midrange.com
|    and specify 'unsubscribe JAVA400-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---