Programming with VisualAge for Java/IBMVJAVA.ISO/vajwin/data1.cab/Ide/relnotes/jib.txt

Text File | 1997-07-04 | 13.1 KB | 304 lines

============================================================================

                        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.
   }
}