× 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 Asmussen opined:]
My suggestion was, if you are planning to support multiple servers, create a
generic JAVA version that will run anywhere.  After the base application has
been tested and verified, start developing server-side programs specific to
the platform to be supported.  For example, use a control record that tells
the application that it is talking to an AS/400, so use the toolbox stuff.
Sounded good to me at the time, but the "purists" tended to disagree.
Personally, I don't _WANT_ my stuff to run like it's on Windoze ;-)...
-------------

The idea is sound, Dean.  However, you don't have to go through the trouble of
adding a control record.  You can instead use a wonderful system call,
System.getProperty("os.name").  I take advantage of that in my Splf2Pdf class to
determine whether I can use the IFSFile streams instead of the standard Java
streams.

The best way to take advantage of that kind of call is to use a factory method
whenever you create an object that varies based on implementation.  You write
your application to use a class called Item.  All your normal methods, setters
and getters, are all in the Item class.  The application only sees objects of
class Item.

Under the covers, though, magic happens.  Item declares any method that changes
from implementation to implementation as virtual.  Let's say the Item class uses
native I/O to read a record on the AS/400, but SQL on other platforms.  Okay,
you simply declare a virtual method getData().  This, of course, makes Item an
abstract class, but that's okay, because we actually define two subclasses:
Item400 and ItemSql.  Item400 defines the getRecord class using toolkit I/O, and
ItemSql defines it using SQL.  Both inherit all the other methods from Item.

Okay, now instead of simply calling "new Item()" to create a new item, we
execute

     Item item = Item.getItem();

The factory class getItem() determines which implementation we're on, and
returns either Item400 or ItemSql.  Then, when the application executes
item.getData(), the JVM determines which version of getData() to execute.

The beauty of this technique is that on, say, a non-AS/400 implementation, you
never instantiate an object of type Item400, so the toolbox routines never get
loaded!

Ah, the wonderful world of objects...

==================
Joe "Zappie" Pluta
www.zappie.net/java
"Where the AS/400 speaks Java... with an RPG accent"
==================


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@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
+---


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 copyright@midrange.com.

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