 |
What is Java?
|
Java is an object-oriented programming language developed
by James Gosling and colleagues at Sun Microsystems in the
early 1990s. The language, which was designed to be platform
independent, is a derivative of C++ with a simpler syntax,
a more robust runtime environment and simplified memory management.
Java is not related to JavaScript, though
they have similar names and share a C-like
syntax.
History
Early History
The Java platform and language began as an
internal project at Sun Microsystems in December
of 1990. Engineer Patrick Naughton had become
increasingly frustrated with the state of
Sun's C++ and C APIs (application programming
interfaces) and tools. While considering
moving to NeXT, Naughton was offered a chance
to work on new technology and thus the Stealth
Project was started.
The Stealth Project was soon renamed to
the Green Project with James Gosling and
Mike Sheridan joining Naughton. Together
with other engineers, they began work in
a small office on Sand Hill Road in Menlo
Park, California. They were attempting to
develop a new technology for programming
next generation smart appliances, which Sun
expected to be a major new opportunity.
The team originally considered using C++,
but it was rejected for several reasons.
Because they were developing an embedded
system with limited resources, they decided
that C++ demanded too large a footprint and
that its complexity led to developer errors.
The language's lack of garbage collection
meant that programmers had to manually manage
system memory, a challenging and error-prone
task. The team was also troubled by the language's
lack of portable facilities for security,
distributed programming, and threading. Finally,
they wanted a platform that could be easily
ported to all types of devices.
Bill Joy had envisioned a new language combining
the best of Mesa and C. In a paper called
Further, he proposed to Sun that its engineers
should produce an object-oriented environment
based on C++. Initially, Gosling attempted
to modify and extend C++, which he referred
to as C++ ++ -- , but soon abandoned that
in favor of creating an entirely new language,
which he called Oak after the tree that stood
just outside his office.
The
team worked long hours and by the summer
of 1992, they were able to demonstrate portions
of the new platform including the Green OS,
the Oak language, the libraries, and the
hardware. Their first attempt, demonstrated
on September 3, 1992, focused on building
a PDA device named Star7[1] which had a graphical
interface and a smart agent called "Duke" to
assist the user. In November of that year,
the Green Project was spun off to become
FirstPerson, Inc, a wholly owned subsidiary
of Sun Microsystems, and the team relocated
to Palo Alto. The FirstPerson team was interested
in building highly interactive devices, and
when Time Warner issued an RFP for a set-top
box, FirstPerson changed their target and
responded with a proposal for a set-top box
platform. However, the cable industry felt
that their platform gave too much control
to the user and FirstPerson lost their bid
to SGI. An additional deal with The 3DO Company
for a set-top box also failed to materialize.
Unable to generate interest within the TV
industry, the company was rolled back into
Sun.
Java meets the Internet
In June and July of 1994, after a three-day
brainstorming session with John Gage, James
Gosling, Joy, Naughton, Wayne Rosing, and
Eric Schmidt, the team re-targeted the platform
for the Web. They felt that with the advent
of the Mosaic browser, the Internet was on
its way to evolving into the same highly
interactive medium that they had envisioned
for cable TV. As a prototype, Naughton wrote
a small web browser, WebRunner, later renamed
HotJava.
That
year, the language was renamed Java after
a trademark search revealed that the
name "Oak" was used by a manufacturer
of video adaptor cards. The name Java was
coined at a local coffee shop frequented
by some of the members. It is not clear whether
the name is an acronym or not; although some
accounts claim that it stands for the names
of James Gosling, Arthur Van Hoff, and Andy
Bechtolsheim, or Just Another Vague Acronym,
it is generally accepted that "Java" does
not stand for anything. Lending credence
to the idea that Java owes its name to the
products sold at the coffee shop is the fact
that the first 4 bytes (the so-called "Magic
number") of any class file are, in hexadecimal,
0xCAFEBABE.
In October of 1994, HotJava and the Java
platform was demonstrated for Sun executives.
Java 1.0a was made available for download
in 1994, but the first public release of
Java and the HotJava web browser came on
May 23, 1995, at the SunWorld conference.
The announcement was made by John Gage, the
Director of Science for Sun Microsystems.
His announcement was accompanied by a surprise
announcement by Marc Andreessen, Executive
Vice President of Netscape, that Netscape
would be including Java support in its browsers.
On January 9th, 1996, the JavaSoft business
group was formed by Sun Microsystems to develop
the technology.[2] Two weeks later the first
version of Java was released.
Recent history
After several years of popularity, Java's
place in the browser has steadily eroded.
For simple interactive animations, it has
been almost completely superseded by Macromedia
Flash and Shockwave. As of 2005 its use is
mostly limited to more complex applications
like Yahoo! Games. It has also suffered from
a lack of support by Microsoft which no longer
includes the Java platform with Internet
Explorer or Windows.
By contrast, on the server side of the Web,
Java is far more popular than ever, with
many websites using JavaServer Pages and
other Java-based technologies.
On the desktop, stand-alone Java applications
remain relatively rare because of their large
overhead. However, with the great advances
in computer power in the last decade along
with improvements in VM and compiler quality,
several have gained widespread use, including
the NetBeans and Eclipse Integrated development
environments, and file sharing clients such
as Limewire and Azureus. Java is also used
in the Matlab mathematics program for rendering
the user interface and for part of the calculation
functionality. Java Swing desktop applications
are being developed as an alternative to
Microsoft .NET technology.
Philosophy
There were five primary goals in the creation
of the Java language:
- It should use the object-oriented programming
methodology.
- It should allow the same program
to be executed on multiple operating
systems.
- It should contain built-in support
for using computer networks.
- It should
be designed to execute code from remote
sources securely.
- It should be easy to
use and borrow the good parts of older
object-oriented
languages
like C++.
Especially for the latter part, however, extensions are sometimes required,
like CORBA or OSGi.
Object orientation
The first characteristic, object orientation ("OO"), refers to a
method of programming and language design. Although there are many interpretations
of OO, one primary distinguishing idea is to design software so that the various
types of data it manipulates are combined together with their relevant operations.
Thus, data and code are combined into entities called objects. An object can
be thought of as a self-contained bundle of behavior (code) and state (data).
The principle is to separate the things that change from the things that stay
the same; often, a change to some data structure requires a corresponding change
to the code that operates on that data, or vice versa. This separation into
coherent objects provides a more stable foundation for a software system's
design. The intent is to make large software projects easier to manage, thus
improving quality and reducing the number of failed projects.
Another primary goal of OO programming is to develop more generic objects
so that software can become more reusable between projects. A generic "customer" object,
for example, should in theory have roughly the same basic set of behaviors
between different software projects, especially when these projects overlap
on some fundamental level as they often do in large organizations. In this
sense, software objects can hopefully be seen more as pluggable components,
helping the software industry build projects largely from existing and well
tested pieces, thus leading to a massive reduction in development times. Software
reusability has met with mixed practical results, with two main difficulties:
the design of truly generic objects is poorly-understood, and a methodology
for broad communication of reuse opportunities is lacking. Some open source
communities want to help ease the reuse problem, by providing authors with
ways to disseminate information about generally reusable objects and object
libraries.
Platform independence
The second characteristic, platform independence, means that programs written
in the Java language must run similarly on diverse hardware. One should be
able to write a program once and run it anywhere.
This is achieved by most Java compilers by compiling the Java language code "halfway" to
bytecode (specifically Java bytecode) —simplified machine instructions
specific to the Java platform. The code is then run on a virtual machine (VM),
a program written in native code on the host hardware that interprets and executes
generic Java bytecode. Further, standardized libraries are provided to allow
access to features of the host machines (such as graphics, threading and networking)
in unified ways. Note that, although there's an explicit compiling stage, at
some point, the Java bytecode is interpreted or converted to native machine
instructions by the JIT compiler.
There are also implementations of Java compilers that compile to native object
code, such as GCJ, removing the intermediate bytecode stage, but the output
of these compilers can only be run on a single architecture.
Sun's license for Java insists that all implementations be "compatible".
This resulted in a legal dispute with Microsoft after Sun claimed that the
Microsoft implementation did not support the RMI and JNI interfaces and had
added platform-specific features of their own. Sun sued and won both damages
(some $20 million) and a court order enforcing the terms of the license from
Sun. In response, Microsoft no longer ships Java with Windows, and in recent
versions of Windows, Internet Explorer cannot support Java applets without
a third-party plugin. However, Sun and others have made available Java run-time
systems at no cost for those and other versions of Windows.
The first implementations of the language used an interpreted virtual machine
to achieve portability. These implementations produced programs that ran more
slowly than programs written in C or C++, so the language suffered a reputation
for poor performance. More recent JVM implementations produce programs that
run significantly faster than before, using multiple techniques.
The first technique is to simply compile directly into native code like a
more traditional compiler, skipping bytecodes entirely. This achieves good
performance, but at the expense of portability. Another technique, known as
just-in-time compilation (JIT), translates the Java bytecodes into native code
at the time that the program is run. More sophisticated VMs use dynamic recompilation,
in which the VM can analyze the behavior of the running program and selectively
recompile and optimise critical parts of the program. Dynamic recompilation
can achieve optimizations superior to static compilation because the dynamic
compiler can base optimizations on knowledge about the runtime environment
and the set of loaded classes. JIT compilation and dynamic recompilation allow
Java programs to take advantage of the speed of native code without losing
portability.
Portability is a technically difficult goal to achieve, and Java's success
at that goal has been mixed. Although it is indeed possible to write programs
for the Java platform that behave consistently across many host platforms,
the large number of available platforms with small errors or inconsistencies
led some to parody Sun's "Write once, run anywhere" slogan as "Write
once, debug everywhere".
Platform-independent Java is however very successful with server-side applications,
such as web services, servlets, and Enterprise Java Beans, as well as with
Embedded systems based on OSGi, using Embedded Java environments.
Automatic garbage collection
One possible argument against languages such as C++ is the burden of having
to perform manual memory management. In C++, memory is allocated by the programmer
to create an object, then deallocated to delete the object. If a programmer
forgets or is unsure when to deallocate, this can lead to a memory leak, where
a program consumes more and more memory without cleaning up after itself. Even
worse, if a region of memory is deallocated twice, the program can become unstable
and will likely crash.
In Java, this potential problem is avoided by automatic garbage collection.
Objects are created and placed at an address on the heap. The program or other
objects can reference an object by holding a reference to its address on the
heap. When no references to an object remain, the Java garbage collector automatically
deletes the object, freeing memory and preventing a memory leak. Memory leaks,
however, can still occur if a programmer's code holds a reference to an object
that is no longer needed—in other words, they can still occur but at
higher conceptual levels. But on the whole, Java's automatic garbage collection
makes creation and deletion of objects in Java simpler, potentially safer,
and often faster than in C++.
Garbage collection in Java is virtually invisible to the developer. That is,
developers may have no notion of when garbage collection will take place as
it is not necessarily a function of the code they themselves write.
Criticism
Java was intended to serve as a novel way to manage software complexity. Most
consider Java technology to deliver reasonably well on this promise. However,
Java is not without flaws, and it does not universally accommodate all programming
styles, environments, or requirements.
- Not all projects or environments require enterprise-level complexity, such
as stand-alone websites or sole-proprietorship programmers. Such individuals
find Java's self-enforcing complexity management to be overkill.
- Java is often a focal point of discontent for those who are not enthusiastic
about object-oriented programming.
- Java can be considered a less pure object-oriented programming language than
for instance Ruby or Smalltalk because it makes certain compromises (such
as the fact that not all values are objects) for performance reasons.
- Java programs may have lower performance than those written in languages
such as C++, which are compiled directly into machine code. The reasons for
this
include the following: Java byte code is not optimized to the same degree
as machine code resulting from C++; Java does not support manual inlining
(though
many JIT compilers perform this optimization); and the usage of a garbage
collector to automatically decide when to delete objects is more expensive
than imperative
deletion in C++ (although modern garbage collectors may outperform imperative
deletion).
- As an established technology, Java inevitably invites comparison with contemporary
languages such as C++, C#, Python, and others. Commenting upon Java's proprietary
nature, supposed inflexibility to change, and growing entrenchment in the
corporate sector, some have said that Java is "the new COBOL".
Many consider this to be a somewhat hyperbolic assertion, although it does
allude to some
legitimate concerns with Java's prospects for the future.
Language
- The distinction between reference types and primitive types may be viewed
as artificial by programmers who are familiar with languages such as Smalltalk,
Python and Ruby, where everything is an object.
- Conversely, C++ programmers can become confused with Java because in
Java primitives are always automatic variables and objects always reside
on
the heap, whereas
C++ programmers are explicitly given the choice in both cases by means
of operator new.
- Java code is often more verbose than code written in
other languages. This is due in part to its frequent type declarations
and manual casts. It is
also due to the lack of operator overloading (see below) and the relatively
simple
syntax. However, J2SE 5.0 introduced Generics which addresses the issue
of manual casts, as well as new syntax for for-loops which also reduces
verbosity.
- Unlike C++, Java does not support user-definable operator
overloading; however, this is a deliberate design decision, seen by many
as a plus
because of the
well-known readability and maintenance problems experienced with operator
overloading.
- Java is predominantly a single-paradigm language. Historically,
it has not been very accommodating of paradigms other than object-oriented
programming.
As of J2SE 5.0, the procedural paradigm is somewhat better supported
in Java
with the addition of the ability to import static methods and fields
so that they can be used globally as one could do in, for example,
C.
- Java only supports single inheritance of implementation. This
causes consternation to programmers accustomed to orthogonal multiple inheritance,
which is
available in many other languages. However, Java employs interfaces,
which allow multiple
inheritance of type and abstract methods.
- Java's support of text matching and manipulation is not as strong
as languages such as Perl or PHP, although regular expressions
were introduced
in J2SE
1.4.
Library
The look and feel of GUI applications written in Java using the Swing platform
is often different from native applications. While programmers can choose to
use the AWT toolkit that displays native widgets (and thus look like the operating
platform), the AWT toolkit is unable to meet advanced GUI programming needs
by wrapping around advanced widgets and not sacrificing portability across
the various supported platforms, each of which have vastly different APIs especially
for higher-level widgets. The Swing toolkit, written completely in Java, avoids
this problem by reimplementing widgets using only the most basic drawing mechanisms
that are guaranteed available on all platforms. The drawback is that extra
effort is required to resemble the operating platform. While this is possible
(using the GTK+ and Windows Look-and-Feel), most users do not know how to change
the default Metal Look-And-Feel to one that resembles their native platform,
and as a result they are stuck with Java applications that look radically different
from their native applications. Of note however, Apple Computer's own optimized
version of the Java Runtime, which is included within the Mac OS X distribution,
by default implements its "Aqua" Look-And-Feel, giving Swing applications
a similar appearance to native Mac software.
Some parts of the standard Java libraries are considered excessively complicated,
or badly designed, but cannot be changed due to the need for backward compatibility.
Performance
It is misleading to make any generalization about the performance of Java programs
in general, because run-time performance is affected much more by the quality
of the compiler or JVM than by any intrinsic properties of the language itself.
Indeed, there are very few language requirements which incur an unavoidable
time penalty. Among these are array bounds checking, run-time type checking
and virtual function indirection, all of which can be made much cheaper by
a good compiler or JVM. Garbage collection may actually increase the performance
of some programs, if implemented well.
Relative performance of JIT compilers as compared to native compilers can
be quite close (often superseeding native compiled), and is often a subject
of debate. The JIT stage may be time-consuming, which is inconvenient for applications
that are short-lived and/or contain large amounts of code. Once this is done,
however, the performance of the program can easily be comparable to that achieved
by a native compiler, even on numerical tasks. In addition, JITs can exploit
information from the runtime environment to guide more effective transformations,
such as profile-directed inlining.
Java was designed with an emphasis on security and portability, and does not
support direct access to the machine architecture and address space. Applications
can drop down to native code to access these features using the Java Native
Interface (JNI).
About
this Tutorial
This tutorial is from The
Wikipedia which is published under the
GNU Free Documentation License.
Blind SQL injection: are your web applications vulnerable? Learn the techniques that can be used to take advantage of a Web application that is vulnerable to Blind SQL Injection, and to make clear the correct mechanisms that should be put in place to protect against Blind SQL Injection and similar input validation problems.
SQL injection occurs when an application does not properly validate user-supplied input and then includes that input as part of a SQL statement. SQL injection largely depends on an attacker discovering and verifying portions of the original SQL query, using information from error messages. However, web applications can still be vulnerable to blind SQL injection attacks even with no error messages or when they only reveal generic information. Request Your Free Whitepaper!
|
|