Advocacy
Dojo (HowTo)
Reference
Markets
Museum
News
Other
Myths
Press
General
Hack
Hardware
Interface
Software
Standards
People
Forensics
Web
CodeNames
Easter Eggs
History
Innovation
Sightings
Opinion
Martial Arts
ITIL
Thought
What
is Java?
I get asked all the time, is Java just hype? What is it going to mean to the computer industry? Why is it such a big deal? First I have to give some explanation about how Languages work, then I can answer those questions.
Computers work with very low-level commands known as "machine code." This code is just grouped bits of binary patterns (0's and 1's). These instructions do loops (repeat a sequence of commands), conditionals (only do something if certain criteria are met or not) and some math functions (normal math like addition, subtraction, multiplication and division as well as some special "Boolean" functions). This is about 95% of what a computers "processor" (CPU) can do -- it can just do these things really really quickly, and we can describe almost any problem with a lot of those simple instructions.
Binary instructions are unique to each processor chip, and are hard for humans to work with; so, we built more human friendly computer "languages" that programmers usually work with. These human friendly computer languages include names that you've probably heard; C, C++, Pascal, Java and others.
[Read the related articles on Understanding Programming Languages or Languages vs Systems for more background].
Compiled languages
Compiled Languages are compiled down into the native machine languages. This process is like translating a document from one human language to another (say English to Spanish); once translated, you can't really get back to the original (easily). Once "compiled" the resulting code is small and great for the computer to work with (fast, native, easy).
Compiled code is specific to each computer processor (since each line of processors speak slightly different languages). So compiled code can not be moved from one processor to another (say from a PowerPC to a Pentium). To a lesser point, the code is also often specific to an Operating System (Mac or Windows) or the code expects certain libraries (support code).
Note: The "source code" (program BEFORE translation), may be partially used across platforms -- but that code has to be compiled for each platform, and it often takes work (time and money) to do this successfully. Furthermore, only parts of the code can be used cross platform (somewhere between 20 and 80%, depending on the design and the problem).
C, C++, Pascal (usually), FORTRAN, and many other languages are "compiled" languages. Programs written in these languages are usually very platform specific, and are compiled to particular processors.
Apple and NeXT both
created a system called "FAT Binaries" which allow
multiple flavors (targets) for compiled code to be
bundled together. Only the right code (the one for
the processor you are running on) is excecuted at
run time. This means that the same application can
run on more than one processor (if they are running
the same OS and have the same libraries).
These Apps are called
"FAT" because there is more than one processors
code in there (making the program slightly larger).
Since most of a programs size is because of
"resources" (text, images, sounds, other data), the
program is not as much larger as people
would think -- probably 30-40% larger (not double
the size).
Interpreted languages
Interpreted Languages are not "precompiled" into a native machine language, they are "interpreted" on the fly. The computer looks at each instruction given, and then interprets those instructions one by one (by excucuting a "native" routine for each instruction). This is like having an interpreter between you and someone that speaks another language. This go-between slows the process of your communicating down (over being able to speak each others language) because of the extra "step". So interpreted Languages make slower programs than Compiled ones.
Interpretive Languages offers advantages to programmers because they can often just modify code immediately, and don't have to go through a "recompiling" process. So for development (writing code) it is very nice. Programmers just add instructions and test them out immediately (without having to wait for long recompiles -- that can take anywhere from a few minutes up to hours for each compile).
Interpreted code does not have to be specific to any particular platform (computer processor, OS, etc.). It can be "interpreted" on the fly -- if you have the interpreter, you can basically speak that "common" language. So interpreted languages are often far more "cross platform" (they run on many different computers).
10 or 20 years ago, when computers were literally hundreds or thousands of times slower than today, we could not sacrifice performance for convenience -- but the reality of today may have changed things. Don't forget that computers are doubling performance every 18 months, and programming costs are still increasing. Interpreted programming will slowly take over in development.
PCODE - The code that the computer "interprets" is not always "the text" that is displayed to programmers. Often a language compiles/contracts the text, into a special abbreviated shorthand (for internal use only). That code is technically called "P-Code" (pCode) or Psuedo-Code. It is not really a machine code (as it can't be run natively, it has to be interpreted), and it is not really something that the user can read.
This "pCode" technique was created UCSD in the late 70's. Sun basically revamped the idea in Java. Java is a "pCode" compiler, which is really just a type of interpreter.
Scripting Languages - some languages (usually interpreted ones), aren't quite powerful (complex) enough to be called "Programming Languages". Instead these languages are used for scripting (a simple form of programming). If users want to write powerful stand alone Applications, they don't use Scripting Languages (they instead use programming languages)-- but sometimes programmers (or PowerUsers) just want to add functionality to an application. To add functionality to programs, they can sometimes use a "scripting" language (if the application supports it).
Many programs have their own scripting languages, HyperCard and QuickTime (QTi) with HyperScript, Microsoft Office with VisualBasic for Apps, or Macromedia Director with Lingo, Apple has a common extensible scripting language for the finder and most Apps called AppleScript. DOS and Unix (which are really programs / Application that is an interface to the OS for users) often have scripting languages as well. There are hundreds of "scripting" languages, like Perl, Awk, most Databases have their own scripting languages (and a few even have "programming languages"), and so on, and there is a scripting language for HTML called JavaScript (which has nothing to do with Java). Remember, Scripting Languages are just "simple" programming languages, tailored to doing things for apps (or for sending commands to the OS-Shell), and are not really designed for "full" programming.
JavaScript has nothing to do with Java -- in
fact its original name was LiveScript. But Netscape
(in a stupid and annoying move motivated by some
marketing hack) wanted to try to leverage some of
the hype behind Sun's "Java" -- and so they renamed
LiveScript to JavaScript, forever confusing users.
A similar move would be if Boeing tried to rename
the 747 passenger jet into "the space shuttle",
eventhough they do two completely different
things. Java is a computer language (syntax), and a set
of libraries (frameworks) for that languge.
JavaScript is a scripting language (that you can
embed in HTML pages) that doesn't even look vaguely
similar to Java. Java works. JavaScript has a
tendency to work poorly and crash Netscape -- but
since it is the only way to do some things,
JavaScript is used anyway. Microsoft didn't want too much progress made
(and they hate standards), so they implemented a
sub-set of JavaScript called JScript. Microsoft
then made sure it was screwed up (different from
JavaScript) in lots of different subtle ways (to
torture programmers). This forces Web sites to
choose between Netscape and Explorer, and prevents
them from writing things in JavaScript (easily)
that work on both. This stuff is likely to be
hashed out in the next few years, but the pain (for
now) is mostly due to Microsofts evil marketing
that intentionally tries to slow down progress
(when they aren't in control), even when it hurts
thousands of programmers and millions of users.
JAVA
So what is Java?
Java is an interpreted language (that uses pCode). It has a syntax (language) that runs on many different platforms -- meaning that programmers can write for this language, and run those programs on any platform. Some other languages do this too, but you have to recompile for each target platform -- Java allows you to "compile" once (to pCode), and then that app can be run anywhere. Java differs from other languages in that it also has a rich set of frameworks (object libraries of things that it can do for programmers -- making them work far less). On top of that, the language itself is designed to avoid something called "pointers" (pointers are where 60%+ of ALL programmers mistakes are made. Those mistakes often cost thousands of dollars each to find and fix). Furthermore, Java makes it easier for programmers to package up their own frameworks/libraries and interchange them and reuse them on other projects (via something called JavaBeans).
So Java costs less (time and money) to develop for, by quite a bit, it costs far less to maintain and debug (because there are no "dangling pointers" and similar subtle bugs), you are more likely to reuse code written for Java (thus not having to recreate things that have already been done), and when you write for Java you can use that one app to run anywhere (on any platform). Costs less, does more. Sounds pretty good, huh? It is.
Well unfortunately, in engineering (and life), there are always trade-offs.
Performance -- For now one of the trade-offs is speed. Java Apps are not yet fast (it takes time to work out "kinks" of a new language). The current implementations are interpreted -- they are in an intermediate language that computers don't understand "natively". So the JVM (Java Virtual Machine) must "interpret" each command for the computer. Because this process takes time, Java Programs are not very fast (yet). A few things are coming around to change all that.
- Computers are always getting faster. "Slow" on todays machine will not be slow on next years machine. It will be blazing fast on the machine released a year after that. Because of that, no matter how slow Java is now, it won't matter in the future.
- Java Interpreters are getting far better (faster). They are using new techniques (called JITs or JIT-C). JITs means "Just-In-Time Compiler" -- the first time it runs an instruction, it actually compiles the Java Instruction into something that the Computer Understand "natively" -- then all times they come back to that instruction (and computer programs loop a lot) it is "native" and fast(er). This is increasing performance by 10-20 times (and will only get better).
- Some Computers (CPU's) are being made to "natively" understand Java. This makes them far faster than machines that don't. As Java becomes more popular, it is highly likely that many computers will be modified to run Java faster (natively).
- More and more functionality is being pushed from Java into its libraries (Frameworks). These frameworks (like JFC and AWT) may be implemented native (even if the Java code isn't) -- or in other words, 80% of the time you are running Java code, the code may be native.
- People are working on Native-Java. Which means you write the programs in Java, but you compile them as stand alone Applications for each platform. This gives you the speed of Native Applications (or closer), but with the advantages of writing once, and delivering on many different platforms (even if you have to deliver a few "flavors", that are precompiled for each platform).
So not only are computers going to get faster (making the speed of Java "fast enough"), but the technologies used in Java are going to make it faster still. It is just a matter of time.
Change always costs money (and time and effort). People are resistant to change, even when they know it is for the better. So the last thing that has been holding Java back is the time it takes to switch. There is a huge amount of infrastructure, tools and code written for other languages -- it takes time for Java to catch up. But people have been busy, there are now literally dozens of commercial tools (and more coming each day). Furthermore, there are now becoming lots of commercial Java Libraries to extend Java and make it do more (with more and more coming). So the cost to change slows progress down -- but it doesn't stop progress.
Despite the resistance to change, and the performance of Java, the momentum is building (the hype has been there for a while). So it is not a matter of "if" Java will take over -- it is just a matter of "when".
Conclusion
The short answer, is that Java will eventually take over and eat most other programming languages (for general purpose). But it will probably not happen as quick as people think. In fact, it has already been a few years, and it hasn't done that much for most programmers, yet -- and we still have a few more years before the full impact will be felt.
There are two ways to deliver Java programs -
- One way to deliver Java is as
an "Applet". An Applet is a small mini-Application that
can only be run inside of a browser (and run across a
network) -- it has security, is small, and can only do
some limited things. Already Applets have littered the
internet, with lots of little Applets solving lots of
little problems (like animation, data-entry, etc.). They
have already made their mark, and are going to do
more.
- The other way to deliver Java is as an Application (Apps). Apps are stand-alone programs (that don't need a browser to run). For now Java Applications have needed something called a JVM (Java Virtual Machine) to run those Apps, but now the JVM is being bundled in with Operating Systems or with the Applications themselves (making them more seamless). This means that stand-alone Java Apps are becoming more viable. In certain business (like fortune500 companies) where they have large databases that need to be accessed from lots of different types of computers, they have been writing Java Applications (as front ends to their databases). So already Java Apps are making dents in certain markets. I think that momentum will build, and more and more markets will feel the impact.
So Java Application programming is already taking off in certain markets, and the momentum is building. Colleges are already teaching Java, and some programming Colleges are talking about an "all Java" curriculum. Momentum. Programmers have been learning Java, tool makers have been making Java tools, places that sell libraries of code have been creating Java Libraries (frameworks). More momentum. Momentum builds momentum -- the snow-ball effect.
1998 will be a transition year, where you will start to see lots more Java Apps leaking out (as better tools become available) -- but 1999 will probably be the year when Java starts "taking over the world". By the millennium, I think many (most) other computer languages will get squashed by the momentum behind Java -- so it will live up to the hype (there is just too much momentum building for it not to). It is just happening a little slower than some people thought.
Created:
1/8/98
Updated:
11/09/02
Top of Section
Home