Java Platform, Enterprise Edition

Java EE Journal

Subscribe to Java EE Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Java EE Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

J2EE Journal Authors: Jeremy Geelan, Zakia Bouachraoui, Douglas Lyon, Stackify Blog, APM Blog

Related Topics: Java EE Journal

J2EE Journal: Article

Enterprise FoxPro and the .NET Revolution

A "sly" need for change

We've both been in the database business since the earliest days of the personal computer. There was a time when the only game in town was dBASE from Ashton-Tate. In 1985, little Fox Software, operating out of a former grocery store in Toledo, Ohio, built a far superior code-compatible product called FoxBASE, and sold its second-generation product, FoxPro, to Microsoft in 1990. It looked like FoxPro was here to stay.

Within a year, rumors were flying that Microsoft had other plans for database development. Some thought it would be Access, but a little experimentation demonstrated clearly that Access was more of a power user's tool. Visual Basic was easy but flawed. C and then C++ was powerful, but very difficult to master and use.

Finally, .NET arrived, and we all got the message. Microsoft had developed a sort of "software abstraction layer" that would support developers working in almost any language. Any language, that is, except FoxPro. Not only did Microsoft exclude FoxPro from the .NET languages; they stopped advertising it, or even mentioning it in their famous database seminars. We're sure that they have their reasons, but the fact remains: FoxPro shops need to start looking at their alternatives.

As former FoxPro developers, we welcomed the opportunity to show that FoxPro could be the best choice for development even in a huge multinational environment. Specifications in hand, we compared each alternative for cost of development (usually the time required to build the application) and the speed of execution of the final product, based on our own in-house experiments. FoxPro usually won. But the decision to move to something else was not technically motivated. The word came down from above: this was going to happen.

To .NET or Not to .NET?
The first platform that came to mind was not .NET but Java. Since we already had large mainframes for our Oracle database, UNIX had made its way into our world. Training, hardware costs, scalability, development time, vendor durability, and choice of programming language were the issues that we considered.

The first issue was the amount of training required for various .NET languages versus Java. Although undoubtedly more difficult to learn than FoxPro, Visual Basic .NET has tons of available examples, including the 101 sample applications for VB .NET available for download from the MSDN site. Even though some Visual Basic 6 developers are dismayed over the learning curve for VB .NET, Java development requires considerable advance planning and design; we spent nearly a year before we were in a position to write the first line of code. That's not practical for most of our requirements, which often require rapid response.

Visual FoxPro 8.0 has about 2,000 commands and functions; the various assemblies in Visual Studio 2003 contain at last count over 130,000 properties, events, and methods. Whidbey reportedly more than doubles that count. Getting new developers up to speed is a never-ending challenge, and the cost is nontrivial.

But more importantly, Java is undoubtedly harder to learn. A two-week .NET course gets most developers up and running; the Java training we use at our company is a three-month course. If it could be done in two weeks, we'd do it, but it's out of the question. There's just a whole lot more to know before you can greet the world in Java.

The question of scalability arose regardless of the choice of development language. Windows servers can support around 250 users, which means that clustering is required for firms of the size of MAPFRE. We opted for an Oracle server running on an IBM mainframe, and have been very satisfied with scalability. FoxPro has served us very well as a UI development environment for the Oracle back end. But with both UNIX and Windows computers in our shop, we seriously considered both J2EE and .NET.

The scalability model for .NET is based on Intel processors and the Windows operating system, using clusters of servers to increase what has come to be called horizontal scalability. UNIX solutions use RISC processors in parallel and massive amounts of memory, offering greater vertical scalability. This is not entirely black and white, however; Linux systems with Intel processors can offer horizontal scalability with J2EE, and 64-bit Windows processors with multiple processors can offer impressive vertical stability. However, these are unusual ad hoc configurations and don't represent the normal implementations. So the real question is whether you want horizontal or vertical scalability, and the answer to that question gives you the operative answer of choice of platform.

Hardware Costs
Acquisition costs are usually higher for UNIX/RISC platforms. Maintenance costs, however, can be lower in a UNIX environment. Expansion is generally cheaper with a Wintel cluster, since you simply add another box to the cluster. When you hit the ceiling on a UNIX computer, you move out the old box and move in the new box. Transactions costs are roughly comparable for the two platforms according to most studies.

Development Costs
Development costs are higher in the Java world for two reasons. First, Java generally requires more lines of code to produce a given result.

A large part of the higher cost of Java is the requirement that software be well planned before it's executed. We know that the theory is that you "measure twice, cut once," or as some say, you can plan for a week and code for a day or plan for a day and code for a week. But Java requires that you make many design decisions that affect every single aspect of coding. It's expensive to change courses down the road. .NET is more forgiving of the real-world process of discovery that happens in most projects. (Visual Basic .NET is less sensitive, especially to design refactoring.) .NET means having to say you're sorry less often.

Vendor Durability
Another issue is the strength of the vendor. At some point, Java shops have to make the decision between BEA and IBM. Cost favors the former, while survivability is on the side of the latter. Microsoft is the richest corporation on Earth, and shows no signs of slowing down. If you want to avoid the cost of possibly switching vendors, .NET is the only game in town.

So there appear to be lots of good reasons for going with .NET, from both the hardware and the software point of view. So will it be C# or VB .NET? Earlier versions of Visual Basic earned (and in some ways deserved) a bad rap for a lack of object orientation that fostered bad programming habits in a generation of programmers. Visual Basic .NET is, however, a complete rewrite of the language and produces exactly the same Intermediate Language code as does C#. It's easier to learn, especially for FoxPro developers. (That's the reason one of us devoted a recent book, published by Sams, to migrating from Visual FoxPro to Visual Basic .NET rather than to C#.) The VB .NET IDE is slightly more productive, and seems to be gaining in programmer-friendly features compared to its siblings.

And it should not be forgotten that .NET is a software abstraction layer that goes between the application and the operating system. That means that a .NET framework for Linux (whether named Mono or MSLinux), and perhaps even a MacDotNet, is inevitable. So even the vaunted portability of Java to any destination is not a monopoly in the long term. Platform independence will someday be another benefit of using .NET.

On balance, for those FoxPro shops contemplating changing horses, .NET, and in particular Visual Basic .NET, appears to be the most appealing destination. It would be nice to be able to stick with what has been a faithful companion for so many years, but apparently all good things must end. For shops that have used FoxPro, Visual Basic .NET has our vote as the choice of minimum regret. But even so, nothing runs like a Fox.

More Stories By Pablo Almunia

Pablo Almunia is the director of development for MAPFRE, one of the largest insurance companies in the world.

Comments (6)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.