Translator tools?

[Gerry Murphy]

I was about to throw in the towel on this
project I've inherited. It's about 5,000
Java files, totally undocumented and uncommented.

I asked and looked for tools that would help
me make sense of this mess, so far to no avail.

Now the owner of the company is willing to
consider redoing it in C++. ( In my opinion
there was no good reason for the previous software
engineer to write this in Java. It's a pretty
straightforward Windows desktop app that would
be much easier to understand and maintain had
it been written in VC++. There's some evidence
he chose Java just so he could get some experience
with it,)

Anyhow, I'm not rewriting this by hand.
I came across the following in Bruce Eckel's
'Thinking In Java', "I've even heard it
suggested that you start with Java, to gain the
short development time, then use a tool and support
libraries to translate your code to C++, if
you need faster execution speed."


Has anybody heard of or better still used
such translator tools? Even if it only did
80-90% and the rest required manual intervention
it might work.

TIA for any advice.

Gerry Murphy

 

[Mike]

I was about to throw in the towel on this
project I've inherited. It's about 5,000
Java files, totally undocumented and uncommented.

I asked and looked for tools that would help
me make sense of this mess, so far to no avail.

Now the owner of the company is willing to
consider redoing it in C++. ( In my opinion
there was no good reason for the previous software
engineer to write this in Java. It's a pretty
straightforward Windows desktop app that would
be much easier to understand and maintain had
it been written in VC++. There's some evidence
he chose Java just so he could get some experience
with it,)

Anyhow, I'm not rewriting this by hand.
I came across the following in Bruce Eckel's
'Thinking In Java', "I've even heard it
suggested that you start with Java, to gain the
short development time, then use a tool and support
libraries to translate your code to C++, if
you need faster execution speed."


Has anybody heard of or better still used
such translator tools? Even if it only did
80-90% and the rest required manual intervention
it might work.

Once at the end of a project I had ~50,000 lines
of code that needed very specific documentation
by the contract. Instead of documenting the code
by hand, as my fellow developers in the project
did, I learned how to write compilers. At first
I was about two weeks behind them and then in one
afternoon all my code was documented without any
compiler syntax problems, etc.

My suggestion, write a compiler/translator to
change the code to what you want.

Mike

 

[Roedy Green]

It's a pretty
straightforward Windows desktop app that would
be much easier to understand and maintain had
it been written in VC++.

I would say, the opposite. Generally even badly written Java is
fairly easy to follow. Even well written C++ requires enormous coding
discipline to be readable.

Your problem may be unfamiliarity with Java. Perhaps you could solve
the problem by getting the code documented and cleaned up by someone
who knows Java.

Perhaps your predecessor took my essay on how to write unmaintainable
code to heart. You can do it is any language.

See http://mindprod.com/jgloss/unmain.html

 

[Roedy Green]

Has anybody heard of or better still used
such translator tools? E

God NO! If the code is an unreadable mess now it will be 5 times a
bigger mess after translation.

 

[Sudsy]

God NO! If the code is an unreadable mess now it will be 5 times a
bigger mess after translation.

I was about to say essentially the same thing but Roedy beat me to
the punch. Think about it: if the Java looks like spaghetti to you
now, how do you think it's going to look when translated into C++?
The NEXT person to come along will be calling for YOUR head on a
platter!

 

[Roedy Green]

I was about to throw in the towel on this
project I've inherited. It's about 5,000
Java files, totally undocumented and uncommented.

You want a navigator tool to help you get the sense of how the big
picture fits together.

You could try on of the more elaborate IDES such as IntelliJ or
Eclipse or SlickEdit or Juliet.

See http://mindprod.com/jgloss/ide.html
http://mindprod.com/jgloss/slickedit.html
http://mindprod.com/jgloss/juliet.html

Eventually you will have even better tools called SCIDs.
See http://mindprod.com/projects/scid.html

 

[Thomas Kellerer]

In my opinion there was no good reason for the previous software
engineer to write this in Java. It's a pretty straightforward Windows
desktop app that would be much easier to understand and maintain had it
been written in VC++.

Now, this surely is a wrong conclusion. A bad programmer will write
horrible code in both languages (and I tend to think that the code will
even be more horrible in C++, but then I'm a Java programmer )

A well written Java/Swing application is as easily understood as a well
written C++ program.

When it comes to documentation, javadoc is a very powerful tool that can
lead (if used at all, and used well) to a good documentation also.
I don't know if such a thing exists for C++

I would think that this application would be an absolute nightmare to
maintain if you automate the transition to C++ (as already mentioned) if
it's already a mess. Automatically generated code is *never* maintainable
by a human brain.

If I was you I would consider a complete re-engineering/re-coding using
your preferred language. I'm pretty sure that's the fastest thing you can do.

Just my 2 cents.

Thomas

 

[Gerry Murphy]

Hi,

I've found your site very useful. And I'm 99% sure
that the previous fellow read your unmaintainable code section.
I recognize several of the tips. I think this was unprofessional
on his part.

My unfamiliarity I readily admit. I've been studying it on
my own but this is my first chance to use it in the job.
I don't think the owner would go for hiring an outside party
to do as you suggest, and I don't have the authority to
do it myself. Ultimately, it's not my code.

Thanks for youe help.

Gerry Murphy

 

[Gerry Murphy]

The issue is that I understand C++ and have lots of tools
I've used over the years that would help me clean it up.

Thanks anyway.

Gerry Murphy

 

[Gerry Murphy]

I've tried a couple of things already, JavaDoc,
Doxygen with GraphWiz, JDepend, and I've
been trying to figure out NetBeans so I could at least
have an IDE. ( Not only is the code undocumented
and uncommented, they build it manually with Sun's
command line compiler, some antiquted build tools
and other compilers and a mind-numbing array of
batch files and makefiles. It's enough to make you weep.)
Can't get it to compile with NetBeans so far.

Another problem I'm having my be called 'tool-fatigue'.
I need to start making progress ASAP, not taking a
week or a month to figure out how to get a tool to work.
I will take a look at the ones you recommend however.

Thanks,

Gerry Murphy

 

[Gerry Murphy]

What you suggest is the only other option I'd consider,
but I don't think the owner would go for the time, money
and effort involved. If I don't show some progress it's
a tossup whether to walk away or wait a bit and get canned.

Thanks,

Gerry Murphy

 

[Liz]

I was about to throw in the towel on this
project I've inherited. It's about 5,000
Java files, totally undocumented and uncommented.

I asked and looked for tools that would help
me make sense of this mess, so far to no avail.

Now the owner of the company is willing to
consider redoing it in C++. ( In my opinion
there was no good reason for the previous software
engineer to write this in Java. It's a pretty
straightforward Windows desktop app that would
be much easier to understand and maintain had
it been written in VC++. There's some evidence
he chose Java just so he could get some experience
with it,)

Anyhow, I'm not rewriting this by hand.
I came across the following in Bruce Eckel's
'Thinking In Java', "I've even heard it
suggested that you start with Java, to gain the
short development time, then use a tool and support
libraries to translate your code to C++, if
you need faster execution speed."


Has anybody heard of or better still used
such translator tools? Even if it only did
80-90% and the rest required manual intervention
it might work.

TIA for any advice.

Gerry Murphy

Sounds like you are looking for an excuse to use the "GOTO" ;-)

Why not reverse engineer it from its behaviour and toss the java code.

 

[Sudsy]

What you suggest is the only other option I'd consider,
but I don't think the owner would go for the time, money
and effort involved. If I don't show some progress it's
a tossup whether to walk away or wait a bit and get canned.

I was going to ask some probing questions, but you've already been
candid in your replies. Would it be fair to suggest that the
situation is something like this?
- you don't have a lot of Java experience
- you've "inherited" a project which is a "rats nest"
- you'd like to convert the code to a language with which you're
more familiar
- you're facing unrealistic expectations and pressure from your
management

Welcome to the real world! Sorry if that doesn't sound particularly
supportive but it's a fair comment. I well recall the times I was
"dropped into it", typically at the 11th hour.
So look upon this as a personal and professional challenge! You'll
have a tough sell in the expectation management area but you seem
to already accept one of the possible outcomes (getting axed).
You're also heading in the right direction by trying to import the
project into an IDE. Try to provide concrete numbers to management
on a daily basis, something along the lines of "I've now got 60%
of the code imported and syntactically correct".
I don't know Netbeans but some people here swear by Eclipse,
particularly for refactoring code. I'm sure that there are also
tools available which can analyze the existing code for linkages
and dependencies but, having never had to do this kind of job
myself, will defer to the recommendations of others.
Just keep trying to move forward and explain that even the "best
of the best" wouldn't fare well faced with atrocious code.
Keep the chin up, try not to dump on the original author, and
maintain your integrity. That, as much as your programming prowess,
will help you through the most trying of times.

 

[Roedy Green]

I was about to say essentially the same thing but Roedy beat me to
the punch. Think about it: if the Java looks like spaghetti to you
now, how do you think it's going to look when translated into C++?
The NEXT person to come along will be calling for YOUR head on a
platter!

Does the code at least work?

If it works, likely you best bet is to get someone more familiar with
Java to document and clean it up for you. Then is suddenly may seem
more comprehensible. (Hint, I do this sort of thing on a contract
basis.). You need quite different sorts of docs for newbies and for
experienced programmers.

I got in to heck of a fight with a guy on a team once because he was
FURIOUS with me for documenting every method and parameter with
JavaDoc no matter how obvious it was. He prided himself on terse
code, and my JavaDoc blew up his line counts.

If the program seriously does not work, your best bet if you have to
maintain this, is just to extract a spec from the working program and
from crucial bits of the code, and redo it in the C++ you are familiar
with.

The docs most often missing are the "forest" docs. It is easy to
figure out how a method works, but much harder to see what it is FOR,
and how it fits into the big picture.

The most important docs are the "most obvious" docs to the coder --
what a class is FOR. To him the details are the complicated things.
To someone coming cold, details are easy to figure out. What's hard is
how the whole thing fits together. What is the overall flow.

In cleanup, you just whittle away, working on the most comprehensible
bits. It is a bit like a crossword puzzle. Every part you figure out
makes some more part clear.

You refactor and clean up code. This makes new levels of meaning shine
through.

 

[Liz]

Does the code at least work?

If it works, likely you best bet is to get someone more familiar with
Java to document and clean it up for you. Then is suddenly may seem
more comprehensible. (Hint, I do this sort of thing on a contract
basis.). You need quite different sorts of docs for newbies and for
experienced programmers.

I got in to heck of a fight with a guy on a team once because he was
FURIOUS with me for documenting every method and parameter with
JavaDoc no matter how obvious it was. He prided himself on terse
code, and my JavaDoc blew up his line counts.

Then he was not using a proper method of counting lines.

 

[Sudsy]

Liz wrote:
<snip everything>

You quoted, in its entirety, a response to a follow-up post and
then added a single line. Could we ask you again to please trim
your posts? All you need to quote is a paragraph or two, just to
provide some context. Pretty please?

 

[Liz]

sure no problem as long as i can top post

 

[Roedy Green]

Then he was not using a proper method of counting lines.

I offered to write a program to count lines not counting comments, but
his view as good code does not need comments, so comments should
count.

 

[Liz]

I offered to write a program to count lines not counting comments, but
his view as good code does not need comments, so comments should
count.

There are a couple of public tools that will do it.

jcsc and ncsl

 

[Thomas Weidenfeller]

I was about to throw in the towel on this
project I've inherited. It's about 5,000
Java files, totally undocumented and uncommented.

Well, we only hear your side of the story. In another posting you
confessed that you are a C++ guy (maybe Windows-only?). And you also
mentioned a beginner's textbook about Java. Could it be that it is not
only the previous programmer who is to blame, but that this system is
just beyond your area of competence? That you simply don't like it?

You also told us, that you didn't even manage to set up an IDE and get
the thing compiled. Which is, hmm, rather interesting, because Java's
class naming requirements (public class name must equal file name), and
the common way to lay out a package structure in a file system (each
package component becomes a directory) makes it fairly trivial to figure
out which files make up the source.

And since you also don't have a preprocessor, there are no nasty
surprises when compiling code, because there is no conditional
compilation (there is inlining of boolean constants, but this is normal
Java code).

Oh, and the reason why you tried to set up an IDE was that you didn't
like the current build system. Well, it was good enough for that one guy
you call incompetent. But you you can't handle it? Something just smells
fishy here.

I asked and looked for tools that would help
me make sense of this mess, so far to no avail.

I have my doubts that any tool in the world will help a Java beginner to
understand 5000 interacting Java classes. However, if you want to throw
money at it, you can waste money by buying such big cannons like
Rational Rose or any other tool which supports full round-trip
engineering. Then you pump the code through it (if you manage to find it
....), you get a class diagram and other funky things out of it, and
then? You will still scratch your head.

You could also have a look at eclipse and the many available plug-ins if
there is anything that suits your need, e.g. eclipse's refactoring tools.

Now the owner of the company is willing to
consider redoing it in C++.

Because you told him? The owner is best advised to first get a second
opinion from an experienced Java developer.

( In my opinion
there was no good reason for the previous software
engineer to write this in Java. It's a pretty
straightforward Windows desktop app that would
be much easier to understand and maintain had
it been written in VC++. There's some evidence
he chose Java just so he could get some experience
with it,)

No comment.

Has anybody heard of or better still used
such translator tools? Even if it only did
80-90% and the rest required manual intervention
it might work.

I think you are naive to believe that such a translation would help you.
The most common thing between Java and C++ is the syntax. Java's class
library (usually heavily used in any Java application), and Java's
garbage collection are fundamentally different from what you have in
C++. As a consequence, a Java program is most likely structured very
differently from a C++ program.

And, in case the Java code is really FUBAR, how could such a translation
fix these problems? Garbage in, garbage out.

TIA for any advice.

I don't think you want to thank me after this posting.

/Thomas