You might keep some of the speed critical stuff in C++ and use a JNI
bridge.

Java's biggest problem with scientific is with complex.  It uses
separate memory objects for each pair -- very inefficient for matrix
work.  You can handle it with clumsy code with array pair or odd-even
doubles.

The big advantage of Java in that code that compiles tends to be bug
free.  With C++ you are just getting started at a clean compile.

Then he's an idiot.  Re-writing existing, working, code in another language --
/any/ other language -- is the kind of mug's game that can kill a company.

Now if you were proposing to use the data in a different /way/ then that might
be different.  But it doesn't sound like it from what you said in your post.

Nor can I see /any/ advantage in switching to Java.  It is unlikely that you'll
see a performance increase in your number crunching.  In fact I would guess
(but it is /only/ a guess) that you'll see a performance drop -- but then, that
might not be too important to you.  It is unlikely that you'll see an benefit
on the data-collection / database-population side either.  Java doesn't provide
any features for structuring such applications that don't exist in C++ too.
So, unless your existing code is a terrible mess, switching to Java won't gain
you anything much.

(And if it /is/ a terrible mess, then it might gain you a lot -- but only if
you can pursuade the programmers who made a pigs ear of it in the first place
to produce a silk purse the second time around.  Not too likely, in my opinion,
unless the reason for the mess is that the programmers didn't know how to use
C++ properly.)

   -- chris

Bad taste to reply to my own post but oh well.

Thanks for all the replies, lots of interesting points to think about.
I don't believe the new manager is an idiot.  He and I have had many
conversations on this subject and he is quite open minded- no
committment has been made to stick with any particular language.

The company I work for hasnt been around too long, about 7 years.  But
it was never a software company, and this is reflected in the design of
the code today.  And during the gradual downsizing of the company we
have lost pretty much _all_ of the original coders.  So the group we
have is pretty good (imho).

The good news?  The code all does what it is supposed to do.  We have
release software products that work and make our users happy.  So things
are right now at a functional state.

The bad news is that we have almost 7 years of legacy code around that
was written mostly by scientists, who as we all know have egos the size
of montana and have to first bash, and then rewrite, any piece of code
they get their hands on.  So we have tons of algorithms floating around
that have roughly the same function, but are application specific.
Because the egocentric putz who wrote it couldn't see past his own work
and how his algorithm might be, say, _portable_, or _encapsulated_ or
_documented_.

Bottom line?  We need rapid application development.  We cant get it
with all this legacy c++ code, duplicate algorithms, and reduced work
force.  Hence the incentive to find something better.

Happy to hear any thoughts!

Bryan