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



Nathan wrote:

> That sounds a little hard to believe.  I've heard that
> different JVMs handle
> threads and synchronization differently, and render Swing classes
> differently, for example  Do you use middleware that behaves
> differently on
> different platforms?  What about the use of stored procedures, or code
> that's based on the User profile, or system security
> settings?  What about
> specific code for specific printers, file systems, and such?
> What about
> integrating your application with existing applications on the server?

Great questions all... what you are discussing is exactly where the
cross-platform strength of Java excels!  Yes, different JVMs handle these
things differently  because (and I'm not trying to be smart here)... they
ARE different!  The point is that the JVM handles it and NOT the programmer.


Take the Swing classes you mentioned.  A Window in Windows and a Window in
Mac/OS do not look the same.  As a Windows User I expect the window to look
a certain way, a Mac user expectes it to look the way their other windows
look, so it only makes sense that in Swing I create a window and the JVM
says... "Oh, it needs to look like this" and renders it properly.  The point
is that they should be different.  You can get a lot more picky if you like
because Swing will allow you to set a specific look and feel, but that is
really a different subject.

Good points about interacting with the server.  Most of this doesn't really
apply to my software, so I haven't given it too much thought.  I'm also
still very early in the development cycle and I have a lot left to learn so
I'm sorry if I don't know good answers to all your questions.  Some of the
stuff is built into Java, such as the File system questions (again thanks to
the JVM), and I think Stored procedures are the pervue of the database, not
the application (although I might be wrong).

I do know that there are a host of additional packages like JNI (Java Native
Interface), RMI (Remote Method Invocation), and others that are intended to
answer these issues, but I haven't learned enough yet - like that's possible
anyway! :-)

I'd also like to point out that I'm not suggesting in any way that this is
going to be easy or that it is the solution to every problem, it just seems
to offer the most hope for our little company to grow into something bigger
utilizing our available resources.

> Have you tested your code on multiple platforms?  Is it
> practical to test
> your application on multiple platforms?  Is there a good
> chance that you
> will settle on one platform, in the future?

I have the same packages installed and being used on the 400, Windows 2000,
XP, NT, and 98.  On the Windows machines those packages are used by a Swing
application.  On the 400 they are being used by a web application.  I think
this illustrates Joe's point about seperating the UI from the business
logic.  I may need to write a different UI depending on the circumstance,
but the business logic and database access don't need to be touched.  And if
the 400 supported a non-browser GUI I wouldn't even need to do that!

Will I settle on one platform?  Not intentionally, but I will concede that
with so much of the market share in Windows I anticipate a lot of our
business going in that direction.


Joel R. Cochran
Director of Internet Services
VamaNet.com
(800)480-8810
mailto:webmaster@vamanet.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.