What is the history and the merit of the Java language?
When selecting a language for developing any new application, the
programming
staff needs to examine the language choice to optimize development
time,
reuse any existing code, exploit language traits, etc. This has been
a time-honored tradition. Let's step back about 25 years or so.
Popular languages
of that era included Fortran, which was good for scientific
applications;
APL, excellent at array manipulation and math intensive
applications;
COBOL, a business language; and the list goes on. There were
die-hard
assembly language and machine-level programmers, absolutely
possessed by speed and
performance.
The choice of the language at that time was not market-driven; it
was
based upon the application. The language that offered the best
utility and
function library was usually the choice. Programmers chose the
language;
the customer had little interest in how an application was written.
In 1978, a couple of fellows by the names of Dennis Ritchie and
Brian
Kernighan at Bell labs published the "general-purpose" language
on the
UNIX operating system. A revolution in computer languages was at
hand.
The time it took for acceptance of this language was almost 5 years.
At
this point, in 1983, the ANSI standards committee adopted a standard
for
the "C" language. Next, "C++", embracing object-oriented principles,
took
the dominant "general-purpose" title. Still, language choice was
pretty much at the discretion of the programmer. Management,
however,
seeing the benefit of common programming languages for maintenance
and easier deployment, began to order in many cases that
C or C++ be used. The end-user, too, became aware that, if C or C++
were
being used, maintenance could be done easily, because a great number
of programmers
were available that understood that base.
As C and C++ matured, the weaknesses of the languages, or the areas
that
caused the most maintenance, also became quite evident. Programmers
were
analyzing memory leaks and chasing null pointers, locked in a battle
of wits with the operating system about event management and thread
dispatching.
The end results were worth the effort, however, as compilers and
linkers
were optimized to execute the code in near-machine speed.
Programming shops in general developed expertise from the ground up,
and
in most shops there are but one or two highly-qualified experts that
can
find those nasty esoteric inter-thread system-hanging problems that
the
other programmers unknowingly put there. Most programming errors are
introduced because programs are so complex that they are written by
teams, not
by one individual who controls all the variables. If ground rules
for team
members are loose, all types of "bugs" can be introduced to the code
at
integration time that were not there during testing of individual
code segments. These "bugs" can be quite insidious, and can easily
put
projects significantly behind schedule. C++ and object-oriented
techniques
helped greatly in reducing the "bug" rate. As data and code were
encapsulated, an object became an island unto itself, and once again
one programmer
could contain all the details of one object, and the rules for
connecting objects became clear. Still, not one C++ compiler is
happy
about being able to use other C++ -compiled objects, but if
regimented
to a single development environment, things are very stable.
But, what if? What if a language removed all of the areas that
caused the
bugs? What if memory management, pointers, and thread concurrency
problems
were no longer anything a programmer had to concern himself with?
What
if the rules of object interaction were so well-defined that they
allowed
operation on any operating system without change? What if your
programmers
only had to write one source for every operating system? What if the
object-oriented paradigm that helped so much were embraced tightly?
What
if error-detection management was enforced so that programmers had
no choice
but to code in error-handling and recovery? Well...to that end, you
would
get JAVA! That is what the language does--and it does it very, very
well!
For an in-depth view of Java's most prominent features, review
Datamations
article written by Arthur van Hoff, Sami Shaio, & Orca Starbuck,
or the
that accompanies this
white
paper.
[
What Is This Thing Called Java?
@ http://www.datamation.com/PlugIn/java/03ajava7.html]
James Gosling, a Sun fellow and Vice President, did just this. He is
an expert C and C++
programmer who was challenged with making a small language for micro
devices for firmware. It was to be a "general-purpose" language. It
wasn't readily accepted for its purpose(it was called OAK in those
days), but
Gosling realized that the Web would benefit from it. The name OAK
was not
accepted because other companies were using it, so after many visits
to the
local coffee shop, the team came up with the name JAVA! Jim's
perspective on
the future of Java, Microsoft, networks, and C++ is very informative
Read about it in Datamation
magazine's interview with Jim.
[
Gosling on Java
@ http://www.datamation.com/PlugIn/java/03ajava2.html]
[xref:
Java Complete
@ http://www.datamation.com/PlugIn/java/index.html]
The bottom line? Java is a better programming language then C++.
Regardless
of the project or the target application, Java will provide better
code, code that is
faster and easier to maintain. If Java had simply been called C2++
or
C+++ and the compilers for native support had come first, no
questions
would have been asked. It would have been adopted as the new de
facto
C++ replacement, even in its first release. The fact is, though,
that it is more--
much more--and the aforementioned benefits are all gravy!
What are the Java language specifics?
OK, hype aside, let's look at Java in more technical detail. First
the merits of the language, then the extensions, support, and
tooling. Wherever
possible, links are provided to expound the details presented here.
- No Pointers... No memory management--garbage collection is automatic
- Cross Platform--full libraries, AWT, NET, IO, UTIL, LANG
- Interpreted--but not like BASIC
- Fully OOP
- Compiler forces error code and handling
- C++ Syntax--Very easy learning curve (from C++ background)
- FAST--Libraries are very inclusive! more coming...
- Compiled byte-code, secure, portable, Webable!
- JVM--28 and counting... all major operating systems
- Can wrapper C, C++, legacy code, drivers, etc., or be wrapped
- A better C++
What are JavaBeans?
JavaBeans is Java's answer to Active-X, Open-Doc, OLE/COM, SOM/DSOM,
etc. For serious
development, beans are the way to go; reuse starts at this level.
The
best definition comes in a
memo from Javasoft@http://splash.javasoft.com/beans/,
which I quote below:
Memo to Java
developers
The choice is clear: Write to JavaBeans
Throughout the industry, JavaBeans is the
component architecture of choice.
More than 400,000 developers around the world have
already embraced the Java platform. And no wonder. Java has
opened up an entirely new world of opportunities for
building fully portable network-aware applications. Yet many
developers are not yet sure how best to take advantage of
the capabilities and benefits the Java Platform delivers
without sacrificing their existing investment in legacy
applications.
The answer is JavaBeans.
JavaBeans is the platform-neutral, component architecture
for Java. It's the ideal choice for developing or assembling
network-aware solutions for heterogeneous hardware and
operating system environments--within the enterprise or
across the Internet. In fact, it's the only component
architecture you should consider if you're developing in a
Java environment.
JavaBeans extends Java's "Write Once, Run
Anywhere"SM capability to reusable component
development. In fact, JavaBeans takes interoperability a
major step forward--your code runs on every OS and also
within any application environment. A Beans developer
secures a future in the emerging network software market
without losing customers that use proprietary platforms,
because JavaBeans interoperate with ActiveX. JavaBeans
connects via bridges
The JavaBeans
specification--which was completed ahead of schedule--defines a set of
standard component software APIs for the Java platform. The
specification was developed by JavaSoft with a number of
leading industry
partners and
was then refined based on broad general input from ISVs,
customers, and end-users during a
public
review period.
into
existing industry component models such as ActiveX. Software
components that use JavaBeans APIs are thus be portable to
containers including Internet Explorer, Visual Basic,
Microsoft Word, Lotus Notes, etc.
JavaBeans allows developers to create reusable software
components that can then be assembled together using
visual
application builder tools,
such as Borland's
JBuilderTM, IBM's
Visual
AgeTM for Java,
SunSoft's Java
WorkshopTM and Symantec's
Visual
Cafe, and many,
many others.
The creation of Java
Beans is very easy with Bibliography
Bowen, Barry D. "Software Reuse with Java: Finding the Holy Grail." May, 1997 feature on
http://www.javasoft.com/
Duntenmann, Jeff. "The Crazy Years Are Here Again." Foreword,
JAVA Programming Language Handbook, 1996, Friedel and
Potts, Coriolis Group Books
Eckhoff, Randy.
"BeanMachine: Adding Life to your Web Site."
IBM Developer Connection News, June 1997, Release 2, p.
15.
Gupta, Suchitra; Hartkopt, Jeff; and Ramaswamy, Suresh.
"Java through the Eyes of a C++ Programmer (Part 2)"
Java Developer's
Journal, March 1997,
Vol. 2, Issue 2, p. 20.
"Introducing a Java Class for Persistence and Scalability."
Java Report, May 1997, Vol. 2, Number 5, Sigs
Publications.
"Java as Client and Server."
Java Report, May 1997, Vol. 2, Number 5, Sigs
Publications.
"Java compared to C/C++."
http://rad.hcf.jhu.edu/~ian/javafyi/javacompare.html
Kaminsky, David.
"The Case for 100% pure Java."
http://www.ibm.com/java/community/viewarchive3.html
MacDonald, Patrick, and Yang, Shili. "JDBC: Open Database Access and
Platform Independence...But How do I use
it?"
IBM Developer Connection News, June 1997, Release 2, p. 9.
Nunn, Hal. "100% Pure Java--Questions and Answers with Hal Nunn." May, 1997 feature on
http://www.javasoft.com/
Renshaw, David S. "JavaBeans: The Perfect Roast?"
IBM Developer Connection News, June 1997, Release 2, p.
3.
Scheier, Robert L. "Managers aren't jumping for Javajoy just yet--Jury's
still out."
Special Report: JAVA Reality check on Java hype,
Computerworld, May 12, 1997, Volume 31, No 19, p. 73.
Spivak, Nova. "Should Java Be an open standard?"
Java Developer's
Journal, March 1997, Vol.
2, Issue 2, p. 7.
"Sun's New JavaSpaces Redefines Distributed Computing."
Java Report, May 1997, Vol. 2, Number 5, Sigs
Publications.
"The San Fransico Project."
http://www.ibm.com/java/sanfrancisco/
"Using the Factory Design Plan."
Java Report, May 1997, Vol. 2, Number 5, Sigs
Publications.