To create a Java web project, you need to have the following software installed: a Java JDK, a recent version of Eclipse that contains the WTP Web Tools Platform module for Eclipse, and a web container or an application server, such as Tomcat, JBoss, WebSphere, etc.

1…Select File/New/Project from the menu. The following dialogue appears:

2…Select Dynamic Web Project from the list and click on the Next button.

3…Type a name for the new project and select a file system location for it. In the Target Runtime option, specify the web container or application server you using. This server is used to build and deploy your web application. If the drop-down box does not contain the desired server, click New… and select one of the predefined configurations (see Step 4). If you have already defined a Target Runtime, you can skip ahead to Step 6. The Dynamic Web Module version option specifies the architecture you are going to use in the web project. Select the latest version for a new project. Unfortunately, this cannot be changed later. By clicking the Modify… button in the Configuration section, you can select “facets” for your web application. What Eclipse calls “facets” are various building blocks and APIs, such as Java Server Faces, Java Persistence API, etc., that add functionality to your application.

4…The New… button in the Target Runtime section opens a dialogue that lets you select the server on which the application is developed and deployed, which is probably the most important aspect of your configuration. Eclipse offers a number of common configurations for popular servers. If you cannot find your server in this list, click on the Download additional server adapters link and chances are that your server is listed. Make sure that the Create a new local server option is checked, so that you can find the server in the Eclipse server view later on.

5…Once you specified the server type, you need to provide some details about it, such as the installation directory of the server, or the server root, and the JRE you want the server to run on. Click Finish when done.

6…Finally, the dynamic web project wizard prompts you for some basic configuration data. The Context Root is the name that the web container matches with the  location where the application is deployed and simultaneously constitutes the root URL for the web application. The Content Directory specifies the name of the directory that contains the web application files. The Java Source Directory specifies the name of the directory that contains Java source code files. These settings are only relevant to the development machine. Make sure that the Generate deployment descriptor option is checked in order to automatically create the web.xml file. In most cases, you can probably accept the default settings and click Finish.

7…Voilá. You have created a web application, or rather the framework for its development in Eclipse. The new project should now be visible in the Navigator view. There aren’t any files yet, except the ones which were generated automatically by Eclipse. The next step would be to write your web application, and possibly incorporating the application framework of your choice. Piece of cake.

8…The Server view should display the server you have chosen for your project. If everything went OK, you can start and stop the server from this view. The server can be started in normal mode, debug mode, or profiling mode. Debug mode needs to be selected if you want to define breakpoints in your Java code. While you edit sources, such as JSP files, servlets, bean classes, static content, etc., Eclipse automatically redeploys these resources to the running server as soon as you save them. You can view your web application in a separate browser window and receive debug output in Eclipse’s Console view.

9…After you have written your formidable web application, it’s time to share it with the world, or in more technical terms, to distribute and deploy it. The process of creating a distributable WAR file is extremely simple. Select File/Export from the Eclipse menu and click on the WAR file option in the Web category.

10…After clicking the Next button, specify the web project to be packaged, the file destination, and the target server. Although the latter is not a mandatory option, it is probably an important one. The selected server is likely to be the same as the one chosen in Step 3. Click Finish and there you have your masterpiece in a handy WAR format.

However, the question I am asking myself now is – isn’t this device just an expensive toy? Where is the robustness that should come with a “business” device . I have put in a good deal of time just to keep my pocket PC working. My HP PPC has seen the service shop twice, once because of a faulty memory chip, and another time because it didn’t boot anymore until the shop installed a firmware upgrade. In addition to that, I have spent a fair number of hours with configuration and trouble-shooting because one or another function was broken. Once I get a working configuration with all the software installed, I use Spb Backup to create a complete backup of the system. Spb Backup is a real life-saver. It backs up all configuration data, user data, applications and system data. Should the device give up its ghost or display odd behaviour (believe me, every Pocket PC will do that at some point), I can perform a factory reset and restore the backup to recreate the former status of the device easily. But even with this tool, the amount of maintenance required seems a little excessive. A gadget that carries the name “Business Navigator” should be expected to work like a business device, namely reliably. Unfortunately, I can’t say that for the HP iPaq and neither for the other Pocket PCs I’ve owned and used. As previously mentioned, I am not blaming the hardware manufacturers. The OS seems to be the crux.

Real business users would probably be better off with a smartphone that requires less messing around. A Pocket PC is more suited to -shall I put it this way- the technically inclined person.

Byte     8-bit Integer (-2^7 to 2 ^7-1)
Short    16-bit Integer (-2^15 to 2^15-1)
Int      32-bit Integer (-2^31 to 2^31-1)
Long     64-bit Integer (-2^64 to 2^64-1)
Char     16-bit Unicode character (0 to 2^16-1)
String   A sequence of Chars
Float    32-bit IEEE 754 single-precision floating point number
Double   64-bit IEEE 754 double-precision floating point number
Boolean  Logical value (true or false)

These data types are defined in the package scala, which is imported automatically along with scala.lang by the compiler. Extended functionality for these types (such as the cited max() function) is available via the scala.runtime API. Each type has an associated “rich wrapper class”, e.g for String there is a RichString class, for Int there is a RichInt class, and so on. Unlike Java, Scala does not distinguish between objects and primitive types. This implies that there are no boxing and unboxing functions and thus less to worry about the semantic details of these operations. Everything is simply an object. Behind the scenes the compiler performs optimisations that amount to auto-unboxing when arithmetic expressions are evaluated. Hence, the expression a + b * c which is equivalent to method calls b.*(c).+(a) is actually resolved to a primitive type arithmetic, just like in Java.

Scala is not only object-oriented in the sense that all variables are objects, irrespective of type, but that all functions including methods are also objects. Since functions and methods are objects, they are treated just like regular variables, which means that functions can be assigned to variables. They can also be used as parameters in function calls or as return values of functions and methods. A function value in the position of a function parameter creates a so-called higher-order function. In addition, Scala has a construct called a function literal which is basically a nameless function used in place of a function value, a bit like an anonymous method in Java, although the former are a lot more versatile. Furthermore, operators in Scala are methods. This makes some sort of operator overloading possible. Since +,-,*,/ etc. are just methods with funny names, you can define operators for your own data types. It is therefore possible to extend the language by adding APIs that contain class definitions for new data types along with their operators. This is illustrated by the following class definition for rational numbers. Rational numbers can be expressed as a fraction of two integer numbers. The following class defines the data type Rational as well as the four basic arithmetic operations for rational numbers:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

class Rational(numerator: Int, denominator: Int) {
 
  require(denominator != 0)
 
  private val gcd = greatestCommonDivisor(numerator.abs,
    denominator.abs)
  val n = numerator / gcd
  val d = denominator / gcd
 
  def this(n: Int) = this(n, 1)
 
  private def greatestCommonDivisor(a: Int, b: Int): Int =
  if (b == 0) a else greatestCommonDivisor(b, a % b)
 
  def + (that: Rational): Rational =
  new Rational(n * that.d + d * that.n, d * that.d)
 
  def - (that: Rational): Rational =
  new Rational(n * that.d - d * that.n, d * that.d)
 
  def * (that: Rational): Rational =
  new Rational(n * that.n, d * that.d)
 
  def / (that: Rational): Rational =
  new Rational(n * that.d, d * that.n)
 
  override def toString = n + "/" + d
}

The first line contains the head of the class with the so-called primary constructor, which is part of the class declaration in Scala. The expression in parentheses accepts two integer numbers that constitute the numerator and the denominator of the fraction. The next line that starts with require tests the denominator for zero and throws an exception if denominator = 0. As you can see, exceptions don’t need to be declared in the head of the class definition in Scala. The following three lines reduce the fraction by calculating the greatest common divisor and subsequently dividing the numerator and denominator by the result. These first four lines are not enclosed by a function definition block or any other block and thus constitute the body of the primary constructor. Next follows what’s called a auxiliary constructor in Scala. Auxiliary constructors are easy to spot, because they always start with this(). The expression def this(n: Int) = this(n, 1) provides a constructor that accepts a single integer number as an argument. This makes it easy to represent integer numbers as fractions where needed simply by setting the denominator implicitly to 1. For example, the expression new Rational(2,3) results in 2/3 and the expression new Rational(2) results in 2/1.

The method definition that follows the constructor code computes the greatest common integer divisor of two numbers using recursion. Since the recursive invocation stands in tail-call position in this instance, the Scala compiler optimises the generated byte code  internally and creates a loop instead of a recursive function call. The four methods after the greatestCommonDivisor() method define the four basic arithmetic operations for fractions. In case of addition and subtraction, the numerators and denominators of both operands are multiplied with each other before the sum of the numerators is calculated. In doing so, Scala makes use of built-in operator precedence (* and / before + and -), which is determined lexically if the function or method name begins with a special operator characters. The expression  n * that.d + d * that.n, is thus executed as n.*(that.d).+.(d.*(that.n)). Multiplication and division are even easier to implement as the two fractions are simply multiplied by each other, or respectively multiplied by the reciprocal value. The results are then returned as new Rational objects. Since the constructor finds the GCD of the two integer numbers, the resulting fraction is automatically reduced. Finally, the last method toString outputs the fraction in a readable form. Overridden methods must be marked with the override keyword in Scala. Functions that don’t take arguments are written without parentheses, hence toString() becomes toString.

Class Hierarchy

Similar to Smalltalk, every class inherits from a single common superclass. The universal superclass is named Any in Scala. This is to say that any datum in Scala is of the type Any. The subclasses of Any fall into two categories: AnyVal (value) and AnyRef (object reference). The above listed basic data types, as well as the primitive types in Java, such as byte, int, float, etc., are direct descendants of AnyVal, while all other types are descendants of AnyRef. The Scala type AnyRef is therefore conceptually identical with java.lang.Object and it comes with analogous methods, e.g. equals(), hashCode, clone, wait, etc. Some of these are actually defined further up in the hierarchy, namely in Any. In addition, Scala defines the type scala.scalaObject which provides the common superclass for all objects in the Scala APIs. This works because Scala allows multiple inheritance via so-called traits. This will be explained later in more detail.

The nesting of this type hierarchy allows interoperability wit Java. For example:

1
2
3

var a: int = 2    // Java Integer
var b: Int = 3    // Scala Integer
println(a + b)    // 5

In addition, it is possible to use Java collections for storing Scala data types, or Scala collections for storing Java data types. Furthermore, Scala has several special data types. For example, scala.Null is defined as subtype of any class that derives from an object reference scala.AnyRef. It is analogous to the null literal in Java and can thus be assigned to object references. The type scala.Nothing is defined as a subtype of all types; it is employed in exceptions where an expression does not return a type. This happens situations where an exception is thrown in a place where a value is expected. Finally, there is the type scala.Unit that is used for functions that don’t return a value. This is Scala’s concession to imperative programming. It is analogous to the void keyword in Java.

While the HTML 4.01 specification has ruled the Web since 1999, the fifth incarnation of HTML was released by the W3C as a working draft earlier this year and is constantly updated since then. The HTML 5 specification is supposed to pave the way for future Web standards. It contains an older draft of W3C dubbed “Web Forms 2.0”, which is W3C’s answer to Web 2.0 and the World Wide Web becoming a platform for distributed applications. Don’t expect anything too radical, though. It neither delivers the hailed “rich GUI” for the Internet, nor will it replace current technologies like AJAX. It is rather designed as a natural extension of the former. It provides good backward compatibility while smoothing some of the rough edges of HTML. No more no less. Let’s have a look at the new features in more detail.

HTML 5 mends the split between the preceding HTML 4 and XHTML 1.0 specifications. Rather than being defined in terms of syntactical rules, it makes the DOM tree its conceptual basis. Thus HTML 5 can be expressed in two similar syntaxes, the “traditional” one and the XML syntax, which both result in the same DOM tree. It goes far beyond the scope of previous specifications, for example by spelling out how markup errors are handled, rather than leaving it to browser vendors, and by specifying APIs for new and old elements. These APIs describe how scripting languages interact with HTML. So, what’s new? The following elements have been dropped from the specification:

• <acronym>
• <applet>
• <basefont>
• <center>
• <dir>
• <font>
• <frame>
• <frameset>
• <isindex>
• <noframes>
• <s>
• <small>
• <strike>
• <tt>
• <u>
• <xmp>

The following attributes are also goners:

abbr, accesskey, align, alink, axis, background, bgcolor, border, cellpadding and cellspacing, char, charoff, charset, classid, clear, compact, codebase, codetype, coords, declare, frame, frameborder, headers, height, hspace, language, link, marginheight and marginwidth, name, nohref, noshade, nowrap, profile, rules, rev, scope, scrolling, shape, scheme, size, standby, summary, target, text, type, valuetype, valign, version, vlink, width.

Some of these elements and attributes are quite obscure, so perhaps they won’t be missed. Others like <center>, align, background, and <u> were heavily used in the past, although most of these were already deprecated in HTML 4. The message here is clear: get rid of presentational markup and use CSS instead. The <b>, <i>, <em> and <strong> tags have miraculously survived, however. Although primarily used for text formatting in the past, these tags have been assigned new (non-presentational) semantics to make them respectable. Another conspicuous omission are frames. Yes, frames are gone! But you might breath a sigh of relief to know that <iframe> is still there. Speaking presentational versus semantic HTML, there are quite a few additions to HTML 5 in the latter category. The new semantic tags are designed to aid HTML authors in structuring text and to make it easier for search engine crawlers to parse information in web pages. Here they are (explanations provided by W3C):

• <section> represents a generic document or application section. It can be used together with h1-h6 to indicate the document structure.
• <article> represents an independent piece of content of a document, such as a blog entry or newspaper article.
• <aside> represents a piece of content that is only slightly related to the rest of the page.
• <header> represents the header of a section.
• <footer> represents a footer for a section and can contain information about the author, copyright information, et cetera.
• <nav> represents a section of the document intended for navigation.
• <dialog> can be used to mark up a conversation in conjunction with the <dt> and <dd> elements.
• <figure> can be used to associate a caption together with some embedded content, such as a graphic or video.
• <details> represents additional information or controls which the user can obtain on demand.

Most of these, except the last two, behave like the <div> element, which means their primary use is to identify a block of content that belongs together. Unlike <div> special semantics are associated with each of these elements. Not very exciting? HTML 5 also introduces the following new elements (explanations again from the W3C document):

• <audio> and <video> for multimedia content. Both provide an API so application authors can script their own user interface, but there is also a way to trigger a user interface provided by the user agent. Source elements are used together with these elements if there are multiple streams available of different types.
• <embed> is used for plugin content.
• <mark> represents a run of marked (highlighted) text.
• <meter> represents a measurement, such as disk usage.
• <time> represents a date and/or time.
• <canvas> is used for rendering dynamic bitmap graphics on the fly, such as graphs, games, et cetera.

The <embed> tag supersedes the <applet> and <object> tags. It defines some sort of embedded content that doesn’t expose its internal structure to the DOM tree. The content is typically rendered by a browser plugin. The <audio> and <video> tags are perhaps more interesting, because they make it possible to include multimedia files or streams directly into the HTML document without having to specify a vendor-specific plugin for playing the content. Granted, this could previously be done with the <embed> tag, but the <embed> tag was never a W3C standard and it isn’t supported by all browsers. Obviously, W3C has decided not to follow the mainstream browser implementations and added the <audio> and <video> tags instead, while reserving the <embed> tag for the above named purpose.

Arguably the most exciting additions to HTML 5 -at least from the perspective of a web developer- are the extensions to form processing and data rendering, and the related APIs, such as the editing API or the drag-and-drop API. These additions have previously evolved as a separate standard under the term Web Forms 2.0 and are now incorporated into HTML 5. The <input> element has been enhanced to support several new data types. New elements for user interface components have been defined, similar to those that can be found in GUI applications. For example, HTML 5 finally features the long awaited combo box, a combination of text input and drop-down list, which is a standard component in GUIs for decades. A new <datagrid> element for the interactive/editable representation of data in tabular, list, or tree form, is also present. Here are the new <input> types:

• type=”datetime”- a date and time (year, month, day, hour, minute, second, fraction of a second) with the time zone set to UTC.
• type=”datetime-local”- a date and time (year, month, day, hour, minute, second, fraction of a second) with no time zone.
• type=”date” - a date (year, month, day) with no time zone.
• type=”month” - a date consisting of a year and a month with no time zone.
• type=”week” - a date consisting of a year and a week number with no time zone.
• type=”time”- a time (hour, minute, seconds, fractional seconds) with no time zone.
• type=”number” - a numerical value.
• type=”range” - a numerical value, with the extra semantic that the exact value is not important.
• type=”email”- an e-mail address.
• type=”url” - an internationalised resource identifier.

The input element also has several new attributes in HTML 5 that enhance its functionality (many of these also apply to other form controls such as <select>, <textarea>, etc.):

• list=”listname” - used in conjunction with the <datalist> element to create a combobox.
• required - indicates that the user must provide an input value.
• autofocus - automatically focuses the control upon page load.
• form - allows a single control to be associated with multiple forms.
• inputmode - gives a hint to the user interface as to what kind of input is expected.
• autocomplete - tells the browser to remember the value when the user returns to the page.
• min - minimum value constraint.
• max - maximum value constraint.
• pattern - specifies pattern constraint.
• step - specifies step constraint.

The following new elements provide additional user interface components for web applications. The last three are actually not themselves UI components, but components used for scripting the UI through a server side language:

• <command> represents a command the user can invoke (e.g. toolbar button or icon).
• <datalist> together with the a new list attribute for input is used to create comboboxes.
• <output> represents some type of output, such as from a calculation done through scripting.
• <progress> represents a completion of a task, such as downloading or when performing a series of expensive operations.
• <menu> represents a menu. The element has three new attributes: type, label and autosubmit. They allow the element to transform into a menu as found in typical user interfaces as well as providing for context menus in conjunction with the global contextmenu attribute.
• <datagrid> represents an interactive representation of a tree list or tabular data.
• <ruby>, <rt> and <rb> allow for marking up Ruby annotations.
• <eventsource> represents a target that “catches” remote server events.
• <datatemplate>, <rule> and <nest> provide a templating mechanism for HTML.

Let’s briefly look at the new <datagrid> element. <datagrid> usually has a <table> child element, although <select> and <datalist> are also possible to create a tree control. The columns in the datagrid can have clickable captions for sorting. Columns, rows, and cells can each have specific flags, known as classes, which affect the functionality of the datagrid element. Rows are selectable and single cells (or all cells) can be made editable. A cell can contain a checkbox or values that can be cycled. Rows can also be separator rows. Datagrids have a DOM API for updating, inserting, and deleting rows or columns. They also have a data provider API that controls grid data content and editing.

I hope you found this brief overview useful. Please note that the features mentioned here don’t cover everything that is new in HTML 5, but hopefully they catch the essence. The HTML 5 specification is a work in progress; it is still changing and evolving. You can find the latest editor’s draft at http://www.w3.org/html/wg/html5/. An overview of the changes from HTML 4 is available at http://www.w3.org/TR/html5-diff/.

What is more, Scala is a rich statically typed language that provides the ease of use of a scripting language. Scala’s object-oriented features are at least as powerful as those of Java. Scala also offers a full set of functional programming features. It is the felicitous combination of object-oriented and functional properties that makes this language interesting. As of today, Scala already has closures, support for properties, an Erlang-like concurrency API (excellent for multi-core parallel programming) as well as other advanced features that Java will only have in future releases, or possibly never. For this reason, I would like to introduce this language to interested readers in a brief tutorial. Once you get to know Scala, you might agree that it’s a fascinating language. So let’s get started. The obvious starting point is the (in-)famous “Hello World” program, or rather a slightly more involved version of it:

1
2
3
4
5
6

object Hello {
  def main(args: Array[String]) {
    for(val arg: String <- args)
      System.out.println("Hello, " + arg + "!");
  }
}

Any Java programmer should be able to understand what these six lines of code do, despite it being written in a “foreign” language. The program prints a greeting for each of the arguments passed to it. The invocation “scala Hello World” prints the inspiring yet slightly trite line “Hello Word!”. For more fun, you could pass the names of all 190 and odd countries and the program would greet each nation individually. There are some obvious differences to Java. For example, there are no static or void declarations. Another obvious difference is that the program starts with an object definition rather than a class definition. In Scala, the keyword object creates a singleton object, which is akin to a class that contains only static members, except that the Scala object is able to make use of inheritance and polymorphic invocation.

Method definitions start with the keyword def in Scala. The single argument to the main method is args which is of type Array[String], meaning “array of string”. The method contains a for-loop that looks similar to the Java-5 foreach loop construct. It iterates over the elements in the string array args. The expression val arg: String is equivalent to the Java expression final String arg. The keyword val declares an immutable variable, which means that its value cannot be changed after it has been assigned a value. Scala also has mutable variables which are declared with var instead of val. The variable arg is of type String and it takes the value of the iterator variable. It is possible to simplify the program a little:

1
2
3
4
5
6

object Hello {  
  def main(args: Array[String]) {
    for(val arg <- args)
      println ("Hello, " + arg + "!")
  }
}

In this version, the following items have been omitted:

The type declaration : String after arg was eliminated. Although Scala is a statically typed language, which means that every variable has a fixed type, it can infer type declarations automatically. In this case, it infers that the arg variable is of type String because the args variable is of type array of String. This feature is known as type inference and it contributes to making Scala source code more concise by eliminating redundant type declarations. Other examples for type inference are:

1
2
3

val a = "Abacadabra"
val b = 3.141592
val c = Map(1 -> "alpha", 2 -> "beta", 3 -> "gamma")

The types of the variables a, b, c are derived from the literal values. Variable a is a String, b is a Double, and c is a Map that maps Integer values to String values. The above listing also does without the System.out in System.out.println() which results in just println(). Since println() is a frequently used statement, the method context is predefined by Scala. Java programmers may think of this as an automatic static import. Another thing that is absent from the simplified version of the program is the semicolon after the println() call. Semicolons are mostly optional in Scala, except in situations where multiple expressions are stringed together in one line. The code already looks simple, but with Scala we can make it even more concise by replacing the for loop with a foreach() invocation:

1
2
3
4
5

object Hello { 
  def main(args: Array[String]) {
    args.foreach(arg => println("Hello" + arg + "!"))
  }
}

The foreach construct iterates over args, creating a String variable arg variable each time and calls println() on every iteration. The expression with the arrow (an equals sign followed by a greater than sign) this => that can be read “with a given argument this do that”. It is called a function literal in Scala. Granted, in this case it doesn’t save us much typing, but if we wanted to print just the arg variable and if we didn’t refer to it in the expression following the arrow =>, we could just write it as: args.foreach(println), which is the short form for args.foreach(arg => println(arg)).

I hope that this first glance at Scala has whetted your appetite for more. The cited examples are fairly unsophisticated. The next section, which discusses Scala’s types and object hierarchy, will introduce some more involved concepts.

The first question is easy to answer. Graduated types result from the fact that computer architectures have evolved in powers of two. Over several decades, the register width of the CPU of an average PC has expanded from 8 to 16 to 32 to  64 bits. Each step facilitated the use of larger types and numeric types in particular were closely matched to register width. Expressing data types in a machine-oriented way appears to be a C legacy and quite a few newer programming languages have been strongly influenced by C. - It is my contention that while curly braces and ternary operators are an acceptable C-language tradition, graduated types are definitely not. Why not? Because they counter abstraction. They hinder rather than serve the natural expression of mathematical constructs. Have you ever wondered whether you should index an array with byte- or short-sized integers? Whether you should calculate an offset using int or long values? Whether method calls comply with type widening rules? Whether an arithmetic operation might overflow? Whether a type cast may lose significant bits or not? All of this is a complete waste of time in my view. Wouldn’t it be better to let the virtual machine worry about such low-level questions, or the library if a VM is not present? Cup typing gets positively annoying when you have to write an API that is flexible enough to deal with parameters of different widths. If there’s no type hierarchy, you inevitably end up with multiple overloaded constructors and methods (one for each type) which add unnecessary bulk. The Java APIs are full of such examples and the valueOf() method is a case in point - it’s really ugly.

However, graduated types are beyond ugly; they are outright evil. They cause an enormous number of bugs and the small numeric types are the prime offenders. I wonder how many times a signed or unsigned byte has caused erratic program behaviour by silently overflowing. Such bugs can be hard to find and worse – they often don’t show until certain border conditions are reached. Casts that shorten types also belong to the usual suspects. I shall not even mention the insidious floating point operations that regularly unsettle newbie programmers with funny looking computation results. What numeric types does one really need? - Integer numbers and real numbers. One of each and not more. - If you want to be generous as a language designer, you can throw in an optimised implementation of a complex number type and a rational number type. However, in an object-oriented language with operator overloading, it’s fairly easy to express these in a library. The fixed comma type (sometimes called decimal type) is the subset of the rational type where the denominator is always a power of ten. So, that’s really all you need – a clean representation of the basic mathematical number systems.

At this point, you might object: “but the CPU register is only x bits wide,” or “how do I allocate an array of fifty thousand short values?”, or “can I still have 8-bit chars?” Unfortunately, there is no simple answer to these questions. The natural way to represent integers is to always use the machine’s native word width, but unfortunately that doesn’t solve the problem. First of all, the word width is architecture dependent. Second, it might be wasteful for large arrays that hold small numbers and on the other hand it would still be too small for applications that need big integers. The solution is of course a variable size type, i.e. an integer representation that can grow from byte size to multiple word lengths. We have variable length strings, so why shouldn’t we have variable length numbers? It seems perfectly natural. There is certainly some overhead involved, because variable length types need special encoding. The overhead will be most likely due to loading a descriptor value and/or to bit shifting operations. After all, variable length numbers don’t come for free, but they do offer tremendous advantages. They relieve the programmer from making type width decisions, as well as documenting these decisions - and worse - changing the type width later if the decision turned out to be inadequate. Furthermore, they eliminate the above mentioned bugs resulting from silent overflows and type cast errors, not to mention API proliferation due to type plurality. Thus variable length numbers are generally preferable to common fixed width types.

Of course, there are situations where you know that you will never need more than a byte. There are also situations where performance is paramount. In addition, APIs and libraries based on multiple fixed types are not going to disappear overnight. To provide backward compatibility and to offer optimisation pathways to the programmer, a language could present these as subsets of the mathematical type. For example, if a language defines the keyword “int” for variable length integer numbers, then “int(8)” could mean a traditional byte, “int(16)” could mean a short word, and so on. Now, this is a bit like reintroducing cup typing through the back door. Therefore the use of subtypes for general purpose computations should be discouraged. However, it’s always better to have a choice of fixed and variable types than having no variable types at all.

…when you type a company memo and begin with the heading “public static final”.
…when you drop your used paper cups on the floor stating that the garbage collector will take care of it.
…when most of your email attachments are jar files.
…when you feel lost without an application server.
…when you refer to your wife as domestic domain expert.
…when you say “use case actor” instead of “user”.
…when you attempt to subclass meeting agendas.
…when you write down your shopping list in string array notation.
…when you think that the “Java community process” has nothing to do with Indonesian politics.
…when you begin all your annotations with an “@” sign.
…when you can type “System.out.println” in less than 2 seconds.

Increasing the clock speed of a CPU has the effect, that program execution speed increases proportionally with clock speed. The increase is independent of software and hardware architectures. A sequential algorithm simply runs twice as fast on a machine where CPU operations take half the time. Unfortunately, this is not the case for a machine with twice as many CPUs. A sequential algorithm runs just as fast on a 3 GHz single core CPU than on a 3 GHz dual core CPU, because it uses only one of the CPU cores. Increased overall execution speed is therefore only achieved when multiple tasks run concurrently, because they can be executed simultaneously on different CPUs. This problem of parallelism is not new in computer science. Unfortunately though, today’s programming languages aren’t very well equipped to deal with parallel scaling. The computer language idiom that typifies multi-core concurrency is the thread model. Threads are lightweight processes that are typically used for self-contained subtasks. Several languages, notably Java, offer APIs and native support for their implementation. Threads are well suited to asynchronous processing, for example in communication and networking. They can also be used for simple parallelisation, where a computing problem is parallel by nature (for example serving multiple web documents at the same time). However, threads are relatively cumbersome and thus not really suitable for fine-grained parallel programming, such as traversing data structures or executing nested loops in parallel. Edward A. Lee describes the problems with threads in this excellent article.

The fundamental problem that software engineers face is described by Amdahl’s law. Amdahl’s formula expresses the speed gain of an algorithm achieved by parallelisation: speedup = N / ( (B*N) + (1-B) ), where B is the non-parallelizable (sequential) percentage of the problem and N is the number of worker threads, or processor cores. There are two notable things about Amdahl’s law: (1) the speedup is highly dependent on B, and (2) the curve flattens logarithmically with increasing N. It’s also important to know that Amdahl’s law assumes a constant problem size, which is unrealistic given that parallelisation  requires a certain amount of control overhead. Nevertheless, we can draw several conclusions from Amdahl’s law. First, the performance gain from parallel scaling is lower than that of frequency scaling. Second, it is not proportional to the number of cores. Third, it is highly dependent on software architecture, since the latter chiefly determines the size of B. From the perspective of a software engineer, the last conclusion is probably the most interesting one. It leads to the question what can be done to maximise parallelisation at the level of the algorithm exploiting data and task parallelisms. The present thread model is too coarse-grained to provide solutions at the algorithm-level. Hence, what is called for are new programming idioms that make this task easier.

Ideally, parallelisation is fully automatic, implemented by the compiler and the underlying hardware architecture. In this case, the application programmer could simply continue to formulate sequential algorithms without having to worry about parallelism. Unfortunately, automatic parallelisation has turned out to be extremely complex and difficult to realise. Despite many years of research in compiler architecture, there are no satisfactory results. Parallelisation at the algorithm level involves several abstraction steps, such as decomposition, mapping, scheduling, synchronisation, and result merging. The hardest among these tasks is very likely decomposition, which means breaking down a sequential task into parts that can be solved in parallel. The preferred method for doing this is divide and conquer. A problem is divided into identical smaller pieces, whereas the division can be expressed recursively or iteratively. The problem chunks can then be solved in parallel and the subtask results are joined into one final result. Prime examples for this strategy are merge sort and sequential search algorithms. These are easily parallelisable. Likewise many operations on arrays and collections can be parallelised fairly easily. But certain tasks are not obviously parallelisable, for example the computation of the Fibonacci series: f (n) = f (n-1) + f (n-2). Since every step in the computation depends on the previous step, the Fibonacci algorithm is sequential by nature. In theoretical informatics, the question whether algorithms of the complexity classes P and NP are in principle parallelisable is still unsolved. For practical purposes, some problems are simply non-parallelisable.

Given that automatic parallelisation is currently out of reach, the need for the facilitation of algorithm parallelisation in computer languages boils down to (1) the need for expressive constructs that allow programmers to express parallelisms intuitively, and (2) the need for freeing programmers from writing boilerplate code for the drudge work of parallel execution, such as scheduling, controlling, and synchronisation. There are already a number of computer languages that provide built-in idioms for parallel programming, such as Erlang, Parallel Haskell, MPD, Fortress, Linda, Charm++ and others. However, these are fringe languages with a small number of users. It is questionable whether the   parallel scaling trend in hardware will lead to a wide adoption of any of these languages. Perhaps mainstream languages will evolve to acquire new APIs, libraries, and idioms to support parallel programming. For example, there are Compositional C++, MPI, Unified Parallel C, Co-Array Fortran and other existing extensions that make widely used languages more suitable for parallel programming, although there aren’t any established standards yet. It also remains to be seen whether the functional programming paradigm will catch on in view of parallel programming. Java is promising, because the JDK 7 (Dolphin) will contain a  new API for fine-grained parallel processing. In this very informative article by Brian Goetz, the author of Java Concurrency in Practice, introduces the new java.util.concurrency API features of Java SE 7. It will include a fork-join framework that simplifies the expression of parallel processing, for example in loops or in recursive method invocation. It will also provide new data structures, such as ParallelArray, that make parallel iteration easier to express. To learn more about parallel computing, read the free Introduction To Parallel Computing by Blaise Barney or search the free parallel programming books at Google Books.