Java

Any of a breed of domestic chicken developed in the United States from Asian stock, having black or mottled black plumage.

This is the genealogy of the programming language Java:

Java is a child of C++ and Smalltalk.
Java was born in year 1991.
Then it begat NetRexx in year 1991.
It became Java 1 in year 1995.
It became Java 2 (v1.2) in year 1998.
Then it begat C# in year 2000.
It became Java 2 (v1.3) in year 2000, and has not changed much since that time.

This genealogy is brought to you by the Programming Languages Genealogy Project. Please send comments to thbz.

In most of the real world, Java is known for being an island, not a coffee, let alone a programming language.

Java is one of the largest islands in Indonesia. The largest city in Java is Jakarta, which is also the capital of Indonesia. Some of the oldest human remains have been found in Java: the "Java man," who was a Homo Erectus, lived there 800,000 years ago. During the first centuries A.D, Indian influence brought hinduism, then buddhism to Java. During the 9th and 10th centuries, some of the most famous buddhist monuments in the world were built at Borobudur.

Islam took over Java in the early 16th century. At the same time, the Dutch arrived in Java, and established trading posts. The merchants gradually controlled the various muslim kingdoms of the island, which eventually became dutch. After being occupied by the Japanese during World War II, Java became a part of independent Indonesia in 1950.

In France, Java is also the name of a 3-step dance, which used to be very popular. Nobody knows about the Java coffee there.

jaggies = J = JCL

Java

An object-oriented language originally developed at Sun by James Gosling (and known by the name "Oak") with the intention of being the successor to C++ (the project was however originally sold to Sun as an embedded language for use in set-top boxes). After the great Internet explosion of 1993-1994, Java was hacked into a byte-interpreted language and became the focus of a relentless hype campaign by Sun, which touted it as the new language of choice for distributed applications.

Java is indeed a stronger and cleaner design than C++ and has been embraced by many in the hacker community - but it has been a considerable source of frustration to many others, for reasons ranging from uneven support on different Web browser platforms, performance issues, and some notorious deficiencies in some of the standard toolkits (AWT in particular). Microsoft's determined attempts to corrupt the language (which it rightly sees as a threat to its OS monopoly) have not helped. As of 2001, these issues are still in the process of being resolved.

Despite many attractive features and a good design, it is difficult to find people willing to praise Java who have tried to implement a complex, real-world system with it (but to be fair it is early days yet, and no other language has ever been forced to spend its childhood under the limelight the way Java has). On the other hand, Java has already been a big win in academic circles, where it has taken the place of Pascal as the preferred tool for teaching the basics of good programming to the next generation of hackers.

--The Jargon File version 4.3.1, ed. ESR, autonoded by rescdsk.

Java is a coupled programming language and execution platform developed at Sun Microsystems. Those primarily responsible for it, and the names most closely linked to it, are Bill Joy and James Gosling. Originally called Oak, it was positioned initially as an embedded platform for consumer appliances.

It languished in this niche until about 1995, when Sun introduced its slow and clumsy HotJava web browser and allowed Netscape to implement a Java execution engine into its browser as well. These efforts were the thrust of Sun's attempt to reposition Java as a desktop application language, and specifically one that could be used to distribute applications over the Web by embedding Java programs in web pages: to use Sun's term, applets. Part of the allure of this strategy was the theory that Java programs could run identically on any operating system, allowing universal access and doing for programs what HTML did for documents. It isn't surprising that Java was briefly a media darling, as it seemed to make the already hot Web interactive and exciting. Plus it has a cute name. The media love a cute name for technology they don't understand.

While Java was a hot industry buzzword, there was a brief flurry of major applications being ported to Java, most notably Corel and WordPerfect. However, these efforts failed as their proponents discovered Java's terrible performance, flakey and distinctly unportable windowing API, and poor integration with the operating system.

The Java language is similar in many ways to C++, being object-oriented but maintaining much flavor from C. Java distinguishes itself by removing much potentially confusing syntactic baggage, such as templates, multiple inheritence, default parameters, constructor initializers, and overloaded operators. Some simplifications of C++ were met with less enthusiastic acceptance, such as the decision to disallow all global declarations except for classes. Some solutions to C++'s inelegance are themselves quite elegant, such as the decision to ditch multiple inheritance in favor of single inheritance with interfaces. The Java language benefits from tight integration with its runtime library, having a single object hierarchy derived from java.lang.Object and a single exception hierarchy derived from java.lang.Throwable. Java borrows from the Smalltalk school in other ways as well: Java language does not have pointers in the same sense as C and C++, and its heap is garbage collected.

The platform side of Java, the Java Virtual Machine, or JVM, is based on a bytecode execution system: source code is compiled to portable bytecode files, which, theoretically, can be executed identically by any compliant JVM. While the standard for the bytecode execution facility itself is reasonably well-defined and static, the Java class library varies wildly from version to version. As a result, Java programs frequently failed to run on unexpected versions, displaying only terse messages like java.lang.ClassNotFoundException to a surprised end-user. The JVM is fairly loosely coupled to the language, so there are compilers that will compile to Java bytecode from languages other than Java. Similarly, there are compilers that will compile the Java language to native platforms, rather than the JVM.

Java source files usually have a ".java" suffix. When compiled, each class is encapsulated in its own class file, having a ".class" suffix. All class files particular to a project are linked together in a Java archive (JAR) file, having a ".jar" suffix, which can then be distributed to the user. JAR files actually borrow their format from ZIP files, meaning they can be opened and examined without any special tools. This, in addition to the fact that the Java bytecode is trivial to decompile (using any of several decompilers, but most famously Mocha) made Java an unsecure way to distribute code and therefore became another reason Java never had serious commercial backing as a desktop environment.

Java has its heart in the right place, and it has a lot of compelling attributes. In many places it is even breathtakingly elegent and occasionally profound. Unfortunately, Java is a piss-poor portable desktop application environment. Of the two windowing APIs Java supports, the Abstract Windowing Toolkit (AWT) and Swing, the former sacrifices control and can produce drastically different results on various host GUIs, and the latter, while quite powerful, eschews entirely the widgets of the underlying operating system and will always produce interfaces that look markedly different than native applications. In addition, Java sacrifices integration with the operating system in favor of portability, so there is no good, standard way for an end user to launch a Java application. Up until recently, end users may have had to deal with arcane, programmer-level details such as installing the Java Runtime Environment (JRE), setting a CLASSPATH environment variable, and manually invoking the Java interpreter for the command line. Initial implementations of Java in web browsers were, and still are, notoriously slow and buggy. Loading a web page that contained an applet often resulted in a several-minute wait while staring at the unhelpful message, "Starting Java..." Despite later enhancements such as Just-in-Time (JIT) compilation, Java's performance is still far less than comparable native code. Java's portability woes were increased by Sun's failure to release the source code for their Java execution environment. The only official Java environments were for Win32 and Sun's Solaris, making actual portability a casualty at the hands of market leverage. Sun's Java Development Kit (JDK) was another fine product that, if made open-source, could have greatly enhanced Java's portability and acceptance by developers.

Microsoft briefly flirted with its own Java virtual machine and development system, Visual J++, but when it attempted to embrace and extend Sun's prized standard by introducing its own Windows-specific Java APIs, Sun sued. Microsoft has since dropped any outward support for Java in favor of its .NET platform and C#.

Today, Java is used occasionally in obnoxious, slow-loading interactive banner ads. It's used more frequently in computer science classrooms, as it displaces Pascal or C++ among academics as the language initially used to terrify and confuse would-be programmers. And, partly because of the ease with which Java code can be written, and partly because of mature latter-day APIs like Enterprise JavaBeans (EJB), it makes an adequate platform for proprietary back-end code, filling a niche for projects too involved for the quick-and-dirty Perl but lighter than would require the just-plain-dirty C++.

Update 5 Aug 2002. In an attempt to migrate Java programmers to the new .NET architecture, Microsoft has introduced the ludicrously named J#, a compiler born of compromise. It seems to be a Java compiler that produces .NET bytecode rather than JVM. Its capacity to support Java libraries is unclear.

Especially post-Java 2, Java can also refer to a rather large set of classes and sample implementations provided by Sun Microsystems and various other members of the Java Community Process (JCP). These include frameworks for various distributed application tricks, 2D and 3D graphics, internationalization, and whole slew of others. In theory, this adds to the appeal of the programming language because it reduces the amount of work programmers have to do to implement any given project.

I hate java quite a lot. Java is both nice and stupid and horribly broken. Java is nice because all the features it has that lisp has, such as object-orientation, byte compilation, and garbage collection, but broken because it has a stupid type system.

1. Interfaces don't allow specification of static methods or constructors
2. It is statically typed
3. It doesn't allow union types

1) Interfaces don't allow specification of static methods or constructors

This is bad because when I want to use reflective features to instantiate an object, I can't use the compiler to guarantee that all my objects have the same interface for construction. Also, specifying static methods allows us to get "extra introspection", so the class can tell us stuff about itself, but that's just froth. The real reason I want it is for when I'm dynamically deciding what class to instantiate.

2) It is statically typed

Static typing adds nothing to object-oriented languages - they carry type information around in objects, so there is no speed or space advantage. On the other hand, it does make things considerably less convenient. Imagine that (for some crazy reason) you're storing things in a Collection, and everything comes back out as Objects. This is bad because you were mainly storing bytes anyway, and you had to allocate a load of wrapper objects. The other situation where static typing is bad is...

2.5) It doesn't allow union types

When declaring variable types (which I don't want to do, except when it's really necessary, as when catching exceptions, but it's a taste thing), you can't declare the variable to be of a union type: (or TooFatException TooThinException). If the actions are always the same, and the only methods you want to invoke on the exception are those of an exception, you can't use a union, you have to have 2 catch blocks, doubling the code you have to maintain, and when you're developing code like this, you always find bugs, and you have to fix them twice. Introduce the errors! Introduce the errors!

In case you think inheritance helps here, consider the case where I am catching exceptions whose types I didn't create, which is the usual case. Here inheritance will not help me, because I do not define the inheritance hierarchy. Also, what if there is a TooUglyException that should be handled differently from the other TooFooExceptions?. You could do:

catch(TooFooException x)
{
   if(x instanceof TooUglyException){throw (TooUglyException)x;}
   else{}
}

The problem with this is that I must know about the entire TooFooException hierarchy, and if a new class is added, this code has to change. Also, if there are many classes in the hierarchy, I must have many if-statements to find the correct type to cast the exception to, or lose type information by just throwing TooFooExceptions. Both are bad.

Many if-statements make the code hard to read, and navigate, and as it's going to need maintaining every time a new exception is added, this is is bad. Losing type information is bad because users of the code are either going to jave to catch TooFooExceptions, and make no ditinction between them, or use if-statements to use the exceptions sensibly. This forces users of your code to adopt your programming style, which is bad.

There is also the objection that a union type is fundamentally different from the way java does things at present, because you can tell from a class' declaration all possible types that it is a subtype of. This is true. However, what I am arguing for is not union types, but union tyoe declarations, so that a variable that is of type (or Foo Bar) does not refer to a varibale that is in some way a combination of Foo and Bar, but rather that it can hold EITHER a Foo, or a Bar. Also, because I am against static typing, as mentioned above, when throwing a union type, it will be thrown as the right type (ie the type that the object is) rather than as the union type of the variable. There is also the rather more meaty objection that you still have to deal with type incompatibilities. Java already has reflection, so if you're careful, you can use that to check that the method you want to invoke exists (Although while I'm wishing for a better type system, we need a new reflection syntax. The current syntax can only be described as god-awful). You could just invoke the operation, and deal with the exception that arised if you invoked a non-existent method. Or, more sensibly, you could simply only invoke methods that you know exist on all types in the declaration, which, as far as I can see, is the only time you'd want to use a union declaration.

Ja"va (?), n.

1.

One of the islands of the Malay Archipelago belonging to the Netherlands.

2.

Java coffee, a kind of coffee brought from Java.

Java cat Zool., the musang. -- Java sparrow Zool., a species of finch (Padda oryzivora), native of Java, but very commonly kept as a cage bird; -- called also ricebird, and paddy bird. In the male the upper parts are glaucous gray, the head and tail black, the under parts delicate rose, and the cheeks white. The bill is large and red. A white variety is also kept as a cage bird.

 

© Webster 1913.