home *** CD-ROM | disk | FTP | other *** search
-
- ============================================================================
-
- VisualAge for Java
- Version 1.0
-
- <Java Compiler and Class Loader>
-
- RELEASE NOTES
-
- ============================================================================
-
- Table of Contents
-
- 1.0 Incremental Compilation
- 1.1 Problem Handling
- 2.0 Java 1.1 Language Features
- 3.0 Class File Support
- 4.0 Java Native Interface (JNI)
- 4.1 JNI on OS/2
- 5.0 Limitations and Known Defects
-
-
- 1.0 Incremental Compilation
-
- VisualAge for Java supports incremental compilation. Incremental
- compilation allows the developer to see the effects of his/her changes
- as they are made, rather than explicitly invoking the compiler periodically
- to find the problems that have been introduced during the last edit cycle.
- In addition to compiling the method that the developer has just changed,
- any methods that are impacted by this change are also automatically
- recompiled. Changing (or adding or deleting) a class definition also
- triggers this automatic recompilation. As a result, binary compatibility
- is automatically ensured by the compiler for any program implemented
- within our environment.
-
- These incremental changes take effect immediately. A thread that is
- iteratively invoking a method will immediately get the new method. Code may
- be changed in the debugger as well; any change in the debugger takes effect
- upon completion of the edit and save.
-
- 1.1 Problem Handling
-
- All problems that are detected are classified as either warnings or errors.
- Warnings are reported on problems that can easily be ignored by the
- compiler, without changing the semantics of the developer's program. The
- existence of a warning does not effect the execution of the program; the code
- will execute as if it were written correctly (e.g. detecting unreachable code
- does not prevent from being able to run it). Errors are more severe problems
- that cannot be ignored since the semantics of the program is corrupted, and
- therefore its execution cannot complete. If there is an error in the
- method, a debugger will be displayed with a stack trace containing the
- problem method. If there is an initialization problem, the problem class will
- be in the stack trace. A method with an error cannot be executed until
- the error is fixed.
-
- The VisualAge for Java compiler detects problems in several phases (e.g.
- parsing, type checking, code generation, ...). Proceeding to the next
- phase is allowed as long as no error has been detected so far. Thus
- errors detected in some phases cause the compilation process to be aborted.
- Therefore, fixing a compilation problem may reveal other previously unreported
- problems.
-
- Some problems are more serious than others. If a class subclasses a
- nonexistent class for example, VisualAge for Java cannot create instances
- of this class. It is also difficult to accurately compile methods when
- much of the context is unavailable. Under these conditions, the compiler
- simply verifies that the methods are syntactically valid. Later, when
- the missing classes and interfaces are available, the methods will be
- fully compiled automatically.
-
- Classes must be syntactically correct in order for the compiler to accept
- them; however methods only need a syntactically valid method header.
- Such a method will be recorded in the workspace and can be invoked by
- other methods. When/if this method is executed, a debugger will be
- displayed. The method can be changed in either the debugger or any
- code browser.
-
-
- 2.0 Java 1.1 Language Features
-
- VisualAge for Java 1.0 supports all of the Java 1.1 language features
- except nested classes. In particular, neither inner classes nor anonymous
- classes are supported. Importing Java source that uses nested classes will
- result in a parse error. Importing .class files that use nested classes
- will work correctly. However, the classes will not be easily accessible
- from Java source, since the only way to refer to the nested class is by
- its mangled name. Anonymous classes or inner classes will not be
- distinguishable from regularly defined classes; they will be treated as
- top-level classes with exotic names. Until support is provided, the best
- way to work with Java 1.1 nested classes is to compile them with JDK and
- import them as .class files.
-
- The following Java 1.1 language features are supported:
- 1. Method parameters and local variables may be declared final.
- 2. Object initializers may be defined for any class. Object
- initializers are similar to static initializers, but are executed just
- before the constructor body is executed.
- 3. Final fields may be defined with initialization values. The compiler
- will ensure that those final blank fields get initialized exactly once by
- the program (in initializers or constructors).
- 4. The class keyword may be used to access the Class Object for
- a given type. For example, the expression Object.class will answer the
- Class object for the type Object.
- 5. C implementations for native methods can be written using the new
- Java Native Interface (JNI). See section 5.0 for additional notes on JNI.
-
-
- 3.0 Class File Support
-
- VisualAge for Java 1.0 allows a developer to write Java programs. Some
- programs are built using pre-constructed class libraries. VisualAge
- for Java allows these pre-compiled programs to be imported and used.
- VisualAge for Java treats classes derived from .class files as immutable.
- In order to change a class from a .class file, the developer must reload
- the source version of the class, and then apply the change.
-
- There are a few other limitations in classes derived from .class files.
- These limitations and related notes are enumerated below.
-
- There is no support for unicode names (class names, field names, method
- names). Any .class file containing unicode names will cause an error
- during the import process.
-
- VisualAge for Java 1.0 does not perform complete bytecode verification.
- A developer should only import trusted code into the workspace. JavaSoft
- provides a tool (javap) that can be used to ensure that the code being
- imported into the environment is valid.
-
- Any references to methods or fields from within classes derived from
- .class files are checked by the compiler incrementally like regular
- source programs. If an API used by a method derived from a .class file is
- changed, the method will be reanalyzed during incremental compilation to
- detect and report problems introduced by the change.
-
-
- 4.0 Java Native Interface (JNI)
-
- C implementations for native methods can be written using the JNI. Please
- refer to the JNI specification for complete information. VisualAge for
- Java 1.0 implements a subset of the JNI. The following functions in the
- JNI API are not implemented. Calling any of these API results in a
- NoSuchMethodError exception:
-
- DefineClass
- ExceptionDescribe
- FatalError
- RegisterNatives
- UnregisterNatives
- MonitorEnter
- MonitorExit
- GetJavaVM
-
- 4.1 JNI on OS/2
-
- JNI on OS/2 requires IBM VisualAge C++ for OS/2, Version 3 CSD level CTC306
- or later. The following system error, which prematurely terminates the IDE,
- may occur with prior CSD levels of the C compiler when a JNI native C
- implementation contains a printf() and the console output is not redirected
- (i.e. IDE > trace):
-
- OS/2 - SYS-147
-
-
- 5.0 Limitations and Known Defects
-
- The following limitations have been discovered during evaluation of Visual
- Age for Java 1.0.
-
- There is no support for Unicode names. Any attempt to use Unicode
- names results in parse errors or import errors. Unicode escape sequences
- may be used to define string or character literals. However, unicode
- escapes are not recognized anywhere else.
-
- According to Java language specification, String and character literals may
- not have embedded CR or LF characters. This problem is usually reported as
- a warning. However, if this condition occurs in a static final field with
- a constant expression initializer, the error is not reported.
-
- It is a compile-time error for a constructor to directly or
- indirectly invoke itself through a series of one or more explicit
- constructor invocations involving this (JLS 8.6.5). Only the direct
- invocation case is detected in the current implementation.
-
- It is a compile-time error to cast an interface T to an interface S
- if S and T contain methods with the same signature but different
- return types (JLS 5.5). We do not detect this error at compile time,
- but rather detect it at runtime, and throw a class cast exception.
-
- During source file import, class and method collisions are silently
- ignored. The definition latest in the file is used. This also occurs
- if the class definition contains two definitions of a single method.
- This can also be caused unchecking the "skip .class files" box, and
- then importing both a .class file and a .java file containing the
- same class definition.
-
- When exporting code, the ordering of methods may not be the same as
- during the initial import, nor the previous export, thus no assumption
- should be made on the method ordering in exported source files or class
- files. Field ordering is preserved.
-
- The float type is emulated in VisualAge for Java 1.0. The result of
- the emulation is that floats have more precision that specified. Therefore,
- the following expressions will answer false (unexpectedly):
- Float.MIN_VALUE / 2.0f == 0.0f
- Float.MAX_VALUE * 2 == 1.0f / 0.0f
-
- Classes defined in a default package are only visible within the default
- package. There is no way to access these classes from outside of the
- default package.
-
- Any exception thrown inside a try block must be handled by a matching
- catch blocks or method throws declarations. However, we incorrectly report
- an error on the following pattern of code, where the uncaught exception
- is never actually thrown due to the abruptly completing finally clause:
-
- void f () throws java.io.IOException {
- try {
- throw Exception();
- } finally {
- throw new java.io.IOException(); // complete abruptly
- }
- }
-
- Empty statements are ignored. Therefore the compiler does not report
- unreachable code errors on unreachable empty statements. The following
- methods exhibits this behavior:
-
- void f () {
- return;
- label: ;
- }
-
- void g () {
- return;
- ;;;;;
- }
-
- In addition, semicolons are silently ignored when included in an class
- definition. Therefore the compiler accepts without complaint the following
- class definition
-
- class C {
- ;;;;
- }
-
- Some problems reported on classes do not provide source highlighting. For
- the problems, deduce the effected type and find it in the class definition
- source.
-
- Breakpoints cannot be inserted at the end of a block. If it is necessary
- to break at the end of a block, insert the following statement where
- the break is desired:
- uvm.tools.DebugSupport.halt();
-
- If some reported problems appear to be lost during incremental compilation,
- one of two events has occurred:
- 1. The problems have been superceded by more significant errors and
- just discarded. If the more serious errors are resolved, these problems
- will return.
- 2. A field initialization problem was detected and reported against
- the constructor. When such a constructor is saved, the problem report
- is "credited" to the class and no longer kept with the constructor.
-
- Some error messages that occur while loading classes are written to the
- log. Please look at the log for additional information if the failure
- message is uninformative.
-
- When a package or class is copied or renamed, qualified references to the
- changed package or class are not edited. Rather problems are reported
- to show the developer where the code must be changed.
-
- Packages that are imported into an existing project remain, even if the
- operation is aborted. The developer may explicitly delete these empty
- packages.
-
- Project names may only include alphanumeric characters, underscore ("_"),
- or spaces. No other characters are permitted.
-
- An import of a simple name is ignored. No errors are detected
- or reported, and the import is ignored during name resolution.
-
- If a method has a qualified reference to a field that is changed from
- not visible to visible, this method may continue to report the original
- problem. Recompiling the method will remove the superfluous problem
- report.
-
- The algorithm responsible for detecting unitialized blank final fields
- will usually get confused by the presence of loop constructions preceding
- the actual field initializations, either in constructors or initializers. As
- a result, the compiler will incorrectly report that some blank final fields
- may not have been initialized, though they actually are. Note that the
- detection for multiple assignments of final blank fields or variables is not
- affected by the same symptoms. On this example, field 'bar' will not be
- recognized as having been initialized.
-
- public WrongDiagnosis {
- final int foo, bar;
- public WrongDiagnosis() {
- foo = 1;
- while(false) { }
- bar = 2; // Not recognized as properly set.
- }
- }