Hi, Frank.
>I am writing an application in VFP9 that needs to interface with a utility provided by another company. This utility was written in Java. They were concerned that VFP would not be able to interface with it.
>
>They have said:
>
>"We don't currently have an ActiveX, .NET, or .dll interface. We're really living in a Java world. I'm not sure where to point you -- you might be able to find a bridge or way of interfacing thing on the web."

Well, you have several approaches, and you have to pick the one that better fits your and the other vendor situation:

- The simplest way could be the old file-exchanging method. If the interaction is about exchanging small data chunks, this could be a possible way. An extension of that could be sharing a database.

- You can use Intrinsyc's Ja.NET to create .NET Remoting proxies around their Java components. Then you can make this call VFP COM components at your side. This is a bit convoluted, but it is the way that could give you the best performance if this is a need.

- You can use Web Services, as Colin and others said. Of course, the vendor should provide a Web Service for you to call, and you another one for them to call, as needed. This shouldn't be difficult for them, and it is really simple to do it from VFP. If you need some examples, tell me and I'll point you to some how-to articles. And, yes, WS could be deployed and consumed locally, without no connection to the net.

- There is a last possibility that could be even better performance-wise than the .NET Remoting one, but it is quite complex because it involves using c++ to make a callable COM Server from Java that you can also call from VFP. It can be done, but it's not for the faint of heart, believe me. 8-)

Somebody already did much of this job, and you can find it here:
http://jawinproject.sourceforge.net/

Let me know if you need more information.

Best luck,