Ray Cromwell writes:
Well those concerns are all fine and swell, but the same kind of reasoning applies to any network application. There are buffer overflow bugs in almost every web browser, there are overflow bugs in CERN HTTPD3.0, and who knows, there are probably bugs in ELM/PINE.
I believe that the security related ones in those applications are well within human ability to fix -- simply implementing some hygenic coding practices stops them. I don't believe that is the case with Java implementations. I don't know how I'd manage to produce a "safe" Java. Its a neat programming language, by the way -- its only when you rig yourself to automatically run code produce by hostile people that the issue comes up.
And the situation without Java is not much better. Most of Java functionality is faked with CGI scripts, usually written in perl, and there are plenty of ways to screw up a CGI implementation to allow holes.
Thats true, but again, there is the alternative of gaining the functionality with truly safe languages.
Java is mostly a risk to consumers (the users with the browsers), and not corporate networks who are running servers, *unless* the employees are using Java on the firewalled network.
Unfortunately, it will be very hard to stop people from doing just that. Perry