C. Differences and Similarities Between Objective-C, Java, and C++

This appendix explains the differences/similarities between Objective-C and Java. It does not cover the Java Interface to GNUstep (JIGS; see Programming GNUstep in Java and Guile), but is included to help people who want to learn Objective-C and know Java already.

C.1 General

• C programmers may learn Objective-C in hours (though real expertise obviously takes much longer).
• Java has global market acceptance.
• Objective-C is a compiled OO programming language.
• Java is both compiled and interpreted and therefore does not offer the same run-time performance as Objective-C.
• Objective-C features efficient, transparent Distributed Objects.
• Java features a less efficient and less transparent Remote Machine Interface.
• Objective-C has basic CORBA compatibility through official C bindings, and full compatibility through unofficial Objective-C bindings.
• Java has CORBA compatibility through official Java bindings.
• Objective-C is portable across heterogeneous networks by virtue of a near omnipresent compiler (gcc).
• Java is portable across heterogeneous networks by using client-side JVMs that are software processors or runtime environments.

C.2 Language

• Objective-C is a superset of the C programming language, and may be used to develop non-OO and OO programs. Objective-C provides access to scalar types, structures and to unions, whereas Java only addresses a small number of scalar types and everything else is an object. Objective-C provides zero-cost access to existing software libraries written in C, Java requires interfaces to be written and incurs runtime overheads.
• Objective-C is dynamically typed but also provides static typing. Java is statically typed, but provides type-casting mechanisms to work around some of the limitations of static typing.
• Java tools support a convention of a universal and distributed name-space for classes, where classes may be downloaded from remote systems to clients. Objective-C has no such conventions or tool support in place.
• Using Java, class definitions may not be extended or divided through the addition of logical groupings. Objective-C provides categories as a solution to this problem.
• Objective-C provides delegation (the benefits of multiple inheritance without the drawbacks) at minimal programming cost. Java requires purpose written methods for any delegation implemented.
• Java provides garbage collection for memory management. Objective-C provides manual memory management, reference counting, and garbage collection as options.
• Java provides interfaces, Objective-C provides protocols.

C.3 Source Differences

• Objective-C is based on C, and the OO extensions are comparable with those of Smalltalk. The Java syntax is based on the C++ programming language.
• The object (and runtime) models are comparable, with Java’s implementation having a subset of the functionality of that of Objective-C.

C.4 Compiler Differences

• Objective-C compilation is specific to the target system/environment, and because it is an authentic compiled language it runs at higher speeds than Java.
• Java is compiled into a byte stream or Java tokens that are interpreted by the target system, though fully compiled Java is possible.

C.5 Developer’s Workbench

• Objective-C is supported by tools such as GNUstep that provides GUI development, compilation, testing features, debugging capabilities, project management and database access. It also has numerous tools for developing projects of different types including documentation.
• Java is supported by numerous integrated development environments (IDEs) that often have their origins in C++ tools. Java has a documentation tool that parses source code and creates documentation based on program comments. There are similar features for Objective-C.
• Java is more widely used.
• Objective-C may leverage investment already made in C based tools.

C.6 Longevity

• Objective-C has been used for over ten years, and is considered to be in a stable and proven state, with minor enhancements from time to time.
• Java is evolving constantly.

C.7 Databases

• Apple’s EOF tools enable Objective-C developers to build object models from existing relational database tables. Changes in the database are automatically recognised, and there is no requirement for SQL development.
• Java uses JDBC that requires SQL development; database changes affect the Java code. This is considered inferior to EOF. Enterprise JavaBeans with container managed persistence provides a limited database capability, however this comes with much additional baggage. Other object-relational tools and APIs are being developed for Java (ca. 2004), but it is unclear which of these, if any, will become a standard.

C.8 Memory

• For object allocation Java has a fixed heap whose maximum size is set when the JVM starts and cannot be resized unless the JVM is restarted. This is considered to be a disadvantage in certain scenarios: for example, data read from databases may cause the JVM to run out of memory and to crash.
• Objective-C’s heap is managed by the OS and the runtime system. This can typically grow to consume all system memory (unless per-process limits have been registered with the OS).

C.9 Class Libraries

• Objective-C: Consistent APIs are defined by the OpenStep specification. This is implemented by GNUstep and Mac OS X Cocoa. Third-party APIs are available (called Frameworks).
• Java: APIs are defined and implemented by the Sun Java Development Kit distributions. Other providers of Java implementations (IBM, BEA, etc.) implement these as well.
• The Java APIs are complex owing to the presence of multiple layers of evolution while maintaining backwards compatibility. Collections, IO, and Windowing are all examples of replicated functionality, in which the copies are incompletely separated, requiring knowledge of both to use.
• The OpenStep API is the result of continuing evolution but backward compatibility was maintained by the presence of separate library versions. Therefore the API is clean and nonredundant. Style is consistent.
• The OpenStep non-graphical API consists of about 70 classes and about 150 functions.
• The equivalent part of the Java non-graphical API consists of about 230 classes.
• The OpenStep graphical API consists of about 120 classes and 30 functions.
• The equivalent part of the Java graphical API consists of about 450 classes.

This document was generated by Adam Fedor on December 24, 2013 using texi2html 1.82.