Could I use Java or c#? [was: Re: re-writingcollege books]

[dcrocker at eschertech.com (David Crocker)]

Hi Attila,

I wouldn't worry about not being able to see the assembly code while debugging.
In practice, there is less need for debugging Java or C# code than with C++. For
example, in C++, out-of-bounds array writes and incorrect type conversions can
give rise to bugs that are hard to find, because the effect may be felt some
time after the cause (e.g. the out-of-bounds array write corrupts some data). In
Java or C#, the runtime system catches this sort of bug immediately.

My company uses a code generator that can generate either C++ or Java. Although
the production version of the products we ship are built using C++ code, for
development and initial testing we generally use the Java code because bugs are
caught much earlier.

The performance improvement you can get from using C++ rather than Java or C# is
significant only if the program uses really huge amounts of CPU time, in which
case you might be able to make a case that the hardware cost saving outweighs
the higher cost and time to develop in C++ rather than Java or C#. Otherwise,
for application-level programming, Java or C# would generally be a more
productive choice.

Regards

David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com



-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On
Behalf Of SZALAY Attila
Sent: 09 November 2006 11:20
To: fake at mailinator.com
Cc: Secure Coding
Subject: Re: [SC-L] Could I use Java or c#? [was: Re: re-writingcollege books]


Hi All,

On Thu, 2006-11-09 at 10:20 +1100, mikeiscool wrote:
> You can definately get appropriate information via the stack trace 
> with java's exception handling. It's strange to see you say debugging 
> is _eaiser_ in c, typically people find it far easier in a managed 
> language :)

People are different. :))

I personally want to know what happens and I don't believe anything waht I can't
see. In C I can see the assembly code what (I hope) is a deterministic thing. An
interpreter is to big (to me) to think about it as a deterministic thing. And
yes, with ``normal'' bugs a managed language could give me more possibility to
find the place of the problem. But I want to hope, that we don't commit normal
bugs. :)

And with mysterious bugs, when you cannot reproduce it in a test system, just
the costumer some hundred miles away, I think that the stability of the compiled
code (and the core file what may created) is give more more chance to find the
right place.

> That's a java applet; please don't judge Java the language based on 
> applets; they are a really bad representation. Serverside java will be 
> very effective and useful; what sort of client are you writing? Is it 
> a website or a desktop app? Even if it's a desktop app, perhaps look 
> to azureus to see a good, well running app written in java for the 
> desktop. There are others.

This is a desktop application in a client-server model.
I will look after azureus.


_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php