C++ to Java Conversion Utility

[Ron]

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.

 

[Lord Zoltar]

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.

 

[Ron]

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.

 

[Patricia Shanahan]

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

 

[Ron]

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?

 

[Stefan Ram]

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.

 

[Ron]

Ron wrote:

...> Also, the only things I really need to convert automatically are


...

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.

 

[Ron]

  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.

 

[Lord Zoltar]

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.

 

[Martin Gregorie]

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.

 

[Patricia Shanahan]

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.

....

That makes a big difference. It is both an opportunity, because the code
is less likely to incorporate arbitrary idiosyncrasies than direct
human-written code, and a limitation, because it would be practically
impossible for you to change what the design tool generates.

At the best, the design tool has a document describing the output file
rules. That would make it easier to find out not just what it generates
for current cases, but what it might generate for future inputs.

Patricia

 

[Roedy Green]

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

Consider using a Funduc Search/Replace script. You can use from-to
pairs and from-to regex pairs.

see http://mindprod.com/jgloss/funduc.html

 

[Roedy Green]

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

like CORBA? see http://mindprod.com/jgloss/corba.html

 

[Gordon Beaton]

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

This is better done by definining your messages with YAML or JSON,
then using the corresponding language bindings for marshalling and
unmarshalling the messages.

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?

Indeed.

/gordon

--

 

[Stefan Ram]

As you're evidently in a separate project team from the C++ gang, it
stands to reason that manual change monitoring would be necessary.

Ron can explain to his supervisor that the current procedure
requires continuous human effort and suggest changes.

Even if a C++-to-Java translator would translate the
structural definitions, usually a program still needs to
be adjusted manually to a change in the interface structure.

If Ron still is required to follow whatever the C++ section
delievers, then this is not so much his problem if he is paid
by the hour. The supervisor can understand that the additional
effort is not Rons fault; and Ron gets paid for his effort.

 

[Martin Gregorie]

Even if a C++-to-Java translator would translate the
structural definitions, usually a program still needs to
be adjusted manually to a change in the interface structure.

Quite, and the only real solution to that is, as Patricia said, to store
the definitions in some form of database and load it at run time, but
this would require a fairly major rewrite on both the C++ and Java programs.

If the design is good and the designer has paid attention to run-time
efficiency the performance can be surprisingly good once the data
definitions have been loaded. IME this is a place where the designers
can't delegate run-time efficiency to the programmers.

If Ron still is required to follow whatever the C++ section
delievers, then this is not so much his problem if he is paid
by the hour. The supervisor can understand that the additional
effort is not Rons fault; and Ron gets paid for his effort.

....but the more straight forward change implementation is once the
project managers have got their heads together, the less likelihood
there is of mistakes and recriminations.

 

[Hendrik Maryns]

Ron schreef:

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 recently was pointed to SWIG. It does a great job creating Java
wrappers to existing C/C++ classes and functions, using JNI. It might
do what you want.

I had quite a hard time setting up Eclipse to handle the SWIG project,
(or JNI, for that matter) so if you want to do that, you can ask again.

HTH, H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHjdPSe+7xMGD3itQRAiF3AJ4z8yhtv68EAjHV9XoKdvLCBmRXYgCfb+eV
OUDF2jfs24/rUd/zf5dQ5Fc=
=jYO/
-----END PGP SIGNATURE-----

 

[Arne Vajhøj]

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

And maybe call it IDL ...

Like when used by CORBA, COM and UNO.



Arne

 

[Arne Vajhøj]

This is better done by definining your messages with YAML or JSON,
then using the corresponding language bindings for marshalling and
unmarshalling the messages.

That would either only be transport not API or not be very type safe.

Arne