«

I'm looking for a utility program that will convert C++ to Java.

I have already searched this group on the topic, but most of the posts
are quite old. I'm wondering if there is more up-to-date info.

I saw one previous post suggesting C2J. I'm going to give that a try,
but based on that thread it looks like the results from C2J may not be
all that useful.

Also, I did read all the advice explaining that a C++ to Java utility
is a bad idea. I am in agreement. But here is my situation:

I work on a tool, written in java, that monitors and displays messages
exchanged between two C++ programs. The number of messages is growing
quite fast, and even the definition for existing messages changes
quite often. Currently I am converting these message definitions by
hand from the original C++ source to java, but I am rapidly becoming
unable to keep up with the changes.

Also, the only things I really need to convert automatically are
header files, and those header files have either:
- a struct that defines the fields in a message
- a enum that specifies the possible values for a field in a message

So I am not trying to convert whole programs...just some fairly simple
type definitions.

Automation would help alot. I'll write my own tool if I need to, but
why re-invent the wheel if I don't need to?

Any advice is appreciated.

>
> Also, the only things I really need to convert automatically are
> header files, and those header files have either:
> - a struct that defines the fields in a message
> - a enum that specifies the possible values for a field in a message
>
> So I am not trying to convert whole programs...just some fairly simple
> type definitions.
>
> Automation would help alot. I'll write my own tool if I need to, but
> why re-invent the wheel if I don't need to?
>

If it's just typedefs and header files, might it be possible to
establish a fixed set of conversion rules (but still flexible enough
to add new ones or tweak old ones) and write a Perl or Ruby script to
do this? That's probably the road I'd take.

On Jan 15, 12:08*pm, Ron <bnor...@gmail.com> wrote:
> I'm looking for a utility program that will convert C++ to Java.
>
> I have already searched this group on the topic, but most of the posts
> are quite old. *I'm wondering if there is more up-to-date info.
>
> I saw one previous post suggesting C2J. *I'm going to give that a try,
> but based on that thread it looks like the results from C2J may not be
> all that useful.
>
> Also, I did read all the advice explaining that a C++ to Java utility
> is a bad idea. *I am in agreement. *But here is my situation:
>
> I work on a tool, written in java, that monitors and displays messages
> exchanged between two C++ programs. *The number of messages is growing
> quite fast, and even the definition for existing messages changes
> quite often. *Currently I am converting these message definitions by
> hand from the original C++ source to java, but I am rapidly becoming
> unable to keep up with the changes.
>
> Also, the only things I really need to convert automatically are
> header files, and those header files have either:
> - a struct that defines the fields in a message
> - a enum that specifies the possible values for a field in a message
>
> So I am not trying to convert whole programs...just some fairly simple
> type definitions.
>
> Automation would help alot. *I'll write my own tool if I need to, but
> why re-invent the wheel if I don't need to?
>
> Any advice is appreciated.

I tried C2J, but I'm pretty sure it is not the tool for this job. It
would seem that you need an entire, compilable C project; there is no
single file conversion. And it also seems like you need to add files
to a C2J workspace one at a time (the project I'm trying to convert
has hundreds of files). And it crashes alot. And it won't take .cpp
files...only .c files. Maybe someone out there has looked deeper than
I have, and has discovered other ways to get C2J to convert files.
I'd be interested in knowing if I misunderstood something about how
C2J works.

Ron wrote:
....
> Also, the only things I really need to convert automatically are
> header files, and those header files have either:
> - a struct that defines the fields in a message
> - a enum that specifies the possible values for a field in a message
>
> So I am not trying to convert whole programs...just some fairly simple
> type definitions.
....

Do you have influence over the C++ part of the project? If so, I suggest
the following:

1. Define a language for the logical structure of the messages files,
and maintain the files in that language.

2. Write a program that converts from the logical messages language to
C++ header file.

3. Write a program that converts from the logical messages language to
Java, or write Java code to read and interpret the logical messages
language.

This avoids a major risk of your current plan. Suppose you find or
create something that converts from some subset of C++ to Java. Some
time in the future, a C++ developer might use, in the header file, some
valid C++ structure that is not supported by your conversion utility. If
you are lucky, the incompatibility will be detected during the build. If
not, you may have a tough debug job on your hands.

Patricia

On Jan 15, 12:20*pm, Lord Zoltar <lord.zol...@gmail.com> wrote:
> > Also, the only things I really need to convert automatically are
> > header files, and those header files have either:
> > - a struct that defines the fields in a message
> > - a enum that specifies the possible values for a field in a message
>
> > So I am not trying to convert whole programs...just some fairly simple
> > type definitions.
>
> > Automation would help alot. *I'll write my own tool if I need to, but
> > why re-invent the wheel if I don't need to?
>
> If it's just typedefs and header files, might it be possible to
> establish a fixed set of conversion rules (but still flexible enough
> to add new ones or tweak old ones) and write a Perl or Ruby script to
> do this? That's probably the road I'd take.

I agree. And I should probably just bite the bullet and do it. I
just wanted to check if anything was already available before doing
that work.

Also, I confess I've never written anything in Perl or Ruby. In your
opinion, do you think it would be more efficient for me to learn one
of those and use it for the converter. Would either of those be
significantly better than just writing the converter in java?

Ron <> writes:
>Currently I am converting these message definitions by
>hand from the original C++ source to java, but I am rapidly becoming
>unable to keep up with the changes.

I would write a generator to generate both the C++ and the
Java source code (only the message definitions).

Better, but possibly more effort:

Both programs read the message definitions at run-time,,
so it will not be necessary anymore to change the source
code, when a message definition has to be changed.

On Jan 15, 12:34*pm, Patricia Shanahan <p...@acm.org> wrote:
> Ron wrote:
>
> ...> Also, the only things I really need to convert automatically are
> > header files, and those header files have either:
> > - a struct that defines the fields in a message
> > - a enum that specifies the possible values for a field in a message
>
> > So I am not trying to convert whole programs...just some fairly simple
> > type definitions.
>
> ...
>
> Do you have influence over the C++ part of the project? If so, I suggest
> the following:
>
> 1. Define a language for the logical structure of the messages files,
> and maintain the files in that language.
>
> 2. Write a program that converts from the logical messages language to
> C++ header file.
>
> 3. Write a program that converts from the logical messages language to
> Java, or write Java code to read and interpret the logical messages
> language.
>
> This avoids a major risk of your current plan. Suppose you find or
> create something that converts from some subset of C++ to Java. Some
> time in the future, a C++ developer might use, in the header file, some
> valid C++ structure that is not supported by your conversion utility. If
> you are lucky, the incompatibility will be detected during the build. If
> not, you may have a tough debug job on your hands.
>
> Patricia

Agreed, that would be better for the work I am doing. Unfortunately I
don't have any influence over the C++ part.

On Jan 15, 12:41*pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Ron <bnor...@gmail.com> writes:
> >Currently I am converting these message definitions by
> >hand from the original C++ source to java, but I am rapidly becoming
> >unable to keep up with the changes.
>
> * I would write a generator to generate both the C++ and the
> * Java source code (only the message definitions).
>
> * Better, but possibly more effort:
>
> * Both programs read the message definitions at run-time,,
> * so it will not be necessary anymore to change the source
> * code, when a message definition has to be changed.

That is a good idea, but not possible in my situation. I have no
influence over the C++ development. Also, they are writing DSP code
that has no filesystem access. So the language independent
definitions would need to get pulled into their build product at
compile time. I think it is more work than I can take on to make that
happen. It might not even be possible, given their development
environment. Even if I could, I think I would have trouble getting
the C++ project managers to accept that change anyway.

Something I didn't mention before: the C++ code is generated by a 3rd
party design tool. Thus the source I'm trying to translate has very
standard formatting and syntax. It should be acceptably future-proof
for me to treat this as my "logical language" for message definitions.

Also, I just want the conversion grunt-work to be automated, but not
the whole process. I will monitor churn to existing message
defintions, so I should be able to catch any changes that cause the
automated conversion to produce undesirable results.

>
> I agree. *And I should probably just bite the bullet and do it. *I
> just wanted to check if anything was already available before doing
> that work.
>
> Also, I confess I've never written anything in Perl or Ruby. *In your
> opinion, do you think it would be more efficient for me to learn one
> of those and use it for the converter. *Would either of those be
> significantly better than just writing the converter in java?

If you're not familiar with Perl or Ruby, then it might be best to
write the converter in Java, seeing as you know it and are familiar
with it. It would probably be fastest to get the job done in Java.
But if time is not an issue and you want to learn something new, then
go for Perl or Ruby. Personally, I would go with Perl because I know
it much better than I know Ruby, but I've been picking up some Ruby
and am liking it a lot. You could also try Python, which I understand
could be used just as easily as Ruby or Perl for this sort of task.

Ron wrote:
>
> Something I didn't mention before: the C++ code is generated by a 3rd
> party design tool. Thus the source I'm trying to translate has very
> standard formatting and syntax. It should be acceptably future-proof
> for me to treat this as my "logical language" for message definitions.
>
I also like the idea of using a language-neutral data definition and
using it to generate C++ and Java, but I see your problem. A couple of
thoughts:

If the design tool has the ability to export and/or import message
definitions in a language neutral format, it would open up two
possibilities:
- maintain a separate, definitive set of language definitions that is
imported into the design tool to generate C++ and processed by your
tool to generate Java source. The master definitions could be either
written in the design tool's import format or be generated from your
own format, database or whatever.

- treat the design tool's repository as definitive. Export the
definitions from it and use them to feet your Java generator.
I know this sounds very similar to translating the C++ source
but it may be easier to integrate with the project work flows.

This might be better than translating generated C++, especially if the
import/export format is documented, stable and is more easily parsed
than C++ source.

> Also, I just want the conversion grunt-work to be automated, but not
> the whole process. I will monitor churn to existing message
> defintions, so I should be able to catch any changes that cause the
> automated conversion to produce undesirable results.
>
As you're evidently in a separate project team from the C++ gang, it
stands to reason that manual change monitoring would be necessary.

Have you considered using a parser generator, such as Coco/R to write
your translation tool?

I've used it to generate Java code to parse C preprocessor directives
and that was pretty straight forward. Even with the learning curve (it
was the first time I'd used it) I was able to create a parser faster
than I could have written it by hand.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |