Language Selection

DRAFT
Why Java? What are the advantages of using Java over other languages such as C++? Both Java and C++ are based syntactically on the C language. They even share a lot of the same key word extensions. They both support object oriented constructs. They are however different in very key ways. One of the biggest strengths of C is its relatively low level. For those of us in the industry, it is essentially a glorified assembler. And rightly so. It was designed to write an operating system, where effeciency is crucial. Just because it made an excellent language for writing system software, does not mean it is necessarily the ideal language for writing business applications. Some key points which make it ideal for system software include precise control over memory management. For large business applications written by teams of perhaps inexperienced programmers, the requirement to manage memory was in practice too often neglected, with dire consequences. The use of arithetic on pointers is a very efficient technique, if platform specific. However, novice programmers are prone to misuse the feature and the memory corruption that results often wastes a great deal of time in debugging. More subtle problems are likely to escape testing, and cause havoc once the code reaches production. Lack of diligence in designing the memory management aspects of a system, often resulted in poorly performing bloated applications which became unstable proportional to the length of time run. C++ shares this heritage with C. It too can be used to write very tight, efficient code, although it is not quite as good at it as its predecessor. In practice, however, most C++ code has been poorly designed and has not realized the objective of increased code reuse. It also suffers from the same pointer and memory management issues as does C. C++ syntax has also varied widely across the platforms that support it. Java shares syntactically with C, but does away with the requirement to manually manage memory. Once memory is unused, a background thread marks it as free, without the programmer being aware of it. As well, pointer arithmetic is not possible, so to eliminate one more class of frequent application errors. Java also, supports single inheritance. C++ multiple inheritance was deemed too complex in practice, and resulted in code which was too difficult to maintain. Instead of allowing multiple inheritance, Java provides for the definition of interfaces, a much more maintainable construct. Java nearly succeeds at the cross platform portability objective, unlike C++. With newer versions of the JDK it should be quite trivial to produce software which will run on any of the popular platforms, from the UNIX power user down to the common Windows desktop. What makes this possible, in part, is the fact that Java comes with a consistent set of powerful class libraries across all supported platforms. These include GUI components, data structure and container classes, and internet support classes. Very few platform differences need to be dealt with at the application program level. The availability of these classes in addition to the structure and conventions that they impose on the developer, results in the increased productivity of the application programmer. Several studies have concluded that projects which were implemented using Java were anywhere from twice to twenty times as fast as an equivalent written in C. On average, it takes about one-quarter as long to bring an application written in Java to market. This is an important point to consider when recouping R&D dollars. Java is also compiled down to psuedo machine code, which is then executed by a virtual machine. That is that although it is not able to optimize each class for the machine that it will run on, all object files are indeed containing the same object code regardless of where they are compiled. Optimisation takes place at run time, in such an environment. Java has significant downsides: it is slower than the equivalent C application and it requires significantly more memory to run. These might be less of an issue a few years from now, but it has hampered the ability for developers to target the existing PC install base until now. In general, one should allow an additional 64meg of real memory per Java application that one intends to run. Relying on virtual memory will significantly delay loading. In my experience Java performance issues have primarily been caused by one of two situations. Firstly, the latency related to program startup. Java tends to be big and it takes time to initialize the VM and get the appropriate classes loaded and executing. Once running, a properly coded Java application does not run significantly slower than an equivalent application written in C++. In fact, a good JIT will cause some Java applications to outperform C++ due to its ability to perform runtime optimizations. If runtime optimizations are not interesting to a situation, it is possible to compile Java down to machine dependent executables to reduce the Java VM startup latency. The other problem with Java performance has been the misuse of object orientation (OO). OO offers some very powerful constructs, but object instantiation and destruction are significant overheads. These overheads exist in all OO supportive languages, including C++ -- the specific behaviours will vary from language to language. The programmer must be cognizant of the lifespan of the objects that they are using when they implement a design, otherwise the resulting application might end up needlessly creating and/or destroying objects at perhaps the least opportune time.

DRAFT

Why Java?

What are the advantages of using Java over other languages such as C++?

Both Java and C++ are based syntactically on the C language. They even share a lot of the same key word extensions. They both support object oriented constructs. They are however different in very key ways.

One of the biggest strengths of C is its relatively low level. For those of us in the industry, it is essentially a glorified assembler. And rightly so. It was designed to write an operating system, where effeciency is crucial.

Just because it made an excellent language for writing system software, does not mean it is necessarily the ideal language for writing business applications. Some key points which make it ideal for system software include precise control over memory management. For large business applications written by teams of perhaps inexperienced programmers, the requirement to manage memory was in practice too often neglected, with dire consequences.

The use of arithetic on pointers is a very efficient technique, if platform specific. However, novice programmers are prone to misuse the feature and the memory corruption that results often wastes a great deal of time in debugging. More subtle problems are likely to escape testing, and cause havoc once the code reaches production.

Lack of diligence in designing the memory management aspects of a system, often resulted in poorly performing bloated applications which became unstable proportional to the length of time run.

C++ shares this heritage with C. It too can be used to write very tight, efficient code, although it is not quite as good at it as its predecessor. In practice, however, most C++ code has been poorly designed and has not realized the objective of increased code reuse. It also suffers from the same pointer and memory management issues as does C. C++ syntax has also varied widely across the platforms that support it.

Java shares syntactically with C, but does away with the requirement to manually manage memory. Once memory is unused, a background thread marks it as free, without the programmer being aware of it. As well, pointer arithmetic is not possible, so to eliminate one more class of frequent application errors.

Java also, supports single inheritance. C++ multiple inheritance was deemed too complex in practice, and resulted in code which was too difficult to maintain. Instead of allowing multiple inheritance, Java provides for the definition of interfaces, a much more maintainable construct.

Java nearly succeeds at the cross platform portability objective, unlike C++. With newer versions of the JDK it should be quite trivial to produce software which will run on any of the popular platforms, from the UNIX power user down to the common Windows desktop.

What makes this possible, in part, is the fact that Java comes with a consistent set of powerful class libraries across all supported platforms. These include GUI components, data structure and container classes, and internet support classes. Very few platform differences need to be dealt with at the application program level.

The availability of these classes in addition to the structure and conventions that they impose on the developer, results in the increased productivity of the application programmer. Several studies have concluded that projects which were implemented using Java were anywhere from twice to twenty times as fast as an equivalent written in C. On average, it takes about one-quarter as long to bring an application written in Java to market. This is an important point to consider when recouping R&D dollars.

Java is also compiled down to psuedo machine code, which is then executed by a virtual machine. That is that although it is not able to optimize each class for the machine that it will run on, all object files are indeed containing the same object code regardless of where they are compiled. Optimisation takes place at run time, in such an environment.

Java has significant downsides: it is slower than the equivalent C application and it requires significantly more memory to run. These might be less of an issue a few years from now, but it has hampered the ability for developers to target the existing PC install base until now. In general, one should allow an additional 64meg of real memory per Java application that one intends to run. Relying on virtual memory will significantly delay loading.

In my experience Java performance issues have primarily been caused by one of two situations. Firstly, the latency related to program startup. Java tends to be big and it takes time to initialize the VM and get the appropriate classes loaded and executing. Once running, a properly coded Java application does not run significantly slower than an equivalent application written in C++. In fact, a good JIT will cause some Java applications to outperform C++ due to its ability to perform runtime optimizations. If runtime optimizations are not interesting to a situation, it is possible to compile Java down to machine dependent executables to reduce the Java VM startup latency.

The other problem with Java performance has been the misuse of object orientation (OO). OO offers some very powerful constructs, but object instantiation and destruction are significant overheads. These overheads exist in all OO supportive languages, including C++ -- the specific behaviours will vary from language to language. The programmer must be cognizant of the lifespan of the objects that they are using when they implement a design, otherwise the resulting application might end up needlessly creating and/or destroying objects at perhaps the least opportune time.