Quote:
Originally Posted by DMcCunney
One of the biggest problems in programming has been the need to allocate memory used by your application, and free it again once done. In C, for example, you use malloc to do it, and it's on you to handle the case where there isn't enough memory available and fail gracefully.
|
Or if you're on an OS like Linux with VM and deferred physical page allocation, you may find that malloc returns a valid, non-NULL pointer but the app faults with an out-of-memory condition later when you try and use it.
Quote:
It's also on you to make sure the memory you allocated is properly freed when you're done with it, and "memory leaks" because this didn't happen are probably the single biggest headache for programmers. You did put in a "free" call to free the memory, but something happened and it never got executed....
In a language like Java, those details are handled for you. You can concentrate on the logic of the application, not the housekeeping required to make it work.
|
In my experience this can often lead to problems. Programmers lean too heavily on the garbage collection, and end up without a clear idea of the ownership and lifespan of their data structures. Given that memory is only one of the limited resources that a programmer needs to keep track of (sockets, file handles, various other system resources, etc. etc.), this lack of clear understanding causes issues elswhere.
Garbage collection also introduces differences in behaviour between the same Java program on different platforms.
Quote:
|
2) It's "write once, run anywhere." Java compiles to tokenized binary form called bytecode, targeted at the underlying virtual machine implemented by the JVM. The bytecode is the same, regardless of what you wrote it on. So you can take a well written Java program created on a Windows PC, compile to bytecode, and run that bytecode on a Mac, expecting it to look and behave the same.
|
"Write once, test everywhere" is perhaps a better characterisation. There is lattitude allowed to JVM implementors in areas such as threading model, garbage collection etc. which means that the behaviour of a (perhaps poorly written) Java program can vary significantly between
platforms. For example, implementations may vary widely in terms of when garbage objects are reaped and hence when, or even if, finalizers are run. Any program which has any significant work done in a finalizer is prone to portability issues.
/JB