Opaque classes and interfaces necessary to simulate JavaScript features, and internal classes for simulative implementation.

For the purposes of both simulation and re-compilation, JS has to, in addition to the access control from Java language, limit the usage of classes and class members by defining compatibility of software members. To JS, a Java software encloses its package collections; A package collection encloses its packages; A package encloses its classes, interfaces, and sub-packages; An interface or class encloses its inner classes and interfaces, its static and instance members including fields, methods and constructors; A field or a constructor encloses its declaration and definition; And a method encloses its declaration, and its definition (method body) if it is concrete.

JS specifies the compatibility of a software member into three levels: normal, opaque and internal. JS Standard Library contains a few opaque interfaces, several internal classes, a couple of base opaque classes, many extended opaque classes, and a lot more normal classes, all distinctively described in the documentation. Accessing software members violating their compatibility shall cause re-compilation failure.

An opaque member can be accessed freely wherever a normal one could be, but it is opaque to JS re-compilers that are required to treat it as just a name. Members of an opaque member are automatically opaque unless specified otherwise. The opacity checking depends on naming reference only. As specified in each "JavaScript" section, re-compilers are expected to convert opaque operations straight forward to the required JavaScript expressions by checking the naming references, rather than resolving the actual members. This is the rule of "Names only for opaque". Note that, subclasses of an opaque class are also opaque while an opaque interfaces can only be implemented in opaque classes or internal classes, such as the classes in JS Simulation Library which is totally isolated from re-compilers by the class {@link js.Sim}. Other than extending the existing opaque classes, developers can not specify opacity for any classes or interfaces.

JS re-compilers shall report errors on any operations causing to access the class data of opaque members.

Internal members are "internal" means they are only expected to be accessed "internally" in opaque members and other internal members. With this rule followed, an internal member is always isolated from and therefore invisible to JS re-compilers. Members of an internal member and subclasses of an internal class must be internal. Accessing the internal members outside of opaque members and internal members is prohibited.

JS re-compilers shall report errors on any operations causing to resolve internal members.

Unless specified, the compatibility and usage of a member are inherited from the super class for a subclass, from the overridden method for an overriding method, or from the enclosing member for a member that is neither a subclass nor an overriding method. Obviously, a private member has no special usage and inherits compatibility from its enclosing member.

As a software, JS is opaque and encloses JS Simulation (sim.jar) which is totally internal, JS Emulation (emu.jar) which is an internal package collection with normal packages, and JS Class Library (js.jar) which is opaque and encloses the opaque packages js.** and the normal packages jsx.**.

Members of an opaque member can be specifically internal but members of an internal member must be all internal. To make re-compilation, simulation and user development relatively independent onto each other, developers other than the author can nor specify the special usage or compatibility, which must be default or inherited from JS.

Without specified, a member is automatically normal, or compatible to both simulation environment and re-compilation process. A normal member has the default compatibility and need not have a "JavaScript" section in this document for it. The subclasses of a normal class must also be normal, but its superclass and members do not have to. For examples, {@link js.Function} is normal but its members, except for the abstract method {@link js.Function#function(Object, js.Function.Call)}, are all opaque, so we are able to define function objects with "normal" Java statements while access the function itself "opaquely". And {@link js.JsApplet} is normal but its superclass, specifically (java.applet), is internal and its members, except for the method {@link js.JsApplet#start()} and {@link js.JsApplet#onReady()}, are all opaque, so we are able to create JS applets "normally".

User defined packages are all normal and a user defined subclass automatically inherits compatibility from its superclass. That is, user defined classes are all normal except for the extended opaque classes. The members of a user extended opaque class must all be opaque and "direct", which means re-compilation process must convert them directly without changing their names, though expanding variable arguments is necessary. for an opaque method with a {@link js.Vars} parameter.

Specially, Java primitive types are all "opaque". The class java.lang.String and Java basic classes that wrap the primitive types are also "primitive" in re-compilation and therefore are opaque too. The class java.lang.Object and the class java.lang.Class have obviously to be opaque to re-compilers but no class inherits the compatibility from java.lang.Object. The static main methods are always internal, where developers can initialize simulation, start applets and/or initiate re-compilation. The static main methods must be isolated completely from the re-compilation process, though the re-compilers themselves might have been started from there.

Please refer to Standard ECMA-262 ECMAScript Language Specification and David Flanagan's JavaScript: The Definitive Guide, 5th Edition for the features of JavaScript language.