>We are thinking of a long term scenario which is INTERNET apps. Monolithic and C/S apps are still profitable at least on our case.
>
>The thing is, if you're good in C++, JAVA is no longer hard to learn because it is the simplified and enhanced version of C++.

I don't think you have the lineage of the languages, or much familiarity with their strengths, to make this assertion. Java accomplishes much of its cross-compatibility through the use of a virtual Java machine which abstracts the hardware. The instant you exploit hardware or software environment-specific behaviors with Java, kiss cross-compatibility goodbye.

The basis of inheritance and behavior for the two languages is quite dissimilar. You're welcome to believe otherwise.

It sounds more like you've made a decision and want someone to come along and pat you on the head and say, "Good girl, you did the right thing". I'm afraid that, in a vacuum, where I don't know what the issues are, it's impossible to give you any degree of reassurance. I can asure you that if you wish to exploit Java's portability out of the Wintel environment, kiss VFP goodbye, since VFP's native interfaces are most easily accessed across a Wintel product boundary via COM at the moment at least.

I've already invested heavily in C/C++, so from your POV, I'm probably not an unbiased judge on the matter. C++, specifically VC++ with ATL or MFC, fits my requirements for low-level technology implementations, and data structure- and raw performance- oriented requirements in the Wintel architecture. When I develop with VC++ and these technologies, I've already committed to the Wintel architecture, so I don't give a hoot whether the code is going to run on Linux. I use so many tools in the Wintel environment that rely on VB or VB-derived syntax that I'd be a fool not to have invested my time learning how to use it. I did enough with Java to know what it did and did not do, what compromises I'd have to make to fit it into my development environment, and came away saying "So what?" But I did learn enough so that JScript is a strong option for me developing ASP and WSH scripts, and I know when I can make convincing arguments for and against its use.

One thing I have learned is that there's enough business for me in the area that I don't go chasing projects that need a toolset or platform I'm not competent to use properly. I can point to a number of projects where I've gone in, spent some time, and in the end, told the customer "It's a great project, but I'm not the guy who should be doing this..." It's at least as important to know what the competition is and where they're better at solving the customer's problem. The idea is to serve the customer well - they're more likely to come back and ask you again, and seriously consider your proposal - giving then an honest appraisal of both their needs and your capabilities pays better than a project that misses time, budget and end-user requirements. You may get this project (until they fire you if it goes badly awry) but it's certain you won't get a shot at the next one.

And in a number of cases, I've been brought in to help look at the project's progress, or help with the design at least to the point where implementation-specific issues become the focus of what's being done.