diff --git a/xdocs/tech.xml b/xdocs/tech.xml index eef3246..a15ce26 100644 --- a/xdocs/tech.xml +++ b/xdocs/tech.xml @@ -229,8 +229,8 @@

(VMSpec 5.4.3) - Resolution of a symbolic reference occurs dymanically at runtime and is carried out by - the Java Vitual Machine. Resolution of a symbolic reference requires loading and linking of the new class. + Resolution of a symbolic reference occurs dynamically at runtime and is carried out by + the Java Virtual Machine. Resolution of a symbolic reference requires loading and linking of the new class.

@@ -241,8 +241,8 @@

(VMSpec 2.17.2) - Loading is the name given process by which a binary form of a class is obtained - by the Java Virutal Machine. + Loading is the name given to the process by which a binary form of a class is obtained + by the Java Virtual Machine. Java classes are always loaded and linked dynamically by the Java Virtual Machine (rather than statically by the compiler).

@@ -251,7 +251,7 @@ In practical development terms: This means that the developer has no certain knowledge about the actual bytecode that will be used to execute any external call (one made outside the class). This is determined only - at execution time and is effected by the way that the code is deployed. + at execution time and is affected by the way that the code is deployed.

@@ -272,7 +272,7 @@ In practical development terms: This means that different JVMs may realize that a reference cannot be resolved at different times during execution. Consequently, the actual behaviour cannot be precisely predicted without intimate knowledge of the JVM (on which the bytecode will be executed). - This makes it hard to give universal guildance to users. + This makes it hard to give universal guidance to users.

@@ -300,7 +300,7 @@

(VMSPEC 5.3) The bootstrap is the base ClassLoader supplied by the Java Virtual Machine. - All others are user (also known as application) ClassLoader's. + All others are user (also known as application) ClassLoader instances.

@@ -314,7 +314,7 @@

(VMSpec 5.3) - At runtime, a class (or interface) is determined by it's fully qualified name + At runtime, a class (or interface) is determined by its fully qualified name and by the classloader that defines it. This is known as the class's runtime package.

@@ -328,7 +328,7 @@ two classes with the same fully qualified name are found to be incompatible during a method call. This may happen when a member is expecting an interface which is (seemingly) implemented by a class but the class is in a different runtime package after being defined by a different classloader. This is a - fundemental java language security feature. + fundamental java language security feature.

@@ -379,8 +379,8 @@

When a classloader is asked to load a class, a question presents itself: should it immediately - delegate the loading to it's parent (and thus only define those classes not defined by it's parent) - or should it try to define it first itself (and only delegate to it's parent those classes it does + delegate the loading to its parent (and thus only define those classes not defined by its parent) + or should it try to define it first itself (and only delegate to its parent those classes it does not itself define). Classloaders which universally adopt the first approach are termed parent-first and the second child-first.

@@ -434,7 +434,7 @@

Java 1.2 introduces a mechanism which allows code to access classloaders which are not the class classloader or one of its parents. - A thread may have a class loader associated with it by it's creator for use + A thread may have a class loader associated with it by its creator for use by code running in the thread when loading resources and classes. This classloader is accessed by the getContextClassLoader method on Thread. It is therefore often known as the context classloader. @@ -655,4 +655,4 @@ href='http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com - \ No newline at end of file +