956 CONCURRENCY,DISTRIBUTION,CLIENT-SERVER AND THE INTERNET $30.3 This idea was first made popular by Java in late 1995 and 1996;Java execution engines have become widely available.Plug-ins have since appeared for many other mechanisms.An alternative to providing a specific plug-in is to generate,from any source language,code for a widely available engine,such as a Java engine;several compiler vendors have indeed started to provide generators of Java "bytecode"(the low-level portable code that the Java engine can execute). For the notation of this book the two avenues have been pursued:ISE has a free execution engine;and at the time of writing a project is in progress to generate Java bytecode. Either approach raises the potential of security problems:how much do you trust someone's application?If you are not careful,clicking on an innocent-looking hyperlink could unleash a vicious program that destroys files on your computer,or steals your personal information.More precisely you should not,as a user,be the one asked to be careful:the responsibility is on the provider of an execution engine and the associated library of basic facilities.Some widely publicized Java security failures in 1996 caused considerable worries about the issue. The solution is to use carefully designed and certified execution engines and libraries coming from reputable sources.Often they will have two versions: One version is meant for unlimited Internet usage,based on a severely restricted execution engine. In ISE's tool the only I/O library facilities in this restricted tool only read and write to and from the terminal,not files.The "external"mechanism of the language has also been removed,so that a vicious application cannot cause mischief by going to C,say,to perform file manipulations.The Java "Virtual Machine"(the engine)is also draconian in what it permits Internet"applets" to do with the file system of your computer. The other version has fewer or no such restrictions,and provides the full power of the libraries,file I/O in particular.It is meant for applications that will run ona secure Intranet (internal company network)rather than the wilderness of the Internet. In spite of the insecurity specter,the prospect of unfettered remote execution,a new step in the ongoing revolution in the way we distribute software,has generated enormous excitement,which shows no sign of abating. 30.3 FROM PROCESSES TO OBJECTS To support all these mind-boggling developments,requiring ever more use of concurrent processing,we need powerful software support.How are we going to program these things?Object technology,of course,suggests itself. Robin Milner is said to have exclaimed,in a 1991 workshop at an O-O conference, Cited in [Matsuoka "I can't understand why objects [of-O languages]are not concurrent in the first place". 1993]. Even if only in the second or third place,how do we go about making objects concurrent?956 CONCURRENCY, DISTRIBUTION, CLIENT-SERVER AND THE INTERNET §30.3 This idea was first made popular by Java in late 1995 and 1996; Java execution engines have become widely available. Plug-ins have since appeared for many other mechanisms. An alternative to providing a specific plug-in is to generate, from any source language, code for a widely available engine, such as a Java engine; several compiler vendors have indeed started to provide generators of Java “bytecode” (the low-level portable code that the Java engine can execute). For the notation of this book the two avenues have been pursued: ISE has a free execution engine; and at the time of writing a project is in progress to generate Java bytecode. Either approach raises the potential of security problems: how much do you trust someone’s application? If you are not careful, clicking on an innocent-looking hyperlink could unleash a vicious program that destroys files on your computer, or steals your personal information. More precisely you should not, as a user, be the one asked to be careful: the responsibility is on the provider of an execution engine and the associated library of basic facilities. Some widely publicized Java security failures in 1996 caused considerable worries about the issue. The solution is to use carefully designed and certified execution engines and libraries coming from reputable sources. Often they will have two versions: • One version is meant for unlimited Internet usage, based on a severely restricted execution engine. In ISE’s tool the only I/O library facilities in this restricted tool only read and write to and from the terminal, not files. The “external” mechanism of the language has also been removed, so that a vicious application cannot cause mischief by going to C, say, to perform file manipulations. The Java “Virtual Machine” (the engine) is also draconian in what it permits Internet “applets” to do with the file system of your computer. • The other version has fewer or no such restrictions, and provides the full power of the libraries, file I/O in particular. It is meant for applications that will run on a secure Intranet (internal company network) rather than the wilderness of the Internet. In spite of the insecurity specter, the prospect of unfettered remote execution, a new step in the ongoing revolution in the way we distribute software, has generated enormous excitement, which shows no sign of abating. 30.3 FROM PROCESSES TO OBJECTS To support all these mind-boggling developments, requiring ever more use of concurrent processing, we need powerful software support. How are we going to program these things? Object technology, of course, suggests itself. Robin Milner is said to have exclaimed, in a 1991 workshop at an O-O conference, “I can’t understand why objects [of O-O languages] are not concurrent in the first place”. Even if only in the second or third place, how do we go about making objects concurrent? Cited in [Matsuoka 1993]