Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
On Tuesday 14 November 2006 13:28, Crispin Cowan wrote: It means that compromising performance It's not necessarily a given that runtime performance is compromised. There are situations where Java is faster than C (I've tested this on trivial things). I'm sure there are situations where the reverse is true, too. But as new releases of the JVM come out, all Java programs get faster. Personally, I find the programmer time to be much better used in Java too. That is less of a factor of the VM side of things (although you can do some really quite nice debugging things by communicating with the JVM which helps), but it does tend to be a feature of things that predominantly run inside some non-native environment. I don't know if there's a causation effect going on there or not however. to obtain runtime portability that does not actually exist is a poor bargain. The runtime portability is not perfect. The problems mostly exist where it interfaces to the underlying system, and where that's done imperfectly. Not so long ago, I ported a commercial desktop Java-based application from Windows to Linux. It took me a day or two to go through all the references to File, and make sure they were constructed properly (i.e. replace instances of '\\' with a properly constructed File) and do some testing, and that was all. It then looked and behaved just the same as it did on Windows, and objects could happily be de/reserialised across the different platforms (and on different architectures if necessary). However, you never have to deal with different word sizes, different endians, and so on. It removes as many of the gotchas as is feasible. Back on the security topic for a moment, you also gain things like sandboxing that works in a way that isn't reliant on the capabilities of the hardware. Robin. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
Robin Sheat wrote: On Tuesday 14 November 2006 13:28, Crispin Cowan wrote: It means that compromising performance It's not necessarily a given that runtime performance is compromised. There are situations where Java is faster than C (I've tested this on trivial things). Here it is bytecode vs. native code generator, not Java vs. C. Remember, I advocated Java over C++ in the first place :) Even in the bytecode vs. native code generator contest, there are cases where each will win: * bytecode interpreters always lose; they really are just a kludge * JIT can win if it uses dynamic profiling effectively and the application is amenable to optimization for decisions that need to be evaluated at runtime * JIT can be a lose because of the latency required to JIT the code instead of compiling ahead of time So: * JIT will win if your application is long-lived, and has a lot of dynamic decision making to do, e.g. making a lot of deep object member function calls that are virtual, or just a lot of conditional branches. * Native code will win if your applications are just short-lived, because they are dispatched as children from a dispatcher process o You pat the JIT cost each time it starts o The short lifespan doesn't give dynamic profiling time to do its thing Personally, I find the programmer time to be much better used in Java too. No argument from me. I advocate Java, I just want a native code generator instead of bytecode. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hack: adroit engineering solution to an unanticipated problem Hacker: one who is adroit at pounding round pegs into square holes ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
Crispin Cowan wrote: Al Eridani wrote: On 11/9/06, Crispin Cowan [EMAIL PROTECTED] wrote: Prior to Java, resorting to compiling to byte code (e.g. P-code back in the Pascal days) was considered a lame kludge because the language developers couldn't be bothered to write a real compiler. Post-Java, resorting to compiling to machine code is considered a lame kludge because the language developers cannot be bothered to write a real optimizer. I don't see what a bytecode intermediate stage has to do with real optimizer. Very sophisticated optimizers have existed for native code generators for a very long time. Bytecode interpreter performance blows goats, so I'm going to assume you are referring to JIT. The first order effect of JIT is slow startup time, but that's not an advantage either. So you must be claiming that dynamic profiling (using runtime behavior to optimize code) is a major advantage. It had better be, because the time constraints of doing your optimization at JIT time restrict the amount of optimization you can do vs. with a native code generator that gets to run off-line for as long as it needs to. But yes, dynamic profiling can be an advantage. However, its use is not restricted to bytecode systems. VMware, the Transmeta CPU, and DEC's FX86 (virtual machine emulation to run x86 code on Alpha CPUs) use dynamic translation to optimize performance. It works, in that those systems all do gain performance from dynamic profiling, but note also the reputation that they all have for speed: poor. And then there's write once, run anywhere. Yeah ... right. I've run Java applets, and Javascript applets, and the latter are vastly superior for performance, and worse, all too often the Java applets are not run anywhere, they only run on very specific JVM implementations. There's the nice property that bytecode can be type safe. I really like that. But the bytecode checker is slow; do people really run it habitually? More important; is type safety a valuable property for *untrusted code* that you are going to have to sandbox anyway? So I give up; what is it that's so great about bytecode? It looks a *lot* like the Emperor is not wearing clothes to me. Crispin Considering that on VMS, due to the use everywhere of a single calling standard and a linker that can understand things, you can link any language with any other language and get things to run. A single app with some pieces in Fortran, C, Pascal, BASIC, and assembly language, all in one program, is perfectly feasible. I have worked with such. Everything's compiled, everything compiles to optimised machine code, and there is no interpreter needed. So why does anyone consider that multilingual development requires some kind of interpretive runtime? The old P-system was current a LONG time ago now, always did have speed problems (and took down some pretty decent apps with that ship in its day because they couldn't run as fast as native code ones). If there is some construct that NEEDS to be interpreted to gain something, it can be justified on that basis. Using interpretive runtimes just to link languages, or just to achieve portability when source code portability runs pretty well thanks, seems wasteful to me. Anybody know why .net uses a runtime of the sort it does? Glenn Everhart ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
On 11/13/06, Glenn and Mary Everhart [EMAIL PROTECTED] wrote: Crispin Cowan wrote: Al Eridani wrote: On 11/9/06, Crispin Cowan [EMAIL PROTECTED] wrote: Prior to Java, resorting to compiling to byte code (e.g. P-code back in the Pascal days) was considered a lame kludge because the language developers couldn't be bothered to write a real compiler. Post-Java, resorting to compiling to machine code is considered a lame kludge because the language developers cannot be bothered to write a real optimizer. I don't see what a bytecode intermediate stage has to do with real optimizer. Very sophisticated optimizers have existed for native code generators for a very long time. Bytecode interpreter performance blows goats, so I'm going to assume you are referring to JIT. The first order effect of JIT is slow startup time, but that's not an advantage either. So you must be claiming that dynamic profiling (using runtime behavior to optimize code) is a major advantage. It had better be, because the time constraints of doing your optimization at JIT time restrict the amount of optimization you can do vs. with a native code generator that gets to run off-line for as long as it needs to. But yes, dynamic profiling can be an advantage. However, its use is not restricted to bytecode systems. VMware, the Transmeta CPU, and DEC's FX86 (virtual machine emulation to run x86 code on Alpha CPUs) use dynamic translation to optimize performance. It works, in that those systems all do gain performance from dynamic profiling, but note also the reputation that they all have for speed: poor. And then there's write once, run anywhere. Yeah ... right. I've run Java applets, and Javascript applets, and the latter are vastly superior for performance, and worse, all too often the Java applets are not run anywhere, they only run on very specific JVM implementations. There's the nice property that bytecode can be type safe. I really like that. But the bytecode checker is slow; do people really run it habitually? More important; is type safety a valuable property for *untrusted code* that you are going to have to sandbox anyway? So I give up; what is it that's so great about bytecode? It looks a *lot* like the Emperor is not wearing clothes to me. Crispin Considering that on VMS, due to the use everywhere of a single calling standard and a linker that can understand things, you can link any language with any other language and get things to run. A single app with some pieces in Fortran, C, Pascal, BASIC, and assembly language, all in one program, is perfectly feasible. I have worked with such. Everything's compiled, everything compiles to optimised machine code, and there is no interpreter needed. So why does anyone consider that multilingual development requires some kind of interpretive runtime? The old P-system was current a LONG time ago now, always did have speed problems (and took down some pretty decent apps with that ship in its day because they couldn't run as fast as native code ones). If there is some construct that NEEDS to be interpreted to gain something, it can be justified on that basis. Using interpretive runtimes just to link languages, or just to achieve portability when source code portability runs pretty well thanks, seems wasteful to me. You think source code portability is good enough such that runtime portability isn't really needed? Anybody know why .net uses a runtime of the sort it does? Because .net is microsofts clone of Java, so they copied everything. Glenn Everhart -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
At 10:31 PM +1100 11/13/06, mikeiscool wrote: On 11/13/06, Glenn and Mary Everhart [EMAIL PROTECTED] wrote: If there is some construct that NEEDS to be interpreted to gain something, it can be justified on that basis. Using interpretive runtimes just to link languages, or just to achieve portability when source code portability runs pretty well thanks, seems wasteful to me. You think source code portability is good enough such that runtime portability isn't really needed? Anything beyond source code portability tempts the customer into use on a platform where the developer has not tested. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
On 11/14/06, ljknews [EMAIL PROTECTED] wrote: At 10:31 PM +1100 11/13/06, mikeiscool wrote: On 11/13/06, Glenn and Mary Everhart [EMAIL PROTECTED] wrote: If there is some construct that NEEDS to be interpreted to gain something, it can be justified on that basis. Using interpretive runtimes just to link languages, or just to achieve portability when source code portability runs pretty well thanks, seems wasteful to me. You think source code portability is good enough such that runtime portability isn't really needed? Anything beyond source code portability tempts the customer into use on a platform where the developer has not tested. But it has been tested, because if it runs on that jvm it has been tested for that JVM. a JVM version x on linux is the same as a JVM version x on windows. That's the point. Now maybe they try running it with a version x - 5 JVM, well fine, it may not work, but the response would be: duh. -- Larry Kilgallen -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
On 11/14/06, Leichter, Jerry [EMAIL PROTECTED] wrote: | If there is some construct that NEEDS to be interpreted to gain | something, it can be justified on that basis. Using interpretive | runtimes just to link languages, or just to achieve portability | when source code portability runs pretty well thanks, seems | wasteful to me. | | You think source code portability is good enough such that runtime | portability isn't really needed? | | Anything beyond source code portability tempts the customer into use | on a platform where the developer has not tested. | | But it has been tested, because if it runs on that jvm it has been | tested for that JVM. a JVM version x on linux is the same as a JVM | version x on windows. That's the point. Now maybe they try running it | with a version x - 5 JVM, well fine, it may not work, but the response | would be: duh. That would be nice, wouldn't it? Unfortunately, painful experience says it's not so. At least not for applications with non-trivial graphics components, in particular. The joke we used to make was: The promise of Java was Write once, run everywhere. What we found was Write once, debug everywhere. Then came the Swing patches, which would cause old bugs to re-appear, or suddenly make old workaround cause problems. So the real message of Java is Write once, debug everywhere - forever. Now, I'm exagerating for effect. There are Java programs even quite substantial Java programs, that run on multiple platforms with no problems and no special porting efforts. (Hell, there are C programs with the same property!) But there are also Java programs that cause no end of porting grief. It's certainly much more common to see porting problems with C than with Java, but don't kid yourself: Writing in Java doesn't guarantee you that there will be no platform issues. True, but that doesn't mean runtime portability isn't a good thing to aim for. -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
mikeiscool wrote: On 11/14/06, Leichter, Jerry [EMAIL PROTECTED] wrote: The joke we used to make was: The promise of Java was Write once, run everywhere. What we found was Write once, debug everywhere. Then came the Swing patches, which would cause old bugs to re-appear, or suddenly make old workaround cause problems. So the real message of Java is Write once, debug everywhere - forever. Now, I'm exagerating for effect. There are Java programs even quite substantial Java programs, that run on multiple platforms with no problems and no special porting efforts. (Hell, there are C programs with the same property!) But there are also Java programs that cause no end of porting grief. It's certainly much more common to see porting problems with C than with Java, but don't kid yourself: Writing in Java doesn't guarantee you that there will be no platform issues. True, but that doesn't mean runtime portability isn't a good thing to aim for. It means that compromising performance to obtain runtime portability that does not actually exist is a poor bargain. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hack: adroit engineering solution to an unanticipated problem Hacker: one who is adroit at pounding round pegs into square holes ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
Al Eridani wrote: On 11/9/06, Crispin Cowan [EMAIL PROTECTED] wrote: Prior to Java, resorting to compiling to byte code (e.g. P-code back in the Pascal days) was considered a lame kludge because the language developers couldn't be bothered to write a real compiler. Post-Java, resorting to compiling to machine code is considered a lame kludge because the language developers cannot be bothered to write a real optimizer. I don't see what a bytecode intermediate stage has to do with real optimizer. Very sophisticated optimizers have existed for native code generators for a very long time. Bytecode interpreter performance blows goats, so I'm going to assume you are referring to JIT. The first order effect of JIT is slow startup time, but that's not an advantage either. So you must be claiming that dynamic profiling (using runtime behavior to optimize code) is a major advantage. It had better be, because the time constraints of doing your optimization at JIT time restrict the amount of optimization you can do vs. with a native code generator that gets to run off-line for as long as it needs to. But yes, dynamic profiling can be an advantage. However, its use is not restricted to bytecode systems. VMware, the Transmeta CPU, and DEC's FX86 (virtual machine emulation to run x86 code on Alpha CPUs) use dynamic translation to optimize performance. It works, in that those systems all do gain performance from dynamic profiling, but note also the reputation that they all have for speed: poor. And then there's write once, run anywhere. Yeah ... right. I've run Java applets, and Javascript applets, and the latter are vastly superior for performance, and worse, all too often the Java applets are not run anywhere, they only run on very specific JVM implementations. There's the nice property that bytecode can be type safe. I really like that. But the bytecode checker is slow; do people really run it habitually? More important; is type safety a valuable property for *untrusted code* that you are going to have to sandbox anyway? So I give up; what is it that's so great about bytecode? It looks a *lot* like the Emperor is not wearing clothes to me. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hack: adroit engineering solution to an unanticipated problem Hacker: one who is adroit at pounding round pegs into square holes ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
And then there's write once, run anywhere. Yeah ... right. I've run Java applets, and Javascript applets, and the latter are vastly superior for performance, and worse, all too often the Java applets are not run anywhere, they only run on very specific JVM implementations. You really can't judge java based on java applets; they are a really poor front, for reasons I assume you are aware. There's the nice property that bytecode can be type safe. I really like that. But the bytecode checker is slow; do people really run it habitually? More important; is type safety a valuable property for *untrusted code* that you are going to have to sandbox anyway? I believe major application servers run with -verify, which is appropriate and useful for them. So I give up; what is it that's so great about bytecode? It looks a *lot* like the Emperor is not wearing clothes to me. I think you just want to see him that way ;) Crispin -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
On 11/9/06, Crispin Cowan [EMAIL PROTECTED] wrote: Prior to Java, resorting to compiling to byte code (e.g. P-code back in the Pascal days) was considered a lame kludge because the language developers couldn't be bothered to write a real compiler. Post-Java, resorting to compiling to machine code is considered a lame kludge because the language developers cannot be bothered to write a real optimizer. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
On 11/9/06, SZALAY Attila [EMAIL PROTECTED] wrote: 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. :) So basically you are expecting the only thing to go wrong on your program is to be bugs in the VM? Be it java or c#? I find that really strange. Sure, there have been bugs in the JVM/C# VM but just the same there have been bugs in windows that will affect your c programs. I really don't see that being a feasible/likely enough scenario to not use one of these languages. 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. Right exactly, and the fact that you have a stable VM instead of a strange-patched-level of windows/linux os gives you a stable platform. -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
Hi Al, On Thu, 2006-11-09 at 08:47 -0500, ljknews wrote: I think you are mixing the issue of Java vs. C* with the issue of interpreters vs compiled languages. Yes, you are totally right. Sorry. But I have not seen java or c# compiler. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
ljknews wrote: At 4:18 PM +0100 11/9/06, SZALAY Attila wrote: Hi Al, On Thu, 2006-11-09 at 08:47 -0500, ljknews wrote: I think you are mixing the issue of Java vs. C* with the issue of interpreters vs compiled languages. I agree with LJ: language issues aside, I detest bytecode interpreters. Prior to Java, resorting to compiling to byte code (e.g. P-code back in the Pascal days) was considered a lame kludge because the language developers couldn't be bothered to write a real compiler. The innovation of Java was to describe this as a feature instead of a bug :) Yes, you are totally right. Sorry. But I have not seen java or c# compiler. For Java, look at JGC http://www.gnu.org/software/gcc/java/. It can compile Java source code to Java bytecode (class files) or directly to native machine code, and Java bytecode to native machine code. For C#, the Mono compiler says http://www.mono-project.com/using/relnotes/1.0-features.html that it has an advanced native optimizing compiler is available for x86, SPARC, s390 and PowerPC available in both an ahead-of-time (AOT) compilation mode to reduce startup time and take advantage of all available optimizations and a Just-in-Time (JIT) compilation mode. However, having native code generation is different from having good support in GDB for you generated code :) Without GDB support, the debugger will treat your binaries like they were written in hand assembly, and not be able to relate core dumps to high level constructs like variables and lines of source code. Current status: * For Java: From the JGC FAQ http://gcc.gnu.org/java/faq.html#1_6, gdb 5.0 ftp://ftp.gnu.org/pub/gnu/gdb/ includes support for debugging gcj-compiled Java programs. For more information please read Java Debugging with gdb http://gcc.gnu.org/java/gdb.html. * For C#: There is a Mono Debugger http://www.mono-project.com/Debugging, but it is not complete. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hack: adroit engineering solution to an unanticipated problem Hacker: one who is adroit at pounding round pegs into square holes ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
Hi All! On Mon, 2006-11-06 at 23:23 +1100, mikeiscool wrote: Hold the phone ... What debugging problems? What _specific_ speed issues? I'd be really surprised if your project couldn't be resolved with java; what specific problems are you facing? What tests have you run/consider to show that java's supposed speed issues will give you trouble? If it's just xml processing I'd say efficient data structures are what you care about, so java can help you there. 1. Debug When the program do something nasty or unwanted thing then in C I could do a lot of thing to find what happened. For example I could make the program dropping a core and analyze it at home. This needed because the program used some places where I cannot go into. And there were bugs in program which is definitely a race condition what is hard to reproduce. So it's not enough to write the steps to reproduce the bug. And I'm not sure that I can get the complete state of the program (and just the program) so I can detect where is the problem, even when the problem is in the compiler. I think it's more harder in java language. 2. Speed Yes, it's maybe an outdated information but for example if there are a java plugin in my web browser (not javascript, java, for example the terminal plugin in some management page of AMD64 servers) or the ``famous'' Hungarian social web page iWIW, which was programmed in JAVA and was slow like Hell. And in this program there are some functions, which is in the corner of usage about speed. (Sometimes in the other side :( ), So any speed degradation is a PIA. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
On 11/8/06, SZALAY Attila [EMAIL PROTECTED] wrote: Hi All! On Mon, 2006-11-06 at 23:23 +1100, mikeiscool wrote: Hold the phone ... What debugging problems? What _specific_ speed issues? I'd be really surprised if your project couldn't be resolved with java; what specific problems are you facing? What tests have you run/consider to show that java's supposed speed issues will give you trouble? If it's just xml processing I'd say efficient data structures are what you care about, so java can help you there. 1. Debug When the program do something nasty or unwanted thing then in C I could do a lot of thing to find what happened. For example I could make the program dropping a core and analyze it at home. This needed because the program used some places where I cannot go into. And there were bugs in program which is definitely a race condition what is hard to reproduce. So it's not enough to write the steps to reproduce the bug. And I'm not sure that I can get the complete state of the program (and just the program) so I can detect where is the problem, even when the problem is in the compiler. I think it's more harder in java language. 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 :) 2. Speed Yes, it's maybe an outdated information but for example if there are a java plugin in my web browser (not javascript, java, for example the terminal plugin in some management page of AMD64 servers) or the ``famous'' Hungarian social web page iWIW, which was programmed in JAVA and was slow like Hell. 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. -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
for cross-platform C# there is the mono project which do a great jpb of porting the .NET framework to the Linux world, check it out at : http://www.mono-project.com/further perl or python (which are more or less cross-platform) might also be used for your rewrite project, all depends one your specific needs... On 11/5/06, SZALAY Attila [EMAIL PROTECTED] wrote: Hi All!I read this thread and I little be afraid. I'm just ahead of a completerewriting of my program. The previous code was written in pure C (withan OOP looks-like somewhere).This program should run on Linux, freebsd and windows platform. This program is a GUI, so it has a graphical interface too but do a lot ofcomputing and xml handling.I know C the most, so C++ is the least step I have to do. But I'muncertain now that this is enough. When I have looked around for OO alternatives the C# was dropped, because I couldn't find across-platform graphical tools and Java was dropped because it's speedand the possibilities of debugging problems.Is there any other alternatives or I left something or the C++ is the only alternative for me?___Secure Coding mailing list (SC-L)SC-L@securecoding.orgList information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-lList charter available at - http://www.securecoding.org/list/charter.php ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
On 11/6/06, SZALAY Attila [EMAIL PROTECTED] wrote: Hi All! I read this thread and I little be afraid. I'm just ahead of a complete rewriting of my program. The previous code was written in pure C (with an OOP looks-like somewhere). This program should run on Linux, freebsd and windows platform. This program is a GUI, so it has a graphical interface too but do a lot of computing and xml handling. I know C the most, so C++ is the least step I have to do. But I'm uncertain now that this is enough. When I have looked around for OO alternatives the C# was dropped, because I couldn't find a cross-platform graphical tools and Java was dropped because it's speed and the possibilities of debugging problems. Hold the phone ... What debugging problems? What _specific_ speed issues? I'd be really surprised if your project couldn't be resolved with java; what specific problems are you facing? What tests have you run/consider to show that java's supposed speed issues will give you trouble? If it's just xml processing I'd say efficient data structures are what you care about, so java can help you there. Is there any other alternatives or I left something or the C++ is the only alternative for me? Certainly not. If all else fails you can write memory-intensive stuff in a dll and import it into one java or c#. It'll still be some lower-level coding (in c++ or c or asm) but at least it'll be isolated. You'll need to explain your program more ... -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
I read this thread and I little be afraid. I'm just ahead of a complete rewriting of my program. The previous code was written in pure C (with an OOP looks-like somewhere). Perhaps I'm missing something. Why do you have to abandon C? You mention C++, C#, and Java, but no other languages; is there some reason you have to use a language that tries to be object-oriented? Also, you have said nothing about what the tradeoffs involved are. Since this is sc-l, I assume security is involved; what does this code need to be secure against? It could very well be that C is the right language for you to use. Yes, it has problems, but so do all other languages; it's just a question of finding the language whose problems are least problematic for you and your application, and it sounds to me as though some of the most important problems for you have nothing to do with the languages' capabilities per se. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
At 10:47 AM -0500 11/6/06, der Mouse wrote: I read this thread and I little be afraid. I'm just ahead of a complete rewriting of my program. The previous code was written in pure C (with an OOP looks-like somewhere). Perhaps I'm missing something. Why do you have to abandon C? You mention C++, C#, and Java, but no other languages; is there some reason you have to use a language that tries to be object-oriented? Is there some reason you have to use a language that looks like C ? -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
