Java and C++

Dear DDJ,

After reading Al Stevens' narrative on C++ versus Java, I felt compelled to respond to a few points with my pragmatic perspective as a developer of Java and C++ applications. I agree with his initial assessment that templates are a sorely missed feature of Java, but container-class libraries were developed in C++ long before templates arrived. The containment of intrinsic types, which appears to be Al's primary issue here, has generally been addressed by the JDK by inclusion of the java.lang classes which are primarily wrappers for intrinsic types. It is these wrappers that allow intrinsics to be used in the java.util classes--primarily container classes (Vector, Stack, Dictionary, Hashtable, Enumeration).

Al's next assertion that Java did not become a cult language because of JavaScript is a demonstration of a lack of knowledge in this area; JavaScript was named as such after Java became popular. JavaScript was originally called "LiveScript" by Netscape. It was realigned with Java after Java was a big hit. Java became popular because it offered the first serious client-side interactive application development tool. (Java wasn't the first web tool to do this; it just hit at the right time.)

Java isn't for C programmers who lack object-oriented background. Java is an intensely object-oriented language, compared to C++. There is no model for stand-alone functions in Java.

Not having read Java for C/C++ Programmers, by Michael Daconta, I'll have to take Al's reading of Daconta's assertion about variable argument lists on face value. All classes in Java are derived from a single Object class; therefore, a Vector could easily be used for a variable argument list. In fact, the instanceof operator makes this a likely scenario since each element of the vector could be queried for the type of class that it is. So, Daconta may have the cause/effect relationship wrong, but the observation is valuable nonetheless. And, in fact, it is the instanceof operator that offers real type-safety.

Al's comments about multiple inheritance are somewhat ambiguous in the column. Rather than trying to guess what Daconta says about them and whether Al agrees, I'll just throw in that Java does not support multiple inheritance directly but supports a similar and powerful paradigm of interface classes. Interface classes do not support multiple inheritance like C++ does, but they do allow a class to declare on a class-level functional interfaces that enable an object to be used polymorphically. In Example 1(a), Fish and Leopard can be instantiated and stored in a Vector. The vector can be enumerated and each animal can be queried for its name via polymorphism: System.out.println((Animal)o.getName()); // print out animal's name. But a more powerful implementation can be used as in Example 1(b). There is really nothing like this in C++. I have actually used this language feature to implement a multicolumn listbox that contains owner-drawn cells based on interface functions.

Whether Bjarne Stroustrup really used references as a band-aid for pointers I can't comment on, but pointers and references do not exist on a language level like they do in C++. Java variables can be defined without being instantiated; see Example 1(c). Although there is a "null" value that can be assigned to an object, the creation of objects and their assignment to variables is more like the C++ copy constructor than anything else. Objects that have default constructors (no arguments) will automatically instantiate themselves. Does this mean that Java supports pointers? Not at all. Objects can be instantiated and assigned to a variable, but they can't be deleted like C++.

Java does not have a preprocessor as part of the JDK. There is no reason that CPP can't be used with Java to do exactly what Al suggests. There's not much to quibble with here, although I do think that Al overplays the need for a CPP.

Al casually tosses in a few jabs at Java by asserting that C++ is a superior programming language. Having written several orders of magnitude more C++ code that I have Java code, my experience tells me that I must disagree with Al. At its worst, Java as a language is about equal to C++. But in many respects it's much better than C++ will ever be. The things I miss in Java are operator overloading, an object destructor, and the ability to create an occasional global object. However, Java is significantly better than C++ in many areas:

The Java language shows strong signs of maturity. The JDK still has bugs galore, but these will eventually work themselves out. And unlike most of those on the Java bandwagon, my support for Java is purely on a language basis. I like Java only because the nature of the language maps better to what I consider good object-oriented programming. I am not as interested in the Java interpreter or portable bytecode.

In fact, I look forward to the future where Java compilers produce native executables so that more of my development efforts may be built in Java.

Jeffrey Kay

Falls Church, Virginia

jkay@dev.infomkt.ibm.com

The Juice of the Bean

Dear DDJ,

If Michael Swaine writes software with the same literary verve he displayed in his "Ode to Java" in the July 1996 "Swaine's Flames," he may well achieve Donald Knuth's ideal of software as literature. But...does it compile?

Russell Galvin

Acton, Ontario

russell@srgsoft.com

Will's Words

Dear DDJ,

The article "Optimizing the Performance of VRML Worlds," by David R. Nadeau, Andrea L. Ames, and John L. Moreland

(DDJ, July 1996) was fascinating. However, whoever decided to use the quote from Macbeth in Figure 8 shouldn't have done it from memory. Every edition of Shakespeare that I've been able to find spells "caldron" without a "u," not the modern "cauldron." And the third line is obviously missing a word, as it doesn't scan. It's not much better in Will's version: "Toad, that under the cold stone." Still, the Bard's words are precious, and we shouldn't omit any.

Neil J. Rubenking

Neil_Rubenking@zd.com

A Helping Hand

Dear DDJ,

Near the end of his August 1996 editorial, Jonathan Erickson suggests that government, in particular the federal government, should "help build an infrastructure to support cooperative research."

I challenge him to read Why Government Doesn't Work, by Harry Browne, the Libertarian candidate for President, and then present his views again as to why this particular government program that he is encouraging has any more chance of succeeding than the hundreds of others that don't. I hope he'll see that what he should be encouraging is exactly the opposite: Get the federal government out of R&D altogether, remove corporate (and individual) taxation and regulations and you'll see R&D flourish like never before.

Did Microsoft or Intel need any help from the government to give us the PCs and software that are 100 times better and faster than they were in 1980? (see Why Government Doesn't Work, page 156).

Joe M. Abbate

jma@icanect.net

Example 1: Java and C++.

(a)

      class Animal extends Object {
          String name;
          public Animal(String s) {
         name = s;
          }
          String getName() {
         return name;
          }
      }
      interface Swimmer {
          public abstract swim();
      }
      interface Runner {
          public abstract run();
      }
      class Fish extends Animal implements Swimmer {
          public Fish(String s) {
         super(s);
          }
          public swim() {
         ...
          }
      }
      class Leopard extends Animal implements Runner {
          public Leopard(String s) {
         super(s);
          }
          public run() {
         ...
          }
      }
      
(b)   
      if (o instanceof Swimmer) {
          Swimmer sw = (Swimmer)o;
          sw.swim();
      }
        if (o instanceof Runner) {
           Runner rn = (Runner)o;
            rn.run();
      }

(c)   
      Fish f;    // f is uninstantiated and undefined
       Leopard l = null;    // l is uninstantiated and set to null, sort of like C++
       Fish f = new Fish("Goldfish");    // instantiated