We've heard so much about Java - just what is it?
In essence, Java is just another programming language. It looks a lot like C++, but it isn't like it at all. The Java language is object-oriented, with an exception handling model enforced at compile time. It performs garbage collection and array bounds checking.
It doesn't have pointers and what this means is that programs written in Java do not suffer from a lot of the common problems that C or C++ programs have, such as buffer overflows. A lot of Unix security holes can be traced down to buffer overflow problems.
Unlike most languages, Java does not compile to machine code. Instead it compiles to a machine independent bytecode. The result of this is that compiled Java programs require help to actually run on a computer. This help comes in the form of a Java Virtual Machine (JVM). The JVM handles the interaction between the Java bytecode and the computer, and typically supports a common set of routines like drawing normal graphical components. The benefit of the JVM system is that it allows you to compile your Java programs once, and then it will run on any machine that has a JVM. This means the same program can run on Unix, Windows 95, Mac OS, OS/2 and more.
What are the main differences between Java bytecode and p-code systems?
P-code systems are similar in some aspects of their philosophy, mainly in the compile-once-run-anywhere aspect. With a p-code system you could write your program in a language like Cobol, compile it to p-code and then use a p-code run-time environment to execute your program. This sounds very similar to Java bytecode and JVM.
However, the details of the two are quite different, which are a result of the design of the systems. Java was originally designed to run on set-top boxes. This required a small compact bytecode. P-code systems tend to be large and bloated as a result of implementing quite high-level commands in the p-code.
Another main difference between Java bytecode and p-code is the openness. "Open" is a much hyped term at present, but Java is open. Sun Microsystems gave away free implementations of their JVM for Solaris and Windows 95. The company gave free licenses for the source code to their JVM. This gave the industry a code base from which to build JVMs for other machines.
Sun retains control of the language and JVM specification, although it is trying to get it accepted as a standard which may result in its losing this control. In contrast, p-code systems tended to be vendor specific. You couldn't run code compiled under one vendor's compiler on another vendor's p-code run-time environment.
Why is Java hyped so much as a Web language?
In 1994, Sun built a Web browser in Java called HotJava. As a graphical browser of its period it was better than most, but in my opinion not as good as Navigator 1. It had the ability to download Java applets and so provide interaction to Web pages that had been static HTML.
At this time plug-ins like Shockwave weren't even on the horizon and graphic images were limited to static Gifs. Techniques known as "server push" and "client pull" were the limits of animation possible at that time.
Netscape then included support for Java in Navigator 2 for Unix, Windows 95 and, eventually, Mac OS. The popularity of Navigator meant a large proportion of the Web surfing community was now open to receive Java applets. Because the bytecode is compact, these applets were quite small.
Typically, the sounds and graphics took much longer to download than the actual applet itself. This allowed Java to get a solid foot in the door long before other methods of interaction were around.
Of course, soon after Macromedia produced the Shockwave plug-in, allowing designers to use Macromedia Director (a commonly used Multimedia authoring tool) to generate interactive animation with minimal programming, but by this stage Java was firmly in people's minds and on their tongues.
Are Java applets safe?
The answer to this is "they should be". The JVM that runs in the Web browser is protected by a "sandbox" which implements security and is meant to stop the applet doing anything nasty. For example, if the applet tried to overwrite your AUTOEXEC.BAT file, the sandbox would cause a security exception to be raised which would normally cause the applet to terminate.
Errors have been found in the Navigator sandbox before now, although these have all been corrected in the latest versions of Navigator.
Other browsers may have security flaws in their sandboxes as well. This makes it hard to guarantee that applets are 100 per cent safe. In addition, there are other ways in which an applet can cause problems, without breaking any of the sandbox rules.
It's true that Java applets are probably safer than plug-ins or ActiveX because of the sandbox being built in by design. In comparison, when you install a plug-in into Navigator, you have to trust that the plug-in doesn't open any new security holes.
It's important to distinguish between Java applets that are loaded from a Web server and an applet that is loaded from the filesystem with the file: style URL. The sandbox will work differently when loading the applet from the filesystem because it assumes you have already trusted it in order to copy it to your hard disk.
What is the future for Java?
Sun has recently applied to the ISO to make Java a standard. The application has had a few difficulties and is unlikely to be passed in its current form. This is probably due to Sun wishing to retain control of the language rather than relinquish control to an independent committee.
In the meantime, the Java language has been improved slightly and is currently at version 1.1. De facto standards exist for connections to databases (JDBC) with both native drivers and a JDBC-ODBC bridge available. Coding standards have been promoted to allow Java classes written by different people to be integrated (JavaBeans).
Software vendors from all over the world are creating utility class libraries, including windowing toolkits. Development environments as powerful as any to be found for Windows can be bought or downloaded from the Net. Netscape is promoting a complete series of classes and intranet utilities that can be downloaded from their Web site.
All is not rosey however. Microsoft is rebelling against Java. Although the company pledges to support Java, it's trying to redefine the term slightly. One example is the way it is extending the classes to allow direct access from Java to the Windows API.
Microsoft's defence is that Java is just another programming language and should be treated as such. Unfortunately this will destroy the platform independence of Java - code written for Windows using the new API will not work on any other machine. Of course, Microsoft is pushing ActiveX as the model for Web site applets, so it isn't too concerned about fragmenting Java in this way. Conspiracy theories exist in many forms.
On the horizon is the Java chip. This is a chip that can run Java bytecode directly and not require software emulation, resulting in faster execution. This could easily find it's way into the fabled network computer. A JavaStation based around the Java chip would run quicker and be a lot cheaper than current JavaStations.
And finally, a slightly ironic twist. Java was initially developed for embedded applications like set-top boxes. It didn't really succeed there and found a new home in Web pages. However, in a twist of fate, Java is returning to the cradle. It is possible that a new generation of mobile phones will be controlled by Java, possibly with the Java chip as the main CPU.
Found by calculating the strength of the material deep inside the crust of neutron stars
Can highlight in real-time the relevant regions of an image being described
Double legal trouble for Musk as he also faces civil lawsuit over renewed British pot-holer 'paedo' claims
Battery development could help boost performance of smartphones