Java and Spring questions

[Bryan]

Hi,

I work for a company where we have several years of code for scientific
applications written in c++. Most applications do some fairly hardcore
calculations, and most of them also communicate with a database.

The model is pretty simple: The data is acquired from scientific
hardware (mass spec), lightly processed and then stored in the database.
It is retrieved for proprietary and intense analysis later with our
apps (which I write).

A new R&D manager has come in and wants to re-architect all of our
existing and difficult to manage code. He has a consulting company
(very well known, six sigma and all that) who is proposing to use Java
and Spring for this rearchitecture.

I know java, but none of us here are experts- all being from the c++ mfc
world. Not that that really matters, we program in whatever is the best
language for the job, but we are behind on knowledge of java's place in
the scientific application world.

Can anyone shed some light on whether java/spring is a reasonable
replacement for c++ in this paradigm? As well as learning how to use
spring, etc.

Im just looking for any insights from anyone who has any experience with
any of this stuff.

Thanks,
Bryan

 

[Roedy Green]

Can anyone shed some light on whether java/spring is a reasonable
replacement for c++ in this paradigm? As well as learning how to use
spring, etc.

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.

 

[Chris Uppal]

A new R&D manager has come in and wants to re-architect all of our
existing and difficult to manage code. He has a consulting company
(very well known, six sigma and all that) who is proposing to use Java
and Spring for this rearchitecture.

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

 

[suckingfish]

I did programming with both C++ and Java, and I also use
Spring 1.2 in my latest project.

I agree with the previous two posters that moving from C++
to Java is not going to gain you too much especially in the
performance arena. A person can write bad code in Java
as easily as in C++. It's a big move and you really have
to do your homework on that.

Spring is just an application framework, not a magic bullet.
The advantage of using frameworks like Spring and Hibernate
is that some of the plumbings are taken care for you, and hopefully
the only thing left is the business logic. You get a solid
structure to build your application from, and less code to write
on your own so I guess that will reduce the chance of writing
bad ones. Spring is also very lightweight, and cannot be
compared to MFC by any stretch of imagination.

Good luck,

Matt

 

[Patrick May]

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.

Shenanigans! I call shenanigans!

Patrick

 

[Scott Ellsworth]

Then he's an idiot. Re-writing existing, working, code in another language

It can, but it can also let you rearchitect in a way that scales. Or
that works. Or that can be maintained. The OP _did_ say that the code
is difficult to manage.

Ofttimes, the existing, working, code doesn't really, it just works
barely well enough. In this case, though, the big points come from
identifying just what it does and does not do, and how that relates to
the core business objectives. Once you have that, you can make a decent
decision about rewrite vs improve.

[...]

So, unless your existing code is a terrible mess, switching to Java won't
gain you anything much.

That was what I understood from the OP.

(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.)

Well, one thing you _can_ do is bring in a leavening of people who do
understand good architecture and design, and have then approve, review,
and work with the code from the current group as it is being designed
and created. We have had that role off and on, and it usually works
well, if the company recognizes what is wrong with their current design.

Where we have seen problems is when the company does not see a problem
with spaghetti code, or with a total lack of decent encapsulation, and
is hoping that sprinkling java pixie dust over it will make it all
better somehow.

Scott

 

[Roedy Green]

Where we have seen problems is when the company does not see a problem
with spaghetti code, or with a total lack of decent encapsulation, and
is hoping that sprinkling java pixie dust over it will make it all
better somehow.

The big thing is having a look for more encapsulating opportunities.
If you simply translate the code as if it were C you will be right
back where you started.

This often means bringing functionality back from the clients into the
class itself, even for one-use stuff.

This might be a great time to read up on refactoring. See
http://mindprod.com/jgloss/refactoring.html

 

[Chris Uppal]

Where we have seen problems is when the company does not see a problem
with spaghetti code, or with a total lack of decent encapsulation, and
is hoping that sprinkling java pixie dust over it will make it all
better somehow.

That is essentially the way that I interpreted the OP -- although not with the
assumption that the existing code /is/ in a complete mess.

Especially since he mentioned that:

[the] new R&D manager [...] has a consulting company (very
well known, six sigma and all that)

My faith in consultants is perhaps not so complete as the consulting industry
would prefer ;-)

-- chris

 

[Chris Uppal]

Shenanigans! I call shenanigans!

I know the word, but I've never heard the expression "I call shenanigans"
before, where does it come from, what does it mean ?

(I'm assuming that someone called Patrick would necessarily be an authority on
this ;-)

-- chris

 

[Scott Ellsworth]

Where we have seen problems is when the company does not see a problem
with spaghetti code, or with a total lack of decent encapsulation, and
is hoping that sprinkling java pixie dust over it will make it all
better somehow.

That is essentially the way that I interpreted the OP -- although not with the
assumption that the existing code /is/ in a complete mess.

Especially since he mentioned that:

[the] new R&D manager [...] has a consulting company (very
well known, six sigma and all that)

My faith in consultants is perhaps not so complete as the consulting industry
would prefer ;-)

I quite understand. We have had a lot of gigs where our work was
essentially cleaning up after a previous group of consultants.

It is tough enough to do a good job when the full time staff is worried,
overworked, or resentful. If they are also still smarting from a group
of idiots full of general platitudes, sprinkled with bad advice, it
multiplies the difficulty enormously.

A good question, I suppose, is whether the clients of the consulting
group invited the consultant back. We have had a few individuals that
brought us in several times at several different companies, and a few
long term clients who terminated us when one project ended, then brought
us in months or years later when a new project started.

Still, testimonials always need to be taken with a grain of salt, and
even more so when the hired help is temporary. (So, IMO, do
credentials, and claims of past excellence. I must be a suspicious
sort.)

Scott

 

[Patrick May]

I know the word, but I've never heard the expression "I call
shenanigans" before, where does it come from, what does it mean ?

It's from South Park. I was trying to be more polite than saying
"What a load of bollocks."

Regards,

Patrick

 

[Roedy Green]

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.

If you think that is nonsense, perhaps I should teach you how I write
Java or you should teach me how you write C++.

 

[Andrew McDonagh]

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.

Knowing both languages, thats just complete rubbish, complete and utter
nonsense.

....and people actually use your site for info...

 

[Chris Uppal]

I quite understand. We have had a lot of gigs where our work was
essentially cleaning up after a previous group of consultants.

Then not only must you be quite competent yourselves, but your sales
departement must be /absolutely stellar/ ;-)

Returning to the OP's problem. It occurs to me that if the new director
/isn't/ an idiot, then the whole lets-rewrite-everything-in-java thing may be a
ploy to, um, eliminate the sources of bad code. Either way (idiot or
Machiavelli) it seems like a good idea to ensure that the CV is up to date.
Now there's a cheerful thought for Christmas...

-- chris

 

[Roedy Green]

Knowing both languages, thats just complete rubbish, complete and utter
nonsense.

...and people actually use your site for info...

If we have a different experience, it might be because we code in
different ways. One factor to consider is that early in my career I
got one run per day with punch cards, and it took about perhaps half
an hour to fix a single typo with paper tape.

 

[Nicros]

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

 

[szewong]

One thing I can share is that we recently finished a big scale
financial application in MS-Access (with good reason. I can share if
anyone cares). Now the client wants to make it enterprise-level. So the
best choice seem to be Java/J2EE and basically rewrite the Access app
in J2EE.

Well, the probelm is kind-of similar to your's Bryan that the finanical
processing is complex and took us a lot of engergy and a lot of reviews
to get all the accountants happy. Rewriting that sound scary.

So, what we will start doing in 2006 is to start putting together a new
web-based front-end in Spring. Any new features will be implemented as
Spring Beans but the original Access stay (!) Yes, we are going to have
a J2EE app interfacing with an Access app as a service. That may sound
crazy in technical term but it makes perfect sense in business term.
Not until the J2EE side of the app starts stablizing will we start
rewriting the Access part.

This approach makes the business people happy, and the IT people
hopeful (eventually we will be in J2EE).

Sze
http://www.zerionconsulting.com

 

[Patrick May]

One thing I can share is that we recently finished a big scale
financial application in MS-Access (with good reason. I can share if
anyone cares). Now the client wants to make it enterprise-level. So
the best choice seem to be Java/J2EE and basically rewrite the
Access app in J2EE.

What lead you to the conclusion that the best choice is J2EE? It
may well be, but you could benefit from considering other
alternatives. If you're using "J2EE" to mean JSP and servlets to
create the user interface, you'll probably be fine. If you intend to
use EJBs and other complex components of J2EE, you may find that you
spend more time struggling with your tools than solving your problem.
Spring will help manage some of that complexity.

One technology I've used successfully to build enterprise systems
is Jini (http://www.jini.org). Depending on the complexity of your
system, you may also want to look at Ruby on Rails. Both offer
advantages over J2EE application servers.

Well, the probelm is kind-of similar to your's Bryan that the
finanical processing is complex and took us a lot of engergy and a
lot of reviews to get all the accountants happy. Rewriting that
sound scary.

You definitely don't want to rewrite unless absolutely
necessary; you want to leverge your existing investment. A
service-oriented architecture, perhaps exposing your business
functionality as Web Services externally and Jini services internally,
is something to consider.

Good luck,

Patrick