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


  • Subject: RE: What makes Java so special?
  • From: Marshall Dunbar <marshall@xxxxxxxxxxx>
  • Date: Mon, 17 Nov 1997 08:41:50 -0500
  • Organization: DPS, Inc.

> The JVM in the Java Toolkit lacks support for AWT. Without AWT,
> exactly
> how will developers write native Java applets for the AS/400 that can
> port to other platforms?

I'm not sure I understand your question.  The toolkit does not prohibit 
you from using the AWT.  The toolkit is primarily a set of classes that 
let you access resources of the as/400.  When the sever-side JVM for 
the AS/400 is available, a provision for "remote AWT" will allow the 
400 to acquire and display graphical output on a client display. 
 Personally, I believe any AWT is not necessary for the 400.  In the 
Java paradigm, the 400 will be a server and the client will have its 
own JVM to handle graphics display.  The 400 is good at database tasks 
and handling simultaneous requests from many clients. The client (PC) 
is good at graphics and user interaction (mouse, keyboard, sound 
effects).

Any Java application written on the 400 will be portable to other 
platforms as long as you don't take advantage of any unique as/400 
resources.  That means sticking to JDBC for database requests and 
staying away from native programs, data queues, DDM, etc.

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

I don't think I spend any more time on data queues and native program 
calls than on JDBC and stored procedures.  I specifically state that 
with JDBC you end up with a portable program that can be pointed to any 
server that uses JDBC.  With the other access methods, I reference that 
you lose portability (of the server, not the client) since you are 
targeting the as/400's native resources.  The choice to target the 
as/400 or a generic server is up to the developer and is not precluded 
by using the toolkit.

> I'm glad the AS/400 division is working with Java but I'm worried
> that
> it will be a half-hearted effort that forgets the incredible
> investment
> already made by IBM's midrange customers. If the effort results in a
> poor implementation it will turn out to be just another reason why
> developers will leave the AS/400 platform.
>
> Any thoughts?
> Patrick

Based on my time in Rochester writing the Redbook, I don't believe that 
IBM's efforts on Java and the AS/400, client and server, are 
half-hearted at all.  There are many dedicated and intelligent people 
working to make the AS/400 a premier Java platform.

------------
Marshall Dunbar
DPS, Inc.
Co-author of the Redbook, "Accessing the AS/400 System with Java"
marshall@dpslink.com
http://www.dpslink.com


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


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.