home *** CD-ROM | disk | FTP | other *** search
/ Programming with VisualAge for Java / IBMVJAVA.ISO / vajwin / data1.cab / Ide / relnotes / jib.txt < prev    next >
Encoding:
Text File  |  1997-07-04  |  13.1 KB  |  304 lines

  1.  
  2. ============================================================================
  3.  
  4.                         VisualAge for Java
  5.                            Version 1.0
  6.  
  7.                         <Java Compiler and Class Loader>
  8.  
  9.                           RELEASE NOTES
  10.  
  11. ============================================================================
  12.  
  13. Table of Contents
  14.  
  15. 1.0 Incremental Compilation
  16.    1.1 Problem Handling
  17. 2.0 Java 1.1 Language Features
  18. 3.0 Class File Support
  19. 4.0 Java Native Interface (JNI)
  20.    4.1 JNI on OS/2
  21. 5.0 Limitations and Known Defects
  22.  
  23.  
  24. 1.0 Incremental Compilation
  25.  
  26. VisualAge for Java supports incremental compilation.  Incremental
  27. compilation allows the developer to see the effects of his/her changes
  28. as they are made, rather than explicitly invoking the compiler periodically
  29. to find the problems that have been introduced during the last edit cycle.
  30. In addition to compiling the method that the developer has just changed,
  31. any methods that are impacted by this change are also automatically
  32. recompiled.  Changing (or adding or deleting) a class definition also
  33. triggers this automatic recompilation.  As a result, binary compatibility 
  34. is automatically ensured by the compiler for any program implemented
  35. within our environment.
  36.  
  37. These incremental changes take effect immediately.  A thread that is 
  38. iteratively invoking a method will immediately get the new method.  Code may
  39. be changed in the debugger as well; any change in the debugger takes effect 
  40. upon completion of the edit and save.
  41.  
  42. 1.1 Problem Handling
  43.  
  44. All problems that are detected are classified as either warnings or errors.
  45. Warnings are reported on problems that can easily be ignored by the
  46. compiler, without changing the semantics of the developer's program.  The 
  47. existence of a warning does not effect the execution of the program; the code
  48. will execute as if it were written correctly (e.g. detecting unreachable code 
  49. does not prevent from being able to run it).  Errors are more severe problems
  50. that cannot be ignored since the semantics of the program is corrupted, and
  51. therefore its execution cannot complete.  If there is an error in the
  52. method, a debugger will be displayed with a stack trace containing the
  53. problem method. If there is an initialization problem, the problem class will
  54. be in the stack trace. A method with an error cannot be executed until
  55. the error is fixed.
  56.  
  57. The VisualAge for Java compiler detects problems in several phases (e.g. 
  58. parsing, type checking, code generation, ...).  Proceeding to the next
  59. phase is allowed as long as no error has been detected so far.  Thus
  60. errors detected in some phases cause the compilation process to be aborted.
  61. Therefore, fixing a compilation problem may reveal other previously unreported 
  62. problems.
  63.  
  64. Some problems are more serious than others.  If a class subclasses a
  65. nonexistent class for example, VisualAge for Java cannot create instances
  66. of this class.  It is also difficult to accurately compile methods when
  67. much of the context is unavailable.  Under these conditions, the compiler
  68. simply verifies that the methods are syntactically valid.  Later, when
  69. the missing classes and interfaces are available, the methods will be
  70. fully compiled automatically.
  71.  
  72. Classes must be syntactically correct in order for the compiler to accept
  73. them;  however methods only need a syntactically valid method header.  
  74. Such a method will be recorded in the workspace and can be invoked by
  75. other methods.  When/if this method is executed, a debugger will be
  76. displayed.  The method can be changed in either the debugger or any
  77. code browser.
  78.  
  79.  
  80. 2.0 Java 1.1 Language Features
  81.  
  82. VisualAge for Java 1.0 supports all of the Java 1.1 language features 
  83. except nested classes.  In particular, neither inner classes nor anonymous 
  84. classes are supported. Importing Java source that uses nested classes will 
  85. result in a parse error.  Importing .class files that use nested classes 
  86. will work correctly.  However, the classes will not be easily accessible
  87. from Java source, since the only way to refer to the nested class is by 
  88. its mangled name.  Anonymous classes or inner classes will not be
  89. distinguishable from regularly defined classes; they will be treated as 
  90. top-level classes with exotic names.  Until support is provided, the best
  91. way to work with Java 1.1 nested classes is to compile them with JDK and 
  92. import them as .class files.
  93.  
  94. The following Java 1.1 language features are supported:
  95.    1.  Method parameters and local variables may be declared final.
  96.    2.  Object initializers may be defined for any class.  Object 
  97. initializers are similar to static initializers, but are executed just 
  98. before the constructor body is executed.
  99.    3. Final fields may be defined with initialization values. The compiler 
  100. will ensure that those final blank fields get initialized exactly once by
  101. the program (in initializers or constructors).
  102.    4.  The class keyword may be used to access the Class Object for
  103. a given type. For example, the expression Object.class will answer the 
  104. Class object for the type Object.
  105.    5.  C implementations for native methods can be written using the new
  106. Java Native Interface (JNI).  See section 5.0 for additional notes on JNI.
  107.  
  108.  
  109. 3.0 Class File Support
  110.  
  111. VisualAge for Java 1.0 allows a developer to write Java programs.  Some
  112. programs are built using pre-constructed class libraries.  VisualAge
  113. for Java allows these pre-compiled programs to be imported and used.
  114. VisualAge for Java treats classes derived from .class files as immutable.
  115. In order to change a class from a .class file, the developer must reload 
  116. the source version of the class, and then apply the change.
  117.  
  118. There are a few other limitations in classes derived from .class files.
  119. These limitations and related notes are enumerated below.
  120.  
  121. There is no support for unicode names (class names, field names, method
  122. names).  Any .class file containing unicode names will cause an error
  123. during the import process.
  124.  
  125. VisualAge for Java 1.0 does not perform complete bytecode verification.
  126. A developer should only import trusted code into the workspace.  JavaSoft
  127. provides a tool (javap) that can be used to ensure that the code being
  128. imported into the environment is valid.  
  129.  
  130. Any references to methods or fields from within classes derived from 
  131. .class files are checked by the compiler incrementally like regular
  132. source programs.  If an API used by a method derived from a .class file is 
  133. changed, the method will be reanalyzed during incremental compilation to 
  134. detect and report problems introduced by the change. 
  135.  
  136.  
  137. 4.0 Java Native Interface (JNI)
  138.  
  139. C implementations for native methods can be written using the JNI.  Please
  140. refer to the JNI specification for complete information.  VisualAge for
  141. Java 1.0 implements a subset of the JNI.  The following functions in the
  142. JNI API are not implemented. Calling any of these API results in a 
  143. NoSuchMethodError exception:
  144.  
  145.    DefineClass
  146.    ExceptionDescribe
  147.    FatalError
  148.    RegisterNatives
  149.    UnregisterNatives
  150.    MonitorEnter
  151.    MonitorExit
  152.    GetJavaVM
  153.  
  154. 4.1 JNI on OS/2
  155.  
  156. JNI on OS/2 requires IBM VisualAge C++ for OS/2, Version 3 CSD level CTC306
  157. or later.  The following system error, which prematurely terminates the IDE,
  158. may occur with prior CSD levels of the C compiler when a JNI native C 
  159. implementation contains a printf() and the console output is not redirected
  160. (i.e. IDE > trace):
  161.  
  162. OS/2 - SYS-147
  163.  
  164.  
  165. 5.0 Limitations and Known Defects
  166.  
  167. The following limitations have been discovered during evaluation of Visual
  168. Age for Java 1.0.  
  169.  
  170. There is no support for Unicode names. Any attempt to use Unicode
  171. names results in parse errors or import errors. Unicode escape sequences
  172. may be used to define string or character literals.  However, unicode
  173. escapes are not recognized anywhere else.
  174.  
  175. According to Java language specification, String and character literals may 
  176. not have embedded CR or LF characters. This problem is usually reported as 
  177. a warning.  However, if this condition occurs in a static final field with 
  178. a constant expression initializer, the error is not reported.
  179.  
  180. It is a compile-time error for a constructor to directly or
  181. indirectly invoke itself through a series of one or more explicit
  182. constructor invocations involving this (JLS 8.6.5). Only the direct
  183. invocation case is detected in the current implementation. 
  184.  
  185. It is a compile-time error to cast an interface T to an interface S
  186. if S and T contain methods with the same signature but different
  187. return types (JLS 5.5). We do not detect this error at compile time,
  188. but rather detect it at runtime, and throw a class cast exception. 
  189.  
  190. During source file import, class and method collisions are silently
  191. ignored.  The definition latest in the file is used.  This also occurs 
  192. if the class definition contains two definitions of a single method.
  193. This can also be caused unchecking the "skip .class files" box, and
  194. then importing both a .class file and a .java file containing the
  195. same class definition.
  196.  
  197. When exporting code, the ordering of methods may not be the same as
  198. during the initial import, nor the previous export, thus no assumption
  199. should be made on the method ordering in exported source files or class
  200. files.  Field ordering is preserved.
  201.  
  202. The float type is emulated in VisualAge for Java 1.0.  The result of
  203. the emulation is that floats have more precision that specified.  Therefore,
  204. the following expressions will answer false (unexpectedly):
  205.    Float.MIN_VALUE / 2.0f == 0.0f
  206.    Float.MAX_VALUE * 2 == 1.0f / 0.0f
  207.  
  208. Classes defined in a default package are only visible within the default
  209. package.  There is no way to access these classes from outside of the
  210. default package.
  211.  
  212. Any exception thrown inside a try block must be handled by a matching
  213. catch blocks or method throws declarations. However, we incorrectly report 
  214. an error on the following pattern of code, where the uncaught exception 
  215. is never actually thrown due to the abruptly completing finally clause:
  216.  
  217. void f () throws java.io.IOException {
  218.    try {
  219.       throw Exception();
  220.    } finally {
  221.       throw new java.io.IOException(); // complete abruptly
  222.    }
  223. }
  224.  
  225. Empty statements are ignored.  Therefore the compiler does not report 
  226. unreachable code errors on unreachable empty statements.  The following
  227. methods exhibits this behavior:
  228.  
  229. void f () {
  230.    return;
  231.    label: ;
  232. }
  233.  
  234. void g () {
  235.    return;
  236.    ;;;;;
  237. }
  238.  
  239. In addition, semicolons are silently ignored when included in an class
  240. definition.  Therefore the compiler accepts without complaint the following
  241. class definition
  242.  
  243. class C {
  244.    ;;;;
  245. }
  246.  
  247. Some problems reported on classes do not provide source highlighting.  For
  248. the problems, deduce the effected type and find it in the class definition
  249. source.
  250.  
  251. Breakpoints cannot be inserted at the end of a block.  If it is necessary
  252. to break at the end of a block, insert the following statement where
  253. the break is desired:
  254.    uvm.tools.DebugSupport.halt();
  255.  
  256. If some reported problems appear to be lost during incremental compilation,
  257. one of two events has occurred:
  258.    1. The problems have been superceded by more significant errors and
  259. just discarded.  If the more serious errors are resolved, these problems
  260. will return.
  261.    2.  A field initialization problem was detected and reported against 
  262. the constructor.  When such a constructor is saved, the problem report
  263. is "credited" to the class and no longer kept with the constructor.
  264.  
  265. Some error messages that occur while loading classes are written to the 
  266. log.  Please look at the log for additional information if the failure 
  267. message is uninformative.
  268.  
  269. When a package or class is copied or renamed, qualified references to the 
  270. changed package or class are not edited.  Rather problems are reported
  271. to show the developer where the code must be changed.
  272.  
  273. Packages that are imported into an existing project remain, even if the
  274. operation is aborted.  The developer may explicitly delete these empty
  275. packages.
  276.  
  277. Project names may only include alphanumeric characters, underscore ("_"),
  278. or spaces.  No other characters are permitted.
  279.  
  280. An import of a simple name is ignored.  No errors are detected
  281. or reported, and the import is ignored during name resolution.
  282.  
  283. If a method has a qualified reference to a field that is changed from
  284. not visible to visible, this method may continue to report the original
  285. problem.  Recompiling the method will remove the superfluous problem
  286. report.
  287.  
  288. The algorithm responsible for detecting unitialized blank final fields 
  289. will usually get confused by the presence of loop constructions preceding
  290. the actual field initializations, either in constructors or initializers. As 
  291. a result, the compiler will incorrectly report that some blank final fields 
  292. may not have been initialized, though they actually are. Note that the 
  293. detection for multiple assignments of final blank fields or variables is not 
  294. affected by the same symptoms.  On this example, field 'bar' will not be 
  295. recognized as having been initialized.
  296.  
  297. public WrongDiagnosis {
  298.    final int foo, bar;
  299.    public WrongDiagnosis() {
  300.       foo = 1;
  301.       while(false) { }
  302.       bar = 2;        // Not recognized as properly set.
  303.    }
  304. }