languages the scoping visibility is defined by the location in the source code file - variables declared inside a method are local to that method, those defined outside methods or other declarations are global to the class (or program). This lack of file-based scoping is a base feature of the ScriptX language and others like it, notably Dylan. In conventional languages like Java, classes and similar constructs are defined within a single file, or at least a "master file". Scope is defined by the file system and the code's location within it. In contrast, in ScriptX any method can be defined on any class in any file. In this example, the method sendTrackDrop is being applied to the Tracker class, and can be placed within any file that will be accessed during runtime. This allows programmers to organize their code by class or by functionality, at the cost of some extra syntax. ScriptX vs. Java Java has many similarities with ScriptX. Like ScriptX, it is an object based language with elements of syntax that are similar to C and C++. Java classes support a limited form of multiple inheritance through interfaces, and the Java runtime environment utilizes a garbage collector for memory management with a "tracing" architecture similar to that of ScriptX. Both Java and ScriptX translate programs into a platform-independent bytecode. Unlike ScriptX, Java is not a pure object system, and has primitive data types. In contrast with ScriptX expressions, Java programs are always written inside a class definition, and return either a value or void. This makes Java code much easier to secure, to protect from tampering and malicious interference. Java was able from the beginning to support multi-processing as well as multi-threaded applications, and thus was naturally scalable. These features, and other attributes of Java, made it more suitable for a distributed and networking environment than ScriptX. Although both ScriptX and Java were designed as platform independent virtual machine environments, their philosophy and implementation were quite different. The Kaleida Media Player was a complex interpreter that required several megabytes to run, and Kaleida never achieved effective performance on a system with less than 16 MB of random-access memory. By contrast, Java was designed to run compiled bytecode on a stripped down virtual machine that could be implemented on virtually any 16-bit or larger processor. In this way, Java could be used anywhere from handheld devices or consumer