Thread in Java

Java & Threads

Threads are essentially subprocesses¹. Informally, you can think of them as tasks that belong to a program and that can run "simultaneously". Depending on the number of CPUs available and the number of competing threads, some of those threads actually will run in parallel on different CPUs, whilst in other cases the illusion of simultaneous execution will be achieved by "juggling" threads in and out of the available CPUs. A part of the OS called the thread scheduler takes care of deciding which threads to allocate CPU time to (on which CPUs) and when.

Who needs to know about thread programming?

In the past, people who needed to know about thread programming were generally people writing applications that dealt with multiple "requests" or "jobs" concurrently, such as a web server or maybe a web browser making simultaneous requests to download a web page and associated images. But many other "client" or "desktop" applications didn't involve threads: there was generally only one CPU on a desktop machine, so everything was just done in one thread. Even games, which often needed to create the illusion of, say, different characters simultaneously moving about, would still use one thread and just "loop through" the various characters to move on every frame. (Look at pretty much any tutorial on game programming written until fairly recently, and the first chapter will inevitably be about "the game loop"...)

But increasingly, practically every programmer needs to know about threading and parallel programming. A fundamental characteristic of "game loop" approach is that it will only occupy one processor. The only way to improve performance with this approach (aside from using better algorithms) is to increase processor speed. This hasn't mattered until recently, because single processor speeds were continually increasing. But increased performance nowadays is being achieved via increased numbers of CPUs rather than increased speed of a single CPU. This means that to get our game or calculator program to perform better, we need to put the multiple CPUs to work in parallel. And by and large, that means multiple threads.

Getting started: what are threads, and how to use them in Java

It's easier to illustrate what a thread is by diving straight in and seeing some code. We're going to write a program that "splits itself" into two simultaneous tasks. One task is to print Hello, world! every second. The other task is to print Goodbye, cruel world! every two seconds. OK, it's a silly example.

For them to run simultaneously, each of these two tasks will run in a separate thread. To define a "task", we create an instance of Runnable. Then we will wrap each of these Runnables around a Thread object.

Runnable

A Runnable object defines an actual task that is to be executed. It doesn't define how it is to be executed (serial, two at a time, three at a time etc), but just what. We can define a Runnable as follows:

Runnable r = new Runnable() {

  public void run() {

    ... code to be executed ...

  }

};

Runnable is actually an interface, with the single run() method that we must provide. In our case, we want the Runnable.run() methods of our two tasks to print a message periodically. So here is what the code could look like:

Runnable r1 = new Runnable() {

  public void run() {

    try {

      while (true) {

        System.out.println("Hello, world!");

        Thread.sleep(1000L);

      }

    } catch (InterruptedException iex) {}

  }

};

Runnable r2 = new Runnable() {

  public void run() {

    try {

      while (true) {

        System.out.println("Goodbye, " +

               "cruel world!");

        Thread.sleep(2000L);

      }

    } catch (InterruptedException iex) {}

  }

};

For now, we'll gloss over a couple of issues, such as how the task ever stops. As you've probably gathered, the Thread.sleep() method essentially "pauses" for the given number of milliseconds, but could get "interrupted", hence the need to catch InterruptedException. We'll come back to this in more detail in the section on Thread interruption and InterruptedException. The most important point for now is that with the Runnable() interface, we're just definingwhat the two tasks are. We haven't actually set them running yet. And that's where the Thread class comes in...

Thread

A Java Thread object wraps around an actual thread of execution. It effectively defines how the task is to be executed— namely, at the same time as other threads². To run the above two tasks simultaneously, we create a Thread object for each Runnable, then call the start() method on each Thread:

Thread thr1 = new Thread(r1);

Thread thr2 = new Thread(r2);

thr1.start();

thr2.start();

When we call start(), a new thread is spawned, which will begin executing the task that was assigned to the Thread object at some time in the near future. Meanwhile, control returns to the caller of start(), and we can start the second thread. Once that starts, we'll actually have at least three threads now running in parallel: the two we've just started, plus the "main" thread from which we created and started the two others. (In reality, the JVM will tend to have a few extra threads running for "housekeeping" tasks such as garbage collection, although they're essentially outside of our program's control.)

 

Difference between “implements Runnable” and “extends Thread” in java

Difference between “implements Runnable” and “extends Thread” in java

In java language, as we all know that there are two ways to create threads. One using Runnable interface and another by extending Thread class.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public class DemoRunnable implements Runnable {     public void run() {         //Code     } } //with a "new Thread(demoRunnable).start()" call public class DemoThread extends Thread {     public DemoThread() {         super("DemoThread");     }     public void run() {         //Code     } } //with a "demoThread.start()" call

There has been a good amount of debate on which is better way. Well, I also tried to find out and below is my learning:

1) Implementing Runnable is the preferred way to do it. Here, you’re not really specializing or modifying the thread’s behavior. You’re just giving the thread something to run. That means composition is the better way to go.

2) Java only supports single inheritance, so you can only extend one class.

3) Instantiating an interface gives a cleaner separation between your code and the implementation of threads.

4)  Implementing Runnable makes your class more flexible. If you extend thread then the action you’re doing is always going to be in a thread. However, if you extend Runnable it doesn’t have to be. You can run it in a thread, or pass it to some kind of executor service, or just pass it around as a task within a single threaded application.

5) By extending Thread, each of your threads has a unique object associated with it, whereas implementing Runnable, many threads can share the same runnable instance.

The issue is that at construction time, a Thread is added to a list of references in an internal thread table. It won’t get removed from that list until its start() method has completed. As long as that reference is there, it won’t get garbage collected.

 

 

 

 

Constructing Threads and Runnables

In our Java threading introduction, we created a thread in two steps:

• firstly, we constructed a Runnable object to define the code to be executed by the thread;
• then, we constructed a Thread object around the Runnable.

There are actually a couple of variations on this pattern of thread construction that we'll look at here.

Pattern 1: create an explicit class that implements Runnable

The Runnable implementations that we created were inline classes. That is, we didn't spell out a full class declaration. But strictly speaking, the way to create a Runnable— or rather, a class that implements the Runnable interface— is as follows:

public class MyTask implements Runnable {

  public void run() {

    ...

  }

}

...

Runnable r = new MyTask();

Thread thr = new Thread(r);

If we just write new Runnable(), the compiler under the hood actually creates a "dummy class" of the above form for us. But sometimes it's useful to create our own class. In our simultaneous message printing example, both Runnables essentially had similar code: only the message and time interval differed. So it would be neater to define a class that took the message and interval as parameters to the constructor:

public class MessagePrinter implements Runnable {

  private final String message;

  private final long interval;

  public MessagePrinter(String msg, long interval) {

    this.message = msg;

    this.interval = interval;

  }

  public void run() {

    try {

      while (true) {

        System.out.println(message);

        Thread.sleep(interval);

      }

    } catch (InterruptedException iex) {}

  }

}

Notice that for reasons we'll come to, we declare the variables final. This is basically a means of making sure they are "seen properly" by the two threads involved (the thread that constructs the object, then the thread in which run() will actually be running when we start the thread).

Pattern 2: override Thread.run()

You can actually dispense with the separate Runnable method. The Thread class has a (normally empty) run() method. If you don't pass in a Runnable to the constructor, then the run() method of Thread will be called instead when the thread starts. So we could write something like this:

public void MyThread extends Thread {

  public void run() {

    ...

  }

}

...

Thread thr = new MyThread();

thr.start();

Of course, we can also turn this into an inline class:

Thread thr = new Thread() {

  public void run() {

    ...

  }

}

thr.start();

Which thread construction pattern?

So, which method should you use to construct a thread in Java? In general, constructing a separate Runnable gives you more flexibility. Running in aThread turns out not to be the only way of running a Runnable, so if you embed everything inside a Thread object from the beginning, you may end up with more code to change later on if you decide to do things differently. In the simplest case, having a separate Runnable allows you to write code such as the following:

public void runTask(Runnable r, boolean separateThread) {

  if (separateThread) {

    (new Thread(r)).start();

  } else {

    r.run();

  }

}

Other instances where a Runnable is used are with the Swing.invokeLater() method (called from a non-Swing thread to ask Swing to run a particular task in its UI thread), or with various executor utilities introduced in the Java 5 concurrency package.
On the other hand, for threads representing fairly "major" tasks running right through your application, where it's clear from the ground up that you don't need the flexibility of the separate Runnable object, just overriding Thread.run() may make your code a little less cluttered.

Thread methods in Java

On the previous page, we looked at how to construct a thread in Java, via the Runnable and Thread objects. We mentioned that the Thread class providescontrol over threads. So on this page, we take a high-level look at the most important methods on this class.

Thread.sleep()

We actually saw a sneak preview of Thread.sleep() in our Java threading introduction. This static method asks the system to put the current thread to sleep for (approximately) the specified amount of time, effectively allowing us to implement a "pause". A thread can be interrupted from its sleep.

For more details, see: Thread.sleep() (separate page).

interrupt()

As mentioned, you can call a Thread object's interrupt() method to interrupt the corresponding thread if it is sleeping or waiting. The corresponding thread will "wake up" with an IOException at some point in the future. See thread interruption for more details.

setPriority() / getPriority()

Sets and queries some platform-specific priority assignment of the given thread. When calculating a priority value, it's good practice to always do so in relation to the constants Thread.MIN_PRIORITY, Thread.NORM_PRIORITY and Thread.MAX_PRIORITY. In practice, values go from 1 to 10, and map on to some machine-specific range of values: nice values in the case of Linux, and local thread priorities in the case of Windows. These are generally the range of values of "normal" user threads, and the OS will actually still run other threads beyond these values (so, for example, you can't preempt the mouse pointer thread by setting a thread to MAX_PRIORITY!).

Three main issues with thread priorities are that:

• they don't always do what you might intuitively think they do;
• their behaviour depends on the platform and Java version: e.g. in Linux, priorities don't work at all in Hotspot before Java 6, and the mapping of Java to OS priorities changed under Windows between Java 5 and Java 6;
• in trying to use them for some purpose, you may actually interfere with more sensible scheduling decisions that the OS would have made anyway to achieve your purpose.

For more information, see the section on thread scheduling and the discussion on thread priorities, where the behaviour on different platforms is compared.

join()

The join() method is called on the Thread object representing enother thread. It tells the current thread to wait for the other thread to complete. To wait for multiple threads at a time, you can use a CountDownLatch.

Thread.yield()

This method effectively tells the system that the current thread is "willing to relinquish the CPU". What it actually does is quite system-dependent. For more details, see: Thread.yield() (separate page).

setName() / getName()

Threads have a name attached to them. By default, Java will attach a fairly dull name such as Thread-12. But for debugging purposes you might want to attach a more meaningful name such as Animation Thread, WorkerThread-10 etc. (Some of the variants of the Thread constructor actually allow you to pass in a name from the start, but you can always change it later.)

Thread interruption in Java

In our overview of thread methods, we saw various methods that throw InterruptedException.

Interruption is a mechanism whereby a thread that is waiting (or sleeping) can be made to prematurely stop waiting.

Incidentally, it is important not to confuse thread interruption with either software interrupts (where the CPU automatically interrupts the current instruction flow in order to call a registered piece of code periodically— as in fact happens to drive the thread scheduler) and hardware interrupts (where the CPU automatically performs a similar task in response to some hardware signal).

To illustrate interruption, let's consider again a thread that prints a message periodically. After printing the message, it sleeps for a couple of seconds, then repeats the loop:

Runnable r = new Runnable() {

  public void run() {

    try {

      while (true) {

        Thread.sleep(2000L);

        System.out.println("Hello, world!");

      }

    } catch (InterruptionException iex) {

      System.err.println("Message printer interrupted");

    }

  }

};

Thread thr = new Thread(r);

thr.start();

The InterruptedException is thrown by the Thread.sleep() method, and in fact by a few other core library methods that can "block", principally:

• Object.wait(), part of the wait/notify mechanism;
• Thread.join(), that makes the current thread wait for another thread to complete;
• Proess.waitFor(), which lets us wait for an external process (started from our Java application) to terminate;
• various methods in the Java 5 concurrency libraries, such as the tryLock() method of the Java 5 ReentrantLock class.

In general, InterruptedException is thrown when another thread interrupts the thread calling the blocking method. The other thread interrupts the blocking/sleeping thread by calling interrupt() on it:

thr.interrupt();

Provided that the thread or task calling sleep() (or whatever) has been implemented properly, the interruption mechanism can therefore be used as a way to cancel tasks.

Stopping a thread

On the previous pages, we focussed on how to start a thread in Java. We saw that after creating the Thread object, calling start() asynchronously starts the corresponding thread. In our example, the run() method contained an infinite loop. But in real life, we generally want our thread to stop. So how do we make our thread stop?
Firstly, the thing you shouldn't do is call Thread.stop(). This method, now deprecated, was intended to stop a given thread abruptly. But the problem with this is that the caller can't generally determine whether or not the given thread is at a safe point to be stopped. (This isn't just a Java phenomenon: in general, the underlying operating system calls that Thread.stop() makes to abruptly stop the thread are also deprecated for this reason.)
So how can we stop a thread safely? In general:

To make the thread stop, we organise for the run() method to exit.

There are a couple of ways that we would typically do so.

Use a "stop request" variable

A common solution is to use an explicit "stop request" variable, which we check on each pass through the loop. This technique is suitable provided that we can check the variable frequently enough:

private volatile boolean stopRequested = false;

public void run() {

  while (!stopRequested) {

    ...

  }

}

public void requestStop() {

  stopRequested = true;

}

Note that we must declare the stopRequested variable as volatile, because it is accessed by different threads.

Use Thread.interrupt()

The above pattern is generally suitable if the variable stopRequested can be polled frequently. However, there is an obvious problem if the method blocksfor a long time, e.g. by calling Thread.sleep() or waiting on an object. In general, such blocking methods are interruptible. For more information, see the section on thread interruption.

How threads work: more details

In our introduction to Java threads, we showed the basics of how to start a thread, and the idea that threads let us run multiple tasks or "mini-programs" in parallel. But to understand certain thread programming issues in more detail, it's helpful to take a more detailed look at what threads actually are and how they work.

Figure 1: Typical relationsip between
threads and processes.

Threads and processes

A thread is essentially a subdivision of a process, or "lightweight process" (LWP) on some systems. A process is generally the most major and separate unit of execution recognised by the OS. The typical relationship between processes, threads and various other elements of the OS are shown in Figure 1 opposite. This shows two processes, each split into two threads (a simplistic situation, of course: there will be typically dozens of processes, some with dozens or more threads).

Crucially, each process has its own memory space. When Process 1 accesses some given memory location, say 0x8000, that address will be mapped to some physical memory address¹. But from Process 2, location 0x8000 will generally refer to a completely different portion of physical memory. Athread is a subdivision that shares the memory space of its parent process. So when either Thread 1 or Thread 2 of Process 1 accesses "memory address 0x8000", they will be referring to the same physical address. Threads belonging to a process usually share a few other key resources as well, such as their working directory, environment variables, file handles etc.

On the other hand, each thread has its own private stack and registers, including program counter. These are essentially the things that threads need in order to be independent. Depending on the OS, threads may have some other private resources too, such as thread-local storage(effectively, a way of referring to "variable number X", where each thread has its own private value of X). The OS will generally attach a bit of "housekeeping" information to each thread, such as its priority and state (running, waiting for I/O etc).

The thread scheduler

There are generally more threads than CPUs. Part of a multithreaded system is therefore a thread scheduler, responsible for sharing out the available CPUs in some way among the competing threads. Note that in practically all modern operating systems, the thread scheduler is part of the OS itself. So the OS actually "sees" our different threads and is responsible for the task of switching between them². The rationale for handling threading "natively" in the OS is that the OS is likely to have the information to make threading efficient (such as knowing which threads are waiting for I/O and for how long), whereas a software library may not have this information available. In the rest of our discussion, we'll generally assume this native threads model.

Next: scheduling and its implications for Java

On the next pages, we look at

• thread scheduling in more detail, including a broad overview of typical scheduling algorithms used by different platforms (with links to more detailed information);
• thread scheduling implcations for Java: how this description transcends into the world of Java and application threads;

---

1. Things are usually a little more complex, in fact. For example, a memory address can actually be mapped to something that isn't memory (such as a portion of a file, or device I/O). For this reason, the term address space is often preferred.
2. An alternative scenario, less common nowadays, is that the OS schedules at some higher level, e.g. scheduling processes, or scheduling some kind of "kernal thread" which is a unit bigger than our applications threads. In this model, sometimes called "green threads", threads are to some extent "artificially" handled by the JVM (or the threading library that it is compiled against). In general, if you are using Java 1.4 onwards on Windows or on Solaris 9 or Linux kernel 2.6 or later, then there will be a 1:1 mapping between Java Threads and "native" operating system threads.

Thread Scheduling

In our introduction to how threads work, we introduced the thread scheduler, part of the OS (usually) that is responsible for sharing the available CPUs out between the various threads. How exactly the scheduler works depends on the individual platform, but various modern operating systems (notably Windows and Linux) use largely similar techniques that we'll describe here. We'll also mention some key varitions between the platforms.

Note that we'll continue to talk about a single thread scheduler. On multiprocessor systems, there is generally some kind of scheduler per processor, which then need to be coordinated in some way. (On some systems, switching on different processors is staggered to avoid contention on shared scheduling tables.) Unless otherwise specified, we'll use the term thread scheduler to refer to this overall system of coordinated per-CPU schedulers.

Across platforms, thread scheduling¹ tends to be based on at least the following criteria:

• a priority, or in fact usually multiple "priority" settings that we'll discuss below;
• a quantum, or number of allocated timeslices of CPU, which essentially determines the amount of CPU time a thread is allotted before it is forced to yield the CPU to another thread of the same or lower priority (the system will keep track of the remaining quantum at any given time, plus its defaultquantum, which could depend on thread type and/or system configuration);
• a state, notably "runnable" vs "waiting";
• metrics about the behaviour of threads, such as recent CPU usage or the time since it last ran (i.e. had a share of CPU), or the fact that it has "just received an event it was waiting for".

Most systems use what we might dub priority-based round-robin scheduling to some extent. The general principles are:

• a thread of higher priority (which is a function of base and local priorities) will preempt a thread of lower priority;
• otherwise, threads of equal priority will essentially take turns at getting an allocated slice or quantum of CPU;
• there are a few extra "tweaks" to make things work.

States

Depending on the system, there are various states that a thread can be in. Probably the two most interesting are:

• runnable, which essentially means "ready to consume CPU"; being runnable is generally the minimum requirement for a thread to actually be scheduled on to a CPU;
• waiting, meaning that the thread currently cannot continue as it is waiting for a resource such as a lock or I/O, for memory to be paged in, for a signal from another thread, or simply for a period of time to elapse (sleep).

Other states include terminated, which means the thread's code has finished running but not all of the thread's resources have been cleared up, and a newstate, in which the thread has been created, but not all resources necessary for it to be runnable have been created. Internally, the OS may distinguish between various different types of wait states² (for example "waiting for a signal" vs "waiting for the stack to be paged in"), but this level of granularity is generally not available or so important to Java programs. (On the other hand, Java generally exposes to the programmer things the JVM can reasonly know about, for example, if a thread is waiting to acquire the lock on a Java object— roughly speaking, "entering a synchronized block".)

Read More

Input and Output in .NET

Input and Output in .NET
To make a crude generalization, the input/output functions in the .NET Framework can be divided into two broad categories, irrespective of the data storage (disk, memory, etc.) that is being written to or read from.

Data can be treated as a stream of bytes or characters. For example, we could read 500 bytes from a file and write them to a memory buffer. Data can also be treated as a set of objects. Reading and writing the objects is referred to as deserializing and serializing the objects. We can serialize (write) the list of Customer objects to disk. We can then deserialize (read) the list of Customer objects back into memory.

The System::IO namespace has several classes for reading and writing to various types of storage while treating the data as bytes or characters. Serialization functionality can be found in various places in the .NET framework. The System::Runtime::Serialization namespace handles serialization of the Common Type System. The System::Xml::Serialization namespace handles XML serialization.

Stream Classes
Stream is an abstract class that is the basis for reading from and writing bytes to some storage such as a file. It supports both synchronous and asynchronous reading and writing. Asynchronous methods are discussed later in this chapter. The Stream class has the typical methods that you would expect: Read, Write, Seek, Flush, and Close.

The FileStream class is derived from Stream to represent the reading and writing of files as a series of bytes. The FileStream constructor builds the actual stream instance. The overridden Stream methods implement the reading and writing to the file.

Other classes derived from Stream include MemoryStream, BufferedStream, and NetworkStream (in System::Net::Sockets).

The FileStream example (in the FileIO directory with the IO examples) illustrates how to use the Stream classes. If the file does not exist, a new file is created and the numbers from 0 to 9 are written to the file. If the file already exists, the code starts reading 5 bytes from the end of the file and then writes them out. (You should run the example twice. The first time creates and writes the file, and the second time reads and displays the file.)

      unsigned char data __gc[] =
         new unsigned char __gc [10];
      FileStream *fs = new FileStream(
         "FileStreamTest.txt", FileMode::OpenOrCreate);
      if (fs->Length == 0)
      {
         Console::WriteLine("Writing Data...");
         for (short i = 0; i < 10; i++)
            data[i] = (unsigned char)i;
         fs->Write(data, 0, 10);
      }
      else
      {
         fs->Seek(-5, SeekOrigin::End);
         int count = fs->Read(data, 0, 10);
         for (int i = 0; i < count; i++)
         {
            Console::WriteLine(data[i]);
         }
      }
      fs->Close();

Read More

Python and XML

Chapter 1
Python and XML

Python and XML are two very different animals, each with a rich history. Python is a full-scale programming language that has grown from scripting world roots in a very organic way, through the vision and guidance of Python's inventor, Guido van Rossum. Guido continues to take into account the needs of Python developers as Python matures. XML, on the other hand, though strongly impacted by the ideas of a small cadre of visionaries, has grown from standards-committee roots. It has seen both quiet adoption and wrenching battles over its future. Why bother putting the two technologies together?

Before the Python/XML combination, there seemed no easy or effective way to work with XML in a distributed environment. Developers were forced to rely on a variety of tools used in awkward combination with one other. We used shell scripting and Perl to process text and interact with the operating system, and then used Java XML API's for processing XML and network programming. The shell provided an excellent means of file manipulation and interaction with the Unix system, and Perl was a good choice for simple text manipulation, providing access to the Unix APIs. Unfortunately, neither sported a sophisticated object model. Java, on the other hand, featured an object-oriented environment, a robust platform API for network programming, threads, and graphical user interface (GUI) application development. But with Java, we found an immediate lack of text manipulation power; scripting languages typically provided strong text processing. Python presented a perfect solution, as it combines the strengths of all of these various options.

The Power of Python and XML

Now that we've introduced you to the world of XML, we'll look at what Python brings to the table. We'll review the Python features that apply to XML, and then we'll give some specific examples of Python with XML. As a very high-level language, Python includes many powerful data structures as part of the core language and libraries. The more recent versions of Python, from 2.0 onward, include excellent support for Unicode and an impressive range of encodings, as well as an excellent (and fast!) XML parser that provides character data from XML as Unicode strings. Python's standard library also contains implementations of the industry-standard DOM and SAX interfaces for working with XML data, and additional support for alternate parsers and interfaces is available.

Of course, this much could be said of other modern high-level languages as well. Java certainly includes an impressive library of highly usable data structures, and Perl offers equivalent data structures also. What makes Python preferable to those languages and their libraries? There are several features, of which we briefly discuss the most important:

• Python source code is easy to read and maintain.
• The interactive interpreter makes it simple to try out code fragments.
• Python is incredibly portable, but does not restrict access to platform-specific capabilities.
• The object-oriented features are powerful without being obscure.

The Power of Python and XML

Now that we've introduced you to the world of XML, we'll look at what Python brings to the table. We'll review the Python features that apply to XML, and then we'll give some specific examples of Python with XML. As a very high-level language, Python includes many powerful data structures as part of the core language and libraries. The more recent versions of Python, from 2.0 onward, include excellent support for Unicode and an impressive range of encodings, as well as an excellent (and fast!) XML parser that provides character data from XML as Unicode strings. Python's standard library also contains implementations of the industry-standard DOM and SAX interfaces for working with XML data, and additional support for alternate parsers and interfaces is available.

Of course, this much could be said of other modern high-level languages as well. Java certainly includes an impressive library of highly usable data structures, and Perl offers equivalent data structures also. What makes Python preferable to those languages and their libraries? There are several features, of which we briefly discuss the most important:

• Python source code is easy to read and maintain.
• The interactive interpreter makes it simple to try out code fragments.
• Python is incredibly portable, but does not restrict access to platform-specific capabilities.
• The object-oriented features are powerful without being obscure.

There are many languages capable of doing what can be done with Python, but it is rare to find all of the "peripheral" qualities of Python in any single language. These qualities do not so much make Python more capable, but they make it much easier to apply, reducing programming hours. This allows more time to be spent finding better ways to solve real problems or just allows the programmer to move on to the next problem. Here we discuss these features in more detail.

Easy to read and maintain

As a programming language, Python exhibits a remarkable clarity of expression. Though some programmers accustomed to other languages view Python's use of significant whitespace with surprise, everyone seems to think it makes Python source code significantly more readable than languages that require more special characters to be introduced to mark structure in the source. Python's structures are not simpler than those of other languages, but the different syntax makes source code "feel" much cleaner in Python.

The use of whitespace also helps avoid having minor stylistic differences, such as the placement of structural braces, so there's a greater degree of visual consistency across code by different programmers. While this may seem like a minor thing to many programmers, the effect is that maintaining code written by another programmer becomes much easier simply because its easier to concentrate on the actual structure and algorithms of the code. For the individual programmer, this is a nice side benefit, but for a business, this results in lower expenses for code maintenance.

Exploratory programming in an interactive interpreter

Many modern high-level programming languages offer interpreters, but few have proved as successful at doing so as Python. Others, such as Java, do not generally offer interpreters at all. If we consider Perl, a language that is arguably very capable when used from a command line, we see that it is not equipped with a rich interpreter. If we start the Perl interpreter without naming a script, it simply waits for us to type a complete script at the console, and then interprets the script when we're done. It does allow us to enter a few commands on the command line directly, but there's no ability to run one statement at a time and inspect the results as we go in order to determine if each bit of code is doing exactly what we expect. With Python, the interactive interpreter provides a rich environment for executing individual statements and testing the results.

Portability without restrictions

The Python interpreter is one of the most portable language interpreters available. It is known to run on platforms ranging from PDAs and other embedded systems to some of the most powerful multiprocessor platforms ever built. It can run on more operating systems than perhaps any other interpreter. Moreover, carefully written application code can share much of this portability. Python provides a great array of abstractions that do just enough to hide platform differences while allowing the programmer to use the services of specific platforms when necessary.

When an application requires access to facilities or libraries that Python does not provide, Python also makes it easy to add extensions that take advantage of these additional facilities. Additional modules can be created (usually in C or C++, but other languages can be used as well) that allow Python code to call on external facilities efficiently.

Powerful but accessible object-orientation

At one time, it was common to hear about how object-oriented programming (OOP) would solve most of the technical problems programmers had to deal with in their code. Of course, programmers knew better, pushed back, and turned the concepts into useful tools that could be applied when appropriate (though how and when it should be applied may always be the subject of debate). Unfortunately, many languages that have strong support for OOP are either very tedious to work with (such as C++ or, to a lesser extent, Java), or they have not been as widely accepted for general use (such as Eiffel).

Python is different. The language supports object orientation without much of the syntactic overhead found in many widely used object-oriented languages, making it very easy to define new object types. Unlike many other languages, Python is highly polymorphic; interfaces are defined in much less stringent ways than in languages such as C++ and Java. This makes it easy to create useful objects without having to write code that exists only to conform to an interface, but that will not actually be used in a particular application. When combined with the excellent advantage taken by Python's standard library of a variety of common interfaces, the value of creating reusable objects is easily recognized, all while the ease of implementing useful interfaces is maintained.

Python Tools for XML

Three major packages provide Python tools for working with XML. These are, from the most commonly used to the largest:

1.     The Python standard library

2.     PyXML, produced by the Python XML Special Interest Group

3.     4Suite, provided by Fourthought, Inc.

The Python standard library provides a minimal but useful set of interfaces to work with XML, including an interface to the popular Expat XML parser, an implementation of the lightweight Simple API for XML (SAX), and a basic implementation of the core Document Object Model (DOM). The DOM implementation supports Level 1 and much of Level 2 of the DOM specification from the W3C, but does not implement most of the optional features. The material in the standard library was drawn from material originally in the PyXML package, and additional material was contributed by leading Python XML developers.

PyXML is a more feature-laden package; it extends the standard library with additional XML parsers, has a much more substantial DOM implementation (including more optional features), has adapters to allow more parsers to support the SAX interface, XPath expression parsing and evaluation, XSLT transformations, and a variety of other helper modules. The package is maintained as a community effort by many of the most active Python/XML programmers.

4Suite is not a superset of the other packages, but is intended to be used in addition to PyXML. It offers additional DOM implementations tailored for different applications, support for the XLink and XPointer specifications, and tools for working with Resource Description Framework (RDF) data.

What Can We Do with It?

Now that we've looked at how we can use XML with Python, we need to look at how we can apply our knowledge of XML and Python to real applications. In the Internet age, this means widely distributed systems operating across the Internet.

There's a lot to working with the Internet beyond XML and the CGI programming done in many of the examples in the book. In case you're not already familiar with this topic, we include an introduction to the facilities in the Python standard library that help create clients and servers for the Internet in Chapter 8. We review how to retrieve data from remote servers, and how to submit form-based requests programmatically and read the result. We then learn to build custom web servers that respond to HTTP requests, allowing us to build servers that do exactly what we need them to.

With these skills under our hat, we proceed to look at the emerging world of "web services." Chapter 9 describes what we mean by web services and introduces the specifications coming out in that area. We look at two packages that allow us to use SOAP to call on web services and demonstrate how to create one in Python.

In Chapter 10, we pull together much of what we've learned with an extended example that demonstrates how it all works together. Using XML as a communications medium, we are able to build an application that uses a variety of technologies and operates in diverse environments.

Read More

XML Extensible Markup Language

XML (Extensible Markup Language) is a flexible way to create common information formats and share both the format and the data on the World Wide Web, intranets, and elsewhere. For example, computer makers might agree on a standard or common way to describe the information about a computer product (processor speed, memory size, and so forth) and then describe the product information format with XML. Such a standard way of describing data would enable a user to send an intelligent agent (a program) to each computer maker's Web site, gather data, and then make a valid comparison. XML can be used by any individual or group of individuals or companies that wants to share information in a consistent way.

XML, a formal recommendation from the World Wide Web Consortium (W3C), is similar to the language of today's Web pages, the Hypertext Markup Language (HTML). Both XML and HTML contain markup symbols to describe the contents of a page or file. HTML, however, describes the content of a Web page (mainly text and graphic images) only in terms of how it is to be displayed and interacted with. For example, the letter "p" placed within markup tags starts a new paragraph. XML describes the content in terms of what data is being described. For example, the word "phonenum" placed within markup tags could indicate that the data that followed was a phone number. This means that an XML file can be processed purely as data by a program or it can be stored with similar data on another computer or, like an HTML file, that it can be displayed. For example, depending on how the application in the receiving computer wanted to handle the phone number, it could be stored, displayed, or dialed.

XML is "extensible" because, unlike HTML, the markup symbols are unlimited and self-defining. XML is actually a simpler and easier-to-use subset of the Standard Generalized Markup Language (SGML), the standard for how to create a document structure. It is expected that HTML and XML will be used together in many Web applications. XML markup, for example, may appear within an HTML page.

Early applications of XML include Microsoft's Channel Definition Format (CDF), which describes a channel, a portion of a Web site that has been downloaded to your hard disk and is then is updated periodically as information changes. A specific CDF file contains data that specifies an initial Web page and how frequently it is updated. Another early application is ChartWare, which uses XML as a way to describe medical charts so that they can be shared by doctors.Applications related to banking, e-commerce ordering, personal preference profiles, purchase orders, litigation documents, part lists, and many others are anticipated.

Read More

XAML

What is XAML?

Expression Studio 2.0

Rate this topic

Extensible Application Markup Language, or XAML (pronounced "zemell"), is an XML-based markup language developed by Microsoft. XAML is the language behind the visual presentation of an application that you develop in Microsoft Expression Blend, just as HTML is the language behind the visual presentation of a Web page. Creating an application in Expression Blend means writing XAML code, either by hand or visually by working in the Design view of Expression Blend.

XAML as the equalizer between design applications

You can export art assets from Microsoft Expression Design 2 as XAML, and then import the XAML into your Expression Blend project. Some other design applications have tools that can convert art assets to XAML. You can search on the Internet for conversion tools that are posted on trusted sites.

For more information about importing XAML, see the topics Import XAML that is exported from Expression Design and Import assets from Expression Design 2 in this User Guide.

You can also import Silverlight 1.0 projects that are created by using a Silverlight template to encode a video project in Microsoft Expression Encoder 2. Additionally, you can modify the Silverlight templates that come with Expression Encoder 2 in Expression Blend 2. For more information, see Import a Silverlight 1.0 site from Expression Encoder 2 and Modify a Silverlight template for Expression Encoder 2 in Expression Blend.

The relationship between XAML and code-behind files

The XAML for any given document in Expression Blend is stored in a .xaml file. If there is underlying code for your XAML document, that code is stored in a file of the same name, with the additional extension of .cs or .vb. For example, if your XAML document is named Window1.xaml, the code-behind file will be called Window1.xaml.cs if the programming language of the code is C#.

Note:

In Silverlight 1.0 projects, the language used in the code-behind files is JavaScript. For more information, see Quick start with Silverlight 1.0.

For information about how to create XAML documents with or without code-behind files, see the topic  Create a new document or project in this User Guide.

When you build your project, the WPF parser reads the. Xaml files for that project and reports any resulting errors. Likewise, when you open an existing project in Expression Blend, the XAML parser reads the. Xaml files that are included in your project folder and attempts to parse the elements and display the documents on the art board in Design view. In both cases, if the parser encounters errors, the art board is disabled, and Expression Blend displays an error message with a link to open XAML view so that you can resolve the errors. The parsing errors are also reported on the Errors tab in the Results panel. For more information, see the topics Editing XAML, Handling errors, and Debug Expression Blend applications in this User Guide. For information about the syntax of individual controls, see Control Library or search for XAML elements in the Class Library reference, both on MSDN.

Read More