>I'm inviting Paul Vlad Tatavu to tell us a little more about his experinces in using Java as a front-end.

BTW, you can address a new message to someone in particular here on UT. This way, you can be sure that that person will see your message in his/her replies box.

>I've appended some posts he made last March.

Everything you quoted still stands.

>1) Was the Java UI that you developed used with VFP middleware or some other language?

No. VFP is involved only for dataconversions from many sources to an Access database. This Access database is converted after that to SQL-Server or Oracle, depending on the customer. The reason for having the source database in Access is... to support an older system which was not completely converted to something else. Anyway, the newer system can work with SQL-Server, Oracle or Access as a backend. This is done transparently for the developers through a set of data access COM objects (developed in VC++ with ATL and ADO). The Access database is also handy when weird tests are needed (it's very easy to modify data to match your testing needs) and when... all the servers are down and nobody knows why. Otherwise, none of our clients will use Access database. But it's also good for demos, when you don't want to install Oracle or SQL Server on the demo laptop.

So, the middleware is done almost 100% in VC++ with ATL and ADO (some VB COM objects, too, unfortunately:)).

Now, from Java UI/client point of view, it really doesn't matter which is the developemnt tool for the middleware or server side.

>2) What is your opinion of Java now?

The same. Java is an outstanding programming language. Excelent OOP features. Very easy to learn and use. Very easy to deploy too.

I still don't know any other better choice for serious web UI development. It may be good for middle tier or database access too, but I don't have experience with Java here.

>3) How does the form handling/presentation speed compare to VFP?

Just to be clear: I consider Java ONLY for web applications. For any other (standalone/desktop/LAN) type of app, choose any other developement tool.

About form speed in VFP: I think Jim Booth said it best: a well designed/developed VFP app will have forms that are fast enough for any user. These are not exactly his words, but... From my experience: Almost any slow VFP form can be modified to perform well even on average computers. I optimized some VFP forms (2 years ago) and obtained a performance increase of 23 times! Finally, it took about 1.5 seconds to load the slowest form. It's also true that, sometimes, due to poor database design, compatibility with legacy apps, etc, this may not be possible.

About Java forms: they are fast enough. You must always consider that the .class files must be downloaded from the server each time a new session is opened. But after they are on the client, the speed is very good.

In particular, for the app we developed: the longest load time is at the beginning (about 2 minutes on 28.8 connection). After the app is on screen, a new form is downloaded in 1-2 seconds, so, no big deal compared with HTML/DHTML solutions. The UI is not so fast as a VC++ UI, but it's comparable to a VB UI or VFP UI. (Obviously, I compare different apps, we had no time to develop the same thing in all these tools only for comparison sake.)

For the record: We used java.awt as base framework for UI. All controls in use are derived 1-3 levels from java.awt, but no java.awt class is used directly in the UI. This allowed a high code reuse and high polymorphic behavior (both are very important for the quantity of code that must be downloaded from the server).

It's also important to know that Netscape's Java Virtual Machine (VM) is much faster than IE's VM. There are also less bugs in Netscape's VM, but MS is improving its VM very fast and I'm quite happy with the last VM for IE4 (it comes with SP3 for VS6).

Things that I don't like in java.awt:
- The set of events is limited and, sometimes, there are no work arounds.
- Both NS and IE have problems with scrollbars (randomly).
- IE has big problems with mouse clicks. A fast user may be very annoyed by the fact that fast clicks (click while the mouse is still moving) are ignored.
- List controls in IE: The user must click on text. If the click is outside the text, the click is ignored.
- There is no editable combobox control. There are many third party combobox classes, but I couldn't find any good one. I had to develop my own editable combobox control, and... it's not perfect.
- There are no Tooltips.

From the experience we had with our clients, none of the above was a major issue considering the fact that the app can be used over the Internet and it looks like any other modern desktop app.

Vlad