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
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
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.
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
The object (and runtime) models are comparable, with Java’s
implementation having a subset of the functionality of that
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
Java is more widely used.
Objective-C may leverage investment already made in C based tools.
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.
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.
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
The equivalent part of the Java non-graphical API consists of about 230
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.