JavaTM development tools (JDT) - release notes
1.0 Introduction
2.0 Known problems and limitations
2.1
Running Java programs with non-Latin-1 characters in package or class names
2.2 Missing debug attributes
2.3 Setting breakpoints
2.4 Using Hot code
replace
2.5 Scrapbook
2.6 Debugging over slow connections
2.7 Updating of inspected values
2.8
Stepping over native methods that perform I/O
2.9 Searching for constant field references
2.10
Java compilation units outside of the build class path
2.11 Actions to modify read-only files
2.12 Java code templates
2.13 Organize import and imports from default packages
2.14 Add Javadoc action for fields
2.15 Javadoc hover in the Java editor
This contains information on known problems and limitations with Java
development tools.
You may get a java.lang.NoClassDefFoundError when running Java programs
with non-Latin characters in the package or class names. To work around this, package the class files as a JAR file and run the program out of the JAR,
instead of directly from the the file system.
The debugger requires that class files be compiled with debug attributes in
order to be able to display line numbers and local variables. Quite often, class
libraries (for example, rt.jar
) are compiled without
complete debug attributes, and thus local variables and method arguments for
those classes are not visible in the debugger.
In general, the debugger will not allow you to place breakpoints on lines of code
that are not executable (comments, blank lines, and so on). However, there are some
cases where the debugger will allow breakpoints on lines of code that are not
executable. For example, the debugger will allow a breakpoint to be placed on a
variable declaration that does not contain an initializer.
Note that enabled breakpoints which are successfully installed on an executable
line in a running (debuggable) VM are displayed with a checkmark. Breakpoints
that are displayed without a checkmark are not installed in a running (debuggable)
VM.
Hot code replace is supported on JDK 1.4.x VMs, and IBMR J9 VMs. Hot code replace
is limited to changes which do not effect the shape of a class. That is, changes
within existing methods are supported, but the addition or removal of members is
not supported.
Hot code replace and stepping on JDK 1.4.0 VMs is unreliable.
Setting a breakpoint inside a scrapbook page is not supported.
When code is run in the scrapbook which directly or indirectly calls System.exit(int)
,
the evaluation cannot be completed, and will result in a stack trace for a com.sun.jdi.VMDisconnectedException
being displayed in the scrapbook editor.
Terminating a scrapbook page while it is performing an evaluation results in
a com.sun.jdi.VMDisconnectedException
being displayed in the
scrapbook editor.
A global Java debug preference specifies the debugger timeout, which is the
maximum amount of time the debugger waits for a response from the target VM
after making a request of that VM. Slow connections may require that this value
be increased. The timeout value can be edited from the Java > Debug preference
page. Changing the timeout value only effects subsequently launched VM, not VMs
that are already running.
When inspecting the result of an evaluated expression in the debugger, it is
important to note that the result displayed is the result of that expression at
the time it was evaluated. For example, when inspecting a simple integer counter
(primitive data type), the value displayed in the Expressions view is the value
when the expression was evaluated. As the counter is changed in the running
program, the inspected result will not change (since the view is not displaying
the value bound to a variable - it is displaying the value of an expression, and
the value of a primitive data type cannot change). However, if an expression
results in an object, fields of that object will be updated in the inspector as
they change in the running program (since the value bound to fields in an object
can change).
When the debugger steps over native methods that perform I/O to System.out
or System.err
, the output may not appear immediately unless the
native performs a flush on the output buffer.
Search does not find references to constant fields inside binaries because the
Java Language Specification mandates that constant field values be inlined in
the class file's bytecodes, leaving no trace of a field reference
When a compilation unit with compilation problems is moved outside the Java
build class path, it retains its Java problems forever (its compilation problem
list does not get refreshed because it will never be compiled again). Renaming a
*.java file to one with another a different file extension suffix causes the
same problem.
Actions on the Source menu (e.g., Generate Getter and Setter) are
always disabled when the file is read-only. This is currently true even when the
repository provider supports automatically checking out files on modification.
You cannot use ${CURSOR}
inside of a comment in a Java code
template (Window > Preferences > Java > Templates).
Organize import does not handle imports from default packages. Note that
importing from a default package is no longer supported in JDK 1.4.
The Add Javadoc action does not work for fields.
The Javadoc hover help shown when hovering over identifiers in the Java
editor does not handle links inside of Javadoc comments properly.
Return
to the main readme file
