Why D isn't Java?
 
By Daniel Yokomiso
 

Since its inception D has strived to be a "better C". Although this looks similar to early C++ goals, D isn't an extension to C: source code compatibility with it was discarded together with all associated syntax and semantic problems. Where does this leave us?

D follows the tradition of the C-like languages (C, C++, Java and C#) using similar constructs and declarators. This snippet is valid in all of them:

                            
            for (i = 0; i < 10; i++) {
                a[i] = add2(a[i]);
            }

            int add2(int n) {
                return n + 2;
            }
                            
                        

Programmers familiar with any of these won't have many problems learning D.

If D is C with classes without C++ complexities, how is it different from Java?

Table 1. Similarities between D and Java
single class inheritance with multiple interface inheritance
garbage collector
single root class
"new" operator with instances on the heap
all methods virtual
method overloading with signature invariance
primitive types
exceptions
...

The similarities list could go on and on, listing concepts and keywords. Both share an object model and C-like syntax. Now the question is: "How are they different?"

The main difference lies in intent. Java supports and mandates the object-oriented paradigm, with few exceptions. For example, every function must be defined as some class's method, leading to static methods, single method classes and utility classes. Everything must be an object (except primitives and their ilk). On the other hand, D just support the object-oriented paradigm; if you want plain functions or data structures they are available. Everything could be an object, but if you think different it's OK too. D helps you get things done without getting in your way.

While Java intends to be an application programming language, D was designed to be a system programming language too. There are several features in D, either "unsafe" or "too low level", included to allow system programming. These features are non-existent in Java, for reasons so strong that any language including them isn't a Java derivative. I will highlight the most important ones and their role in D:

  • Structs: it's the standard way of defining memory-mapped data layouts. If you're writing device drivers or data format handlers it's nice, quick and efficient to define a struct representing your data layout and access it directly, instead of dealing with explicit conversions;
  • Pointers and pointer arithmetic: most modern languages either disallow or disapprove of direct memory access. As a system programming language, D satisfies the occasional need for raw memory manipulation using these features. However, contrary to C/C++, other features are available to substitute common usages of this error-prone, yet powerful, feature: powerful and safe arrays, its simple object model and out/inout parameters;
  • Embedded assembly: the last resort when you need access to the bare metal. Sometimes you need extra performance in an already tuned piece of code, or access the hardware to interact with a particular device. When the need exists you can always use the "asm" statement, and if you want portability, there's also the "version" statement;
  • Direct access to C functions: easy and safe to use (as safe as C gets), just declare the signature and call the legacy functions;
  • Delete statement: use it when you don't, or can't, trust the compiler, but beware of dangling pointers.

The last four features make D both powerful and unsafe, so use them judiciously.

But supporting C programming practices isn't the only thing that makes it different from Java. D's creator, Walter Bright, used almost 20 years of experience on compiler writing as D's design guideline. The syntax has very few ambiguities, leading to very fast compile times. The semantics for language constructs leave plenty of room for optimizing compilers. Portability of semantics is a concern that permeates the language design. Also, efficiency of execution is one of the main goals: D is suitable for industrial strength, real-time software. Finally D is an evolving language. Anyone can drop in at news.digitalmars.com and help shape the language or the basic libraries. Suggestions and criticisms are welcome.

The future will part Java and D even more. The current D implementation (DMD 0.58) includes several features missing in Java, including covariant return types, delegates, templates (true generics, instead of type erasure) and Design by Contract. Most of these are currently RFE's in Java Developer's Connection, and even when Java develops these features they'll have to live with legacy libraries written using older syntax and semantics.

 

For another view on Java vs. D check the Digital Mars D site.

 

 

Copyright (c) 2003 Daniel Yukio Yokomiso. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is available at GNU Free Documentation License .