🚀 go-pugleaf

Owen,
That would actually be fine with me and sounds like a reasonable solution.
However, one of our directors has decided that Java is "the Holy Grail" of
programming and that it will replace every other tool we use from mainframe
Cobol to C++ to Delphi and VB.  His position is that desktop apps are a
waste of resources and that traditional client/server technologies have
failed (our group's main application is somewhat of an embarrassment to him
since it is very successful).

This has left us caught in the middle between our management's stated
strategic direction and our customers' demand for functionality they have
specifically requested and require to do their jobs.  If I'm going to make
this work, I'm going to eventually have to find a way to make Java do what
Delphi makes so easy -- i.e., leverage the functionality of the office suite
and other parts of Windows.  All of our customers have standardized on
Windows and Office and have no intention of moving to anything else.

Thanks to Torsten too.  I'll check out the resources you mention.

Ray

"Owen Green" <owen@norobots.unique.com> wrote in message
news:3adc0572_1@dnews...
> Would there be any merit in keeping the desktop apps in Delphi, so that
you
> can do all the API stuff, and have them talk to the server by CORBA, or
the
> EJB-COM bridge, or (even) TCP?
>
> Owen
>
> > In their infinite wisdom, our management has decreed that all
applications
> > (everything from mainframe CICS to little desktop apps) must be
converted
> to
> > Java, with Oracle as the backend database if a db is needed.  We have
> > several fairly major client/server and desktop applications (currently
in
> > Delphi) that interact directly with the Windows api and the office suite
> of
> > tools.  These are functions that our customers have requested and
require
> > (for example, exports of query results to local MS Access databases or
to
> > Excel and Word, etc).  Is there a way to duplicate this functionality in
> > Java?  Can Java automate Windows applications?  The preferred
methodology
> > here is Java servlets and JSP which I think leaves us with even less
> ability
> > to interact with the local operating system.
> >
>
>
>
>