Decompile Once, Run Anywhere
Protecting Your Java Source
By Godfrey Nolan
Partly due to the media controversy over Internet fraud and partly because of the history of the language, Java is one of the most secure languages for Internet applications. Applets cannot read or write to a Web browser's hard disk, call native code, or access any third-party URLs. The programmer has no access to memory pointers, so they can't stray outside the bounds of their applet or application.
That's not to say that Java hasn't any security holes, or that security isn't a moving target, but JavaSoft is working hard to limit hostile applets. JavaBeans, for example, will use the sandbox concept--where signed applets cannot be executed until the user is happy with their credentials. Quite rightly, Java is seen as a much safer option than an ActiveX control.
The number of applets appearing on Web pages is increasing rapidly. Sun claims that there are now tens of thousands of Web pages with Java applets. With the advent of the JavaStation and cross-platform office suites from Lotus and Corel, Java has begun to shift away from the Web site and onto the desktop. But is an applet or application safe from prying eyes? No. The focus has always been on safeguarding the end user's security; the developer has largely been ignored.
One reason the number of Web pages increased exponentially and the overall design jumped in leaps and bounds was that the HTML or client-side scripting for most interesting Web effects could easily be copied by viewing the source. It was taken for granted, however, that Java applets, ActiveX controls, and any server-side scripting code would not be visible.<>
