× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



DEan

At 08:13 PM 5/30/1998 EDT, you wrote:
>Vernon,
>
>In a message dated 98-05-30 11:33:43 EDT, you write:
>
><<snip>>
>> The IBM approach does _not_ limit you to running on the 400. The
>>  applications that you create can run on any Java virtual machine. The
>>  400-specificity here has nothing to do with Java. It's no different from
>>  using Lightning in VB to talk to the 400.
>>  
>>  So, IMO, it's misleading to lump these approaches together, esp. to
suggest
>>  that IBM is pulling the rug out from under the portability of Java by
>>  providing classes for 400 access.
>
>The IBM JDT _does_ limit your applications to the /400.  That's it's whole
>raison d'etre.  However, someone writing cross-platform applications would be
>well-served by identifying the platform on which the application is running
>and optimizing their code for that platform.  For example, use a JDBC for all
>platforms, yet allow room in your code to use the /400 (or HP/9000, or
>DEC/VAX) extensions to make it run optimally.

I think we're saying the same thing, although it appears we are saying
opposite things.

My point about the IBM approach addressed where the Java app _runs_, not
the system to which it is _connected_. I still believe that, in terms of
where the program _runs_, this approach does not limit you.

If you look at the source for the AS/400 Toolkit for Java classes, you will
see that they are straight, pure Java classes. They make calls to server
programs, via Sockets. This does nothing to diminish their 100% Java-ness,
IMO.

As you say, it is best to be able to write optimized code in apps that
knows to which kind of server the app is connected. This is harder to do
but has great benefit. The same principal applies to any client/server
distributed apps, whether written in Java, VB, Delphi, or ???. Having
AS/400-specific OCX's does not make a VB app any less a VB app, does it?

The alternative to optimized classes or OCX's or whatever, is to use the
generic processes, like ODBC or JDBC. These will also work, albeit with
potentially lower performance at the user end and harder development at the
programmer end.

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 MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.