Introduction to scripting in Java, Part 1

	Excerpt from Scripting in Java: Languages, Frameworks, and Patterns.
By Dejan Bosanac Published by Addison Wesley Professional ISBN-10: 0-321-32193-6 ISBN-13: 978-0-321-32193-0

Until recently only the hardcore were excited about scripting on the Java platform, but that was before Sun boosted the JRE’s support for dynamically typed languages like Python, Ruby, and JavaScript. In this two-part excerpt from the forthcoming Scripting in Java: Languages, Frameworks, and Patterns (Addison Wesley Professional, August 2007) Dejan Bosanac narrows in on what differentiates most scripting languages from a programming language like Java, then explains why scripting is a time-worthy addition to your Java programming skillset.

Introduction to Scripting in Java: Languages, Frameworks, and Patterns

The main topic of this book is the synergy of scripting technologies and the Java platform. I describe projects Java developers can use to create a more powerful development environment, and some of the practices that make scripting useful.

Before I start to discuss the application of scripting in the Java world, I summarize some of the theory behind scripting in general and its use in information technology infrastructure. This is the topic of the first two chapters of the book, and it gives us a better perspective of scripting technology as well as how this technology can be useful within the Java platform.

To begin, we must define what scripting languages are and describe their characteristics. Their characteristics greatly determine the roles in which they could (should) be used. In this chapter, I explain what the term scripting language means and discuss their basic characteristics.

At the end of this chapter, I discuss the differences between scripting and system-programming languages and how these differences make them suitable for certain roles in development.

Background

The definition of a scripting language is fuzzy and sometimes inconsistent with how scripting languages are used in the real world, so it is a good idea to summarize some of the basic concepts about programming and computing in general. This summary provides a foundation necessary to define scripting languages and discuss their characteristics.

Let’s start from the beginning. Processors execute machine instructions, which operate on data either in the processors’ registers or in external memory. Put simply, a machine instruction consists of a sequence of binary digits (0s and 1s) and is specific to the particular processor on which it runs. Machine instructions consist of the operation code telling the processor what operation it should perform, and operands representing the data on which the operation should be performed.

For example, consider the simple operation of adding a value contained in one register to the value contained in another. Now let’s imagine a simple processor with an 8-bit instruction set, where the first 5 bits represent the operation code (say, 00111 for register value addition), and the registers are addressed by a 3-bit pattern. We can write this simple example as follows:

00111 001 010

In this example, I used 001 and 010 to address registers number one and two (R1 and R2, respectively) of the processor.

This basic method of computing has been well known for decades, and I’m sure you are familiar with it. Various kinds of processors have different strategies regarding how their instruction sets should look (RISC or CISC architecture), but from the software developer’s point of view, the only important fact is the processor is capable of executing only binary instructions. No matter what programming language is used, the resulting application is a sequence of machine instructions executed by the processor.

What has been changing over time is how people create the order in which the machine instructions are executed. This ordered sequence of machine instructions is called a computer program. As hardware is becoming more affordable and more powerful, users’ expectations rise. The whole purpose of software development as a science discipline is to provide mechanisms enabling developers to craft more complex applications with the same (or even less) effort as before.

A specific processor’s instruction set is called its machine language. Machine languages are classified as first-generation programming languages. Programs written in this way are usually very fast because they are optimized for the particular processor’s architecture. But despite this benefit, it is hard (if not impossible) for humans to write large and secure applications in machine languages because humans are not good at dealing with large sequences of 0s and 1s.

In an attempt to solve this problem, developers began creating symbols for certain binary patterns, and with this, assembly languages were introduced. Assembly languages are second-generation programming languages. The instructions in assembly languages are just one level above machine instructions, in that they replace binary digits with easy-to-remember keywords such as ADD, SUB and so on. As such, you can rewrite the preceding simple instruction example in assembly language as follows:

ADD R1, R2

In this example, the ADD keyword represents the operation code of the instruction, and R1 and R2 define the registers involved in the operation. Even if you observe just this simple example, it is obvious assembly languages made programs easier for humans to read and thus enabled creation of more complex applications.

Although they are more human-oriented, however, second-generation languages do not extend processor capabilities by any means.

Enter high-level languages, which allow developers to express themselves in higher-level, semantic forms. As you might have guessed, these languages are referred to as third-generation programming languages. High-level languages provide various powerful loops, data structures, objects, and so on, making it much easier to craft many applications with them.

Over time, a diverse array of high-level programming languages were introduced, and their characteristics varied a great deal. Some of these characteristics categorize programming languages as scripting (or dynamic) languages, as we see in the coming sections.

Also, there is a difference in how programming languages are executed on the host machine. Usually, compilers translate high-level language constructs into machine instructions that reside in memory. Although programs written in this way initially were slightly less efficient than programs written in assembly language because of early compilers’ inability to use system resources efficiently, as time passed compilers and machines improved, making system-programming languages superior to assembly languages. Eventually, high-level languages became popular in a wide range of development areas, from business applications and games to communications software and operating system implementations.

But there is another way to transform high-level semantic constructs into machine instructions, and that is to interpret them as they are executed. This way, your applications reside in scripts, in their original form, and the constructs are transformed at runtime by a program called an interpreter. Basically, you are executing the interpreter that reads statements of your application and then executes them. Called scripting or dynamic languages, such languages offer an even higher level of abstraction than that offered by system-programming languages, and we discuss them in detail later in this chapter.

Languages with these characteristics are a natural fit for certain tasks, such as process automation, system administration and gluing existing software components together; in short, anywhere the strict syntax and constraints introduced by system-programming languages were getting in the way between developers and their jobs. A description of the usual roles of scripting languages is a focus of Chapter 2, “Appropriate Applications for Scripting Languages.”

But what does all this have to do with you as a Java developer? To answer this question, let’s first briefly summarize the history of the Java platform. As platforms became more diverse, it became increasingly difficult for developers to write software that can run on the majority of available systems. This is when Sun developed Java, which offers “write once, run anywhere” simplicity.

The main idea behind the Java platform was to implement a virtual processor as a software component, called a virtual machine. When we have such a virtual machine, we can write and compile the code for that processor, instead of the specific hardware platform or operating system. The output of this compilation process is called bytecode, and it practically represents the machine code of the targeted virtual machine. When the application is executed, the virtual machine is started, and the bytecode is interpreted. It is obvious an application developed in this way can run on any platform with an appropriate virtual machine installed. This approach to software development found many interesting uses.

The main motivation for the invention of the Java platform was to create an environment for the development of easy, portable, network-aware client software. But mostly because of performance penalties introduced by the virtual machine, Java is now best suited in the area of server software development. It is clear as personal computers increase in speed, more desktop applications are being written in Java. This trend only continues.

One of the basic requirements of a scripting language is to have an interpreter or some kind of virtual machine. The Java platform comes with the Java Virtual Machine (JVM), which enables it to be a host to various scripting languages. There is a growing interest in this area today in the Java community. Few projects exist that are trying to provide Java developers with the same power developers of traditional scripting languages have. Also, there is a way to execute your existing application written in a dynamic language such as Python inside the JVM and integrate it with another Java application or module.

This is what we discuss in this book. We take a scripting approach to programming, while discussing all the strengths and weaknesses of this approach, how to best use scripts in an application architecture, and what tools are available today inside the JVM.

Definition of a scripting language

There are many definitions of the term scripting language, and every definition you can find does not fully match some of the languages known to be representatives of scripting languages. Some people categorize languages by their purpose and others by their features and the concepts they introduce. In this chapter, we discuss all the characteristics defining a scripting language. In Chapter 2, we categorize scripting languages based on their role in the development process.

Compilers vs. interpreters

Strictly speaking, an interpreter is a computer program that executes other high-level programs line by line. Languages executed only by interpreters are called interpreted languages.

To better understand the differences between compilers and interpreters, let’s take a brief look at compiler architecture (see Figure 1.1).

As you can see in Figure 1.1, translating source code to machine code involves several steps:

1. First, the source code (which is in textual form) is read character by character. The scanner groups individual characters into valid language constructs (such as variables, reserved words, and so on), called tokens.

2. The tokens are passed to the parser, which checks that the correct language syntax is being used in the program. In this step, the program is converted to its parse tree representation.

3. Semantic analysis performs type checking. Type checking validates that all variables, functions, and so on, in the source program have been used consistently with their definitions. The result of this phase is intermediate representation (IR)  code.

4. Next, the optimizer (optionally) tries to make equivalent but improved IR code.

5. In the final step, the code generator creates target machine code from the optimized IR code. The generated machine code is written as an object file.

Compiler architecture

To create one executable file, a linking phase is necessary. The linker takes several object files and libraries, resolves all external references and creates one executable object file. When such a compiled program is executed, it has complete control of its execution.

Unlike compilers, interpreters handle programs as data that can be manipulated in any suitable way (see Figure 1.2).

Interpreter architecture

As you can see in Figure 1.2, the interpreter, not the user program, controls program execution. Thus, we can say the user program is passive in this case. So, to run an interpreted program on a host, both the source code and a suitable interpreter must be available. The presence of the program source (script) is the reason why some developers associate interpreted languages with scripting languages. In the same manner, compiled languages are usually associated with system-programming languages.

Interpreters usually support two modes of operation. In the first mode, the script file (with the source code) is passed to the interpreter. This is the most common way of distributing scripted programs. In the second, the interpreter is run in interactive mode. This mode enables the developer to enter program statements line by line, seeing the result of the execution after every statement. Source code is not saved to the file. This mode is important for initial system debugging, as we see later in the book.

In the following sections, I provide more details on the strengths and weaknesses of using compilers and interpreters. For now, here are some clear drawbacks of both approaches important for our further discussion:

• It is obvious compiled programs usually run faster than interpreted ones. This is because with compiled programs, no high-level code analysis is being done during runtime.

• An interpreter enables the modification of a user program as it runs, which enables interactive debugging capability. In general, interpreted programs are easier to debug because most interpreters point directly to errors in the source code.

• Interpreters introduce a certain level of machine independence because no specific machine code is generated.

• The important thing from a scripting point of view, as we see in a moment, is interpreters allow the variable type to change dynamically. Because the user program is reexamined constantly during execution, variables do not need to have fixed types. This is harder to accomplish with compilers because semantic analysis is done at compile time.

From this list, we can conclude interpreters are better suited for the development process, and compiled programs are better suited for production use. Because of this, for some languages, you can find both an interpreter and a compiler. This means you can reap all the benefits of interpreters in the development phase and then compile a final version of the program for a specific platform to gain better performance.

Many of today’s interpreted languages are not interpreted purely. Rather, they use a hybrid compiler-interpreter approach, as shown in Figure 1.3.

Hybrid compiler-interpreter architecture

In this model, the source code is first compiled to some intermediate code (such as Java bytecode), which is then interpreted. This intermediate code is usually designed to be very compact (it has been compressed and optimized). Also, this language is not tied to any specific machine. It is designed for some kind of virtual machine, which could be implemented in software. Basically, the virtual machine represents some kind of processor, whereas this intermediate code (bytecode) could be seen as a machine language for this processor.

This hybrid approach is a compromise between pure interpreted and compiled languages, due to the following characteristics:

• Because the bytecode is optimized and compact, interpreting overhead is minimized compared with purely interpreted languages.

• The platform independence of interpreted languages is inherited from purely interpreted languages because the intermediate code could be executed on any host with a suitable virtual machine.

Lately, just-in-time compiler technology has been introduced, which allows developers to compile bytecode to machine-specific code to gain performance similar to compiled languages. I mention this technology throughout the book, where applicable.

Source code in production

As some people have pointed out, you should use a scripting language to write user-readable and modifiable programs that perform simple operations and control the execution of other programs. In this scenario, source code should be available in the production system at runtime, so programs are delivered not in object code, but in plain text files (scripts) in their original source. From our previous discussion of interpreters, it is obvious this holds true for purely interpreted languages. Because scripting languages are interpreted, we can say this rule applies to them as well. But because some of them use a hybrid compilation-interpretation strategy, it is possible to deliver the program in intermediate bytecode form. The presence of the bytecode improves execution speed because no compilation process is required. The usual approach is to deliver necessary libraries in the bytecode and not the program itself. This way, execution speed is improved, and the program source is still readable in production. Some of the compiler-interpreter languages cache in the file the bytecode for the script on its first execution. On every following script execution, if the source hasn’t been changed, the interpreter uses the cached bytecode, improving the startup speed required to execute the script.

As such, the presence of source code in the production environment is one of the characteristics of scripting languages, although you can omit it for performance reasons or if you want to keep your source code secret.

Typing strategies

Before I start a discussion on typing strategies implemented in different programming languages, I have to explain what types are.

There is no simple way to explain what typing is because its definition depends on the context in which it is used. Also, a whole branch of mathematics is dedicated to this issue. It is called type theory, and its proponents have the following saying, which emphasizes their attitude toward the importance of this topic:

Design the type system correctly, and the language will design itself.

To put it simply, types are metadata that describe the data stored in some variable. Types specify what values can be stored in certain variables, as well as the operations that can be performed on them.

Type constraints determine how we can handle and operate a certain variable. For example, what happens when you add the values of one variable to those of another depends on whether the variables are integers, floats, Booleans or strings. A programming language’s type system could classify the value hello as a string and the value 7 as a number. Whether you can mix strings with numbers in this language depends on the language’s type policy.

Some types are native (or primitive), meaning they are built into the language. The usual representatives of this type category are Booleans, integers, floats, characters and even strings in some languages. These types have no visible internal structure.

Other types are composite, and are constructed of primitive types. In this category, we have structures and various so-called container types, such as lists, maps and sets. In some languages, string is defined as a list of characters, so it can be categorized as a composite type.

In object-oriented languages, developers got the opportunity to create their own types, also known as classes. This type category is called user-defined types. The big difference between structures and classes is with classes, you define not just the structure of your complex data, but also the behavior and possible operations you can perform with it. This categorizes every class as a single type, where structures (in C, for example) are one type.

Type systems provide the following major benefits:

• Safety — Type systems are designed to catch the majority of type-misuse mistakes made by developers. In other words, types make it practically impossible to code some operations that cannot be valid in a certain context.

• Optimization — As I already mentioned, languages that employ static typing result in programs with better-optimized machine code. That is because early type checks provide useful information to the compiler, making it easier to allocate optimized space in memory for a certain variable. For example, there is a great difference in memory usage when you are dealing with a Boolean variable vs. a variable containing some random text.

• Abstraction — Types allow developers to make better abstractions in their code, enabling them to think about programs at a higher level of abstraction, not bothering with low-level implementation of those types. The most obvious example of this is in the way developers deal with strings. It is more useful to think of a string as a text value rather than as a byte array.

• Modularity — Types allow developers to create APIs for the subsystems used to build applications. Typing localizes the definitions required for interoperability of subsystems and prevents inconsistencies when those subsystems communicate.

• Documentation — Use of types in languages can improve the overall documentation of the code. For example, a declaration that some method’s arguments are of a specific type documents how that method can be used. The same is true for return values of methods and variables.

Now that we know the basic concepts of types and typing systems, we can discuss the type strategies implemented in various languages. We also discuss how the choice of implemented typing system defines languages as either scripting (dynamic) or static.

Dynamic typing

The type-checking process verifies that the constraints introduced by types are being respected. System-programming languages traditionally used to do type checking at compile time. This is referred to as static typing.

Scripting languages force another approach to typing. With this approach, type checking is done at runtime. One obvious consequence of runtime checking is all errors caused by inappropriate use of a type are triggered at runtime. Consider the following example:

x = 7
y = "hello world"
z = x + y

This code snippet defines an integer variable, x, and a string variable, y, and then tries to assign a value for the z variable that is the sum of the x and y values. If the language has not defined an operator, +, for these two types, different things happen depending on whether the language is statically or dynamically typed. If the language was statically typed, this problem would be discovered at compile time, so the developer would be notified of it and forced to fix it before even being able to run the program. If the language was dynamically typed, the program would be executable, but when it tried to execute this problematic line, a runtime error would be triggered.

Dynamic typing usually allows a variable to change type during program execution. For example, the following code would generate a compile-time error in most statically typed programming languages:

x = 7
x = "Hello world"

On the other hand, this code would be legal in a purely dynamic typing language. This is simply because the type is not being misused here.

Dynamic typing is usually implemented by tagging the variables. For example, in our previous code snippet, the value of variable x after the first line would be internally represented as a pair (7, number). After the second line, the value would be internally represented as a pair (“Hello world”, string). When the operation is executed on the variable, the type is checked and a runtime error is triggered if the misuse is discovered. Because no misuse is detected in the previous example, the code snippet runs without raising any errors.

I comprehensively discuss the pros and cons of these approaches later in this chapter, but for now, it is important to note a key benefit of dynamic typing from the developer’s point of view. Programs written in dynamically typed languages tend to be shorter than equivalent solutions written in statically typed languages. This is an implication of the fact that developers have more freedom in terms of expressing their ideas when they are not constrained by a strict type system.

Weak typing

There is yet another categorization of programming-language typing strategy. Some languages raise an error when a programmer tries to execute an operation on variables whose types are not suitable for that operation (type misuse). These languages are called strongly typed languages. On the other hand, weakly typed languages implicitly cast (convert) a variable to a suitable type before the operation takes place.

To clarify this, let’s take a look at our first example of summing a number and string variable. In a strongly typed environment, which most system-programming languages deploy, this operation results in a compile-time error if no operator is defined for these types. In a weakly typed language, the integer value usually would be converted to its string representative (7 in this case) and concatenated to the other string value (supposing that the + operator represents string concatenation in this case). The result would be a z variable with the “7HelloWorld” value and the string type.

Most scripting languages tend to be dynamic and weakly typed, but not all of them use these policies. For example, Python, a popular scripting language, employs dynamic typing, but it is strongly typed. We discuss in more detail the strengths and weaknesses of these typing approaches, and how they can fit into the overall system architecture, later in this chapter and in Chapter 2.

Data structures

For successful completion of common programming tasks, developers usually need to use different complex data structures. The presence of language mechanisms for easy handling of complex data structures is in direct connection to developers’ efficiency.

Scripting languages generally provide more powerful and flexible built-in data types than traditional system-programming languages. It is natural to see data structures such as lists, sets, maps, and so on, as native data types in such languages.

Of course, it is possible to implement an arbitrary data structure in any language, but the point is these data structures are embedded natively in language syntax making them easier to learn and use. Also, without this standard implementation, novice developers are often tempted to create their own solution that is usually not robust enough for production use.

As an example, let’s look at Python, a popular dynamic language with lists and maps (also called dictionaries) as its native language type. You can use these structures with other language constructs, such as a for loop, for instance. Look at the following example of defining and iterating a simple list:

list = ["Mike", "Joe", "Bruce"]
for item in list :
    print item

As you can see, the Python code used in this example to define a list is short and natural. But more important is the for loop, which is designed to naturally traverse this kind of data. Both of these features make for a comfortable programming environment and thus save some time for developers.

Java developers may argue that Java collections provide the same capability, but prior to J2SE 1.5, the equivalent Java code would look like this:

String[] arr = new String[]{"Mike", "Joe", "Bruce"};
List list = Arrays.asList(arr);
for (Iterator it = list.iterator(); it.hasNext(); ) {
      System.out.println(it.next());
}

Even for this simple example, the Java code is almost twice as long as and is harder to read than the equivalent Python code. In J2SE 1.5, Java got some features that brought it closer to these scripting concepts. With the more flexible for loop, you could rewrite the preceding example as follows:

String[] arr = new String[]{"Mike", "Joe", "Bruce"};
List list = Arrays.asList(arr);        
for (String item : list) {
      System.out.println(item);
}

With this in mind, we can conclude data structures are an important part of programming, and therefore native language support for commonly used structures could improve developers’ productivity. Many scripting languages come with flexible, built-in data structures, which is one of the reasons why they are often categorized as “human-oriented.”

Code as data

The code and data in compiled system programming languages are two distinct concepts. Scripting languages, however, attempt to make them more similar. As I said earlier, programs (code) in scripting languages are kept in plain text form. Language interpreters naturally treat them as ordinary strings.

Evaluation

It is not unusual for the commands (built-in functions) in scripting languages to evaluate a string (data) as language expression (code). For example, in Python, you can use the eval() function for this purpose:

x = 9
eval("print x + 7")

This code prints 16 on execution, meaning the value of the variable x is embedded into the string, which is evaluated as a regular Python program.

More important is the fact that scripted programs can generate new programs and execute them “on the fly”. Look at the following Python example:

temp = open("temp.py", "w")
temp.write("print x + 7")
temp.close()
x = 9
execfile("temp.py")

In this example, we created a file called temp.py, and we wrote a Python expression in it. At the end of the snippet, the execfile() command executed the file, at which point 16 was displayed on the console.

This concept is natural to interpreted languages because the interpreter is already running on the given host executing the current script. Evaluation of the script generated at runtime is not different from evaluation of other regular programs. On the other hand, for compiled languages this could be a challenging task. That is because a compile/link phase is introduced during conversion of the source code to the executable program. With interpreted languages, the interpreter must be present in the production environment, and with compiled languages, the compiler (and linker) is usually not part of the production environment.

Closures

Scripting languages also introduce a mechanism for passing blocks of code as method arguments. This mechanism is called a closure. A good way to demonstrate closures is to use methods to select items in a list that meet certain criteria.

Imagine a list of integer values. We want to select only those values greater than some threshold value. In Ruby, a scripting language that supports closures, we can write something like this:

threshold = 10
newList = orig.select {|item| item > threshold}

The select() method of the collection object accepts a closure, defined between the {}, as an argument. If parameters must be passed, they can be defined between the ||. In this example, the select() method iterates over the collection, passing each item to the closure (as an item parameter) and returning a collection of items for which the closure returned true.

Another thing worth noting in this example is closures can refer to variables visible in the scope in which the closure is created. That’s why we could use the global threshold value in the closure.

Closures in scripting languages are not different from any other data type, meaning methods can accept them as parameters and return them as results.

Functions as method arguments

Many scripting languages, even object-oriented ones, introduce standalone functions as so-called “first-class language citizens.” Even if you do not have true support for closures, you can pass your functions as method arguments.

The Python language, for example, defines a filter() function that accepts a list and the function to be executed on every item in the list:

def over(item) :
    threshold = 10
    return item > threshold
    
newList = filter(over, orig)

In this example, we defined the over() function, which basically does the same job as our closure from the previous example. Next, we called the filter() function and passed the over() function as the second argument. Even though this mechanism is not as convenient as closures are, it serves its purpose well (and that is to pass blocks of code as data around the application).

Of course, you can achieve similar functionality in other nonscripting languages. For example, Java developers have the concept of anonymous inner classes serving the same purpose. Let’s implement a similar solution using this approach:

package net.scriptinginjava.ch1;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.Iterator;
import java.util.List;

interface IFilter {
 public boolean filter(Integer item);
}

public class Filter {

    private static List select(List list, IFilter filter) {
        List result = new ArrayList();
        for (Iterator it = list.iterator(); it.hasNext();) {
            Integer item = (Integer)it.next();
 if (filter.filter(item)) {
 result.add(item);

 }
        }
        return result;
    }

    public static void main(String[] args) {
        Integer[] arr = new Integer[]{
                    new Integer(5), 
                    new Integer(7), 
                    new Integer(13), 
                    new Integer(32)
                };
        List orig = Arrays.asList(arr);
        List newList = select(orig, 
 new IFilter() {
 private Integer threshold 
 = new Integer(10); 
 public boolean filter(Integer item) {

 return item.compareTo(threshold) > 0;
 }
 }        
 );
        System.out.println(newList);
    }
  
}

First we defined the IFilter interface with a filter() method that returns a Boolean value indicating whether the condition is satisfied.

---

Note – Some closure proponents say that the existence of this “named” interface breaks the anonymous concept at the beginning.

---

Our Filter class contains a select() method equal to the methods we saw in the earlier Ruby and Python examples. It accepts a list to be handled and the implementation of the IFilter interface that filters the values we want in our new list. At the end, we implement the IFilter interface as the anonymous inner class in the select() method call.

As a result, the program prints this result list to the screen:

[13, 32]

From this example, we can see even though a similar concept is possible in system-programming languages, the syntax is more complex. This is an important difference because the natural syntax for some functionality leads to its frequent use, in practice. Closures have simple syntax for passing the code around the application. That is why you see closures used more often in languages that naturally support them than you see similar structures in other languages (anonymous inner classes in Java, for example).

Hopefully, closures will be added in Java SE 7, which will move Java one step closer to the flexibility of scripting languages.

Summary

In this section of the chapter, I discussed some basic functional characteristics of scripting languages. Many experts tend to categorize a language as scripting or system programming, not by these functional characteristics but by the programming style and the role the language plays in the system. However, these two categorizations are not independent, so to understand how scripting can fit into your development process, it is important to know the functional characteristics of the scripting language and the implications of its design. The differences between system-programming and scripting languages are described later in this chapter, helping us to understand how these two approaches can work together to create systems that feature the strengths of both programming styles.

It is important to note that the characteristics we’ve discussed thus far are not independent among each other. For example, whether to use static or dynamic typing depends on when the type checking is done. It is hard to implement dynamic typing in a strictly compiled environment. Thus, interpreter and dynamic typing somehow fit naturally together and are usually employed in scripting environments. The same is true for the compiler and static typing found in system-programming environments.

The same is true for the generation and execution of other programs, which is a natural thing to do in interpreted environments and is not very easy (and thus is rarely done) in compiled environments.

To summarize, these characteristics are usually found in scripting programming environments. Not all languages support all the features described earlier, which is a decision driven by the primary domain for which the language is used. For example, although Python is a dynamic language, it introduces strong typing, making it more resistible to type misuse and more convenient for development of larger applications.

These characteristics should serve only as a marker when exploring certain languages and their possible use in your development process. More important is the language’s programming style, a topic we discuss shortly.

This content is an excerpt from the new book titled Scripting in Java, authored by Dejan Bosanac, Copyright 2007 Pearson Education, Inc., published by Addison-Wesley Professional, August 2007, ISBN 0321321936. For additional information, please visit: www.awprofessional.com.

Copyright (c) 2007 Pearson Education. All rights reserved.