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






1. I liked your java site a lot, even used some of the stuff.

Thanks.  Hopefully you'll have even more to use soon.  I've got to get Alex
Garrison's latest utility up there, hopefully tomorrow night, along with the
SPLF2PDF utility Don Denoncourt and I co-authored.



2. In my opinion, however, we do need to build classes with portability
in mind which means less usage of the tool box since the tool box
classes are as400 specific.

Ah, now THIS is an area where I tend to disagree, and I'd love to get some
dialogue started (IS EVERYBODY LISTENING??).
To me, portability is far more important for client-side code than for
server-side, and here's why:

In this brave new world of distributed computing, especially with the Internet,
I have no idea what kind of client will be accessing my server.  Therefore, my
client-side code has to be as platform independent as possible.  Similarly, even
my local LAN (or intranet) may have many different kinds of clients.  In either
case, WORA is the goal.

However, as the developer, I DO have control over what environment my
server-side code is running on.  Unless I am trying to SELL my server code to a
multi-platform environment, I should be free to use any extensions and packages
that make my server run better, faster and smarter.  The truth is that I do NOT
intend on trading my AS/400 in for a Windows/NT network anytime soon, so using
the toolbox for performance reasons is actually a GOOD business decision.

All that said, I still think we need to encapsulate the toolbox within our own
classes so that when the time DOES come to move to a new server, we can replace
the AS/400-specific code with whatever we need.  To that end, I am playing with
making my JDB/400 classes optionally support a JDBC interface.  How's THAT for a
weird twist?  Use an object-oriented language to emulate SETLL and READE via SQL
calls.  Why?  Because I know that native DB2/400 calls are a lot faster than
those for JDBC.  So, if my classes ARE running on an AS/400, they can be
switched to take advantage of the AS/400.

Well, I should get off my soapbox for now.  Comments and criticisms are of
course encouraged.




3. I myself would volunteer to do some rpg-java code comparisions if
needed.

What exactly do you mean by this, Shahar?



4. Keep up the good job

Thanks!  Of course, it's alot easier to keep doing this when I get feedback ...


+---
| 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 [javascript protected email address].

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