Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.stack.nl!aioe.org!.POSTED!not-for-mail From: Rajiv Gupta Newsgroups: comp.lang.java.programmer Subject: Re: U.S. warns on Java software as security concerns escalate Date: Thu, 17 Jan 2013 11:47:29 +1100 Organization: Aioe.org NNTP Server Lines: 27 Message-ID: References: NNTP-Posting-Host: 39ANEZhZpPfPAN69vSdZ+Q.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Unison/2.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.java.programmer:21453 On 2013-01-16 09:23:29 +1100, Roedy Green said: > On Tue, 15 Jan 2013 15:22:07 +1100, Rajiv Gupta > wrote, quoted or indirectly quoted someone who said : > >> Browser manufacturers should stop supporting Java. Applets are a dead >> technology which hardly anybody uses (except for criminals). > > Applets are an inherently much superior technology for client side > computing. Nothing else has a sandbox. Nothing else is so scrupulous > about signing for dangerous code. Nothing else is so compact. > Browsers don't load the Java engine at start up, which made them > appear slower than they really are. Even that has been fixed with > smarter JVMs that hang around as DLLs. The closed mindedness and general ignorance of Java fanatics never ceases to amaze. As for the Java sandbox, the real problem is that the sandbox is implemented inside the VM itself, in Java (via the SecurityManager), and the Java runtime is poorly equipped to secure itself against itself. Contrast this with the sandboxing model the CLR uses, where access grants can only originate from outside of the VM -- it is impossible, by design, for managed code to enable grants that the VM itself was not externally configured to provide.