Boris Epstein wrote:

On Fri, Jun 12, 2009 at 11:00 AM, Dave Howorth wrote:

...

Boris Epstein wrote:

...

Can you recommend a tool to convert a bunch of legacy C code into Java?

A programmer? But I expect I/they'd resent being called a 'tool' :)

Cheers, Dave --

Well, I am ending up playing the role of said tool... And am wondering if that role could be offloaded to a piece of software:)

In fact, I've found a couple, but they seemed so primitive as to be almost of no use.

Don't bother - you'll end up with a nightmare of unmaintainable code. /Per -- Per Jessen, Zürich (19.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Randall R Schulz wrote:

On Saturday June 13 2009, G T Smith wrote:

...

Boris Epstein wrote:

...

Hi all,

...

Can you recommend a tool to convert a bunch of legacy C code into Java?

Thanks.

Boris. Why? It is more normal to port from inefficient to efficient languages, and C is much more efficient than Java. ...

That is a myth.

?? Nonsense... Assuming the same programmer writing as near as possible the same algorithm then the C code should out perform the Java code by a significant value for most tasks, by being faster (no interpreter overheads for a starter), using less physical resources (no JRE memory footprint for seconds). True, the more complex the program becomes the easier it is to realize that complexity within the OO paradigm than the procedural or functional language paradigms, which is *not* in itself an efficiency issue. This is not a myth but a practical observation of a requirement the language (compiled Java does exist and I have never used it as I would suspect some functionality could be lost), no matter how efficient the JRE can be made it will always add an overhead. What could be more precise is to replace efficient with 'efficient to task'. One would not normally write hardware device drivers, perform heavy duty numeric computing, compilers or low level OS code in Java (you might prototype in Java for later porting to something else if you are using any variant of fast prototyping but it would be perverse to release production code in Java for these purposes). Java is rather like a swan... smooth and graceful on the surface but paddling furiously to keep up under the surface...

...

...

Randall Schulz

- -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAko2IcQACgkQasN0sSnLmgL2dACeLNDpAtxiSddwKeAhdYCMf7eh Hw8An1NvWVfNSiDzug+cph8VsxRMoABA =OfPJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Randall R Schulz wrote:

On Monday June 15 2009, G T Smith wrote:

...

Randall R Schulz wrote:

...

On Saturday June 13 2009, G T Smith wrote:

...

Boris Epstein wrote:

...

Hi all,

<>

...

?? Nonsense...

Assuming the same programmer writing as near as possible the same algorithm then the C code should out perform the Java code by a significant value for most tasks, by being faster (no interpreter overheads for a starter), ...

All the code that is executed frequently is converted to native machine code by the JIT compiler.

There are many optimizations available dynamically that are not available to ahead-of-time machine code compilation used by languages like C.

There are some few applications that are not competitive in Java, but not many.

While I am sceptical about the results presented of the site given by Boyd elsewhere, it does suggest that there is some sort of performance hit for Java. The question is really if the decision to optimise dynamically when running improves the performance more than the penalty for making the decision, a classic risk analysis and decision theory problem. Java's strength is the productivity benefits of the tools available for writing Java, and side stepping memory management issues that bedevil C and C++ programming, not its speed and memory usage. The features above limit the impact of aspects of its performance requirements but do not eliminate them.

Randall Schulz

- -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAko3br8ACgkQasN0sSnLmgLvugCcC5/U10OYQSsw4jscA7psAKlv Iy4An1g4PeAbEaLsHGXWyoSgxATQsGzp =kKK9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Boyd Stephen Smith Jr. wrote:

In <4A3621C4.604@gandalfsemporium.homelinux.com>, G T Smith wrote:

...

Randall R Schulz wrote:

...

On Saturday June 13 2009, G T Smith wrote:

...

C is much more efficient than Java. ... That is a myth. ?? Nonsense...

Benchmarks say otherwise.

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=all&box=1 is a fair set of benchmarks across languages. C and C++ are still the leaders as far as run time (with C++ beating C), but Java is right behind them overall and does run faster on some of the benchmarks when you drill down.

There was a time when compilers were compared using a well defined set of tests for a particular language. The end result was a lot of compilers that performed the test superbly well but often were less effective in real application. The thing which rather makes me inclined to take the resulted here with a little scepticism is the gaps in some of the tests. This is a bit of fun but I would query the methodological rigour of the test framework.

I'm still an advocate for ISO-standardized languages (C being my favorite), but I'm getting more friendly toward languages that have a free software implementation.

- -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAko3bpMACgkQasN0sSnLmgL/EgCgyPKhU1IoA1+w5sIWSvCOD595 r78AoMQjlo0bFYgxmeTr4lx3PU4KOx+O =g1eI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org