Annotated edit history of
JavaDebuggingHints version 2, including all changes.
View license author blame.
| Rev |
Author |
# |
Line |
| 2 |
AristotlePagaltzis |
1 |
[Java] is immunne some of the [Stack] and [Heap] overwriting issues that arise in languages such as [AssemblyLanguage], [C] and [C++] and described on the excellent AdvancedDebuggingHints page. There are, however, a different set of common issues that arise: |
| 1 |
StuartYeates |
2 |
|
| 2 |
AristotlePagaltzis |
3 |
!! Threading |
| 1 |
StuartYeates |
4 |
|
| 2 |
AristotlePagaltzis |
5 |
All [Java] [GUI] programs are MultiThreaded, with at least a thread for each window, a thread for the GarbageCollection, a main thread, as well as those explicitly started. Testing such programs is non-trivial. Typically the solution is to have data accessed through accessors (small methods / functions which get or set data values) and have these accessors perform locking on the data. Most [JVM]s output significant information when a deadlock occurs and this can enable debugging. |
| 1 |
StuartYeates |
6 |
|
| 2 |
AristotlePagaltzis |
7 |
!! Internationalisation |
| 1 |
StuartYeates |
8 |
|
| 2 |
AristotlePagaltzis |
9 |
Java uses [Unicode] throughout and bad habits learnt with [ASCII], and which work for English [Unicode], break completely when you encountered real [Unicode]. Generally any single quoted characters ('c') need to be looked at very closely. |
| 1 |
StuartYeates |
10 |
|
| 2 |
AristotlePagaltzis |
11 |
!! GarbageCollection |
| 1 |
StuartYeates |
12 |
|
| 2 |
AristotlePagaltzis |
13 |
GarbageCollection systems and algorithms can have bugs, but the systems in most [JVM]s are mature and stable. Unless you're doing incredible numbers of calls to [JNI] code, the bug is almost certainly in your code. Several of the [JVM]s provide memory [Profiling] which appears to be useful in a significant number of non-pathological cases. |
