Double-checked locking and the Singleton pattern-A comprehensive look at this broken programming idiom

Peter Haggar (haggar@us.ibm.com), Senior Software Engineer, IBM

01 May 2002

All programming languages have their share of idioms. Many are useful to know and use, and programmers spend valuable time creating, learning, and implementing them. The problem is that some idioms are later proven not to be all that they were purported, or to simply not work as described. The Java programming language contains several useful programming idioms. It also contains some that further study has shown should not be used. Double-checked locking is one such idiom that should never be used. In this article, Peter Haggar examines the roots of the double-checked locking idiom, why it was developed, and why it doesn't work.

Editor's note: This article refers to the Java Memory Model before it was revised for Java 5.0; statements about memory ordering may no longer be correct. However, the double-checked locking idiom is still broken under the new memory model.

The Singleton creation pattern is a common programming idiom. When used with multiple threads, you must use some type of synchronization. In an effort to create more efficient code, Java programmers created the double-checked locking idiom to be used with the Singleton creation pattern to limit how much code is synchronized. However, due to some little-known details of the Java memory model, this double-checked locking idiom is not guaranteed to work. Instead of failing consistently, it will fail sporadically. In addition, the reasons for its failure are not obvious and involve intimate details of the Java memory model. These facts make a code failure due to double-checked locking very difficult to track down. In the remainder of this article, we'll examine the double-checked locking idiom in detail to understand just where it breaks down.

Singleton creation idiom

To understand where the double-checked locking idiom originated, you must understand the common singleton creation idiom, which is illustrated in Listing 1:


Listing 1. Singleton creation idiom

import java.util.*;
class Singleton
{
private static Singleton instance;
private Vector v;
private boolean inUse;

private Singleton()
{
v = new Vector();
v.addElement(new Object());
inUse = true;
}

public static Singleton getInstance()
{
if (instance == null) //1
instance = new Singleton(); //2
return instance; //3
}
}


The design of this class ensures that only one Singleton object is ever created. The constructor is declared private and the getInstance() method creates only one object. This implementation is fine for a single-threaded program. However, when multiple threads are introduced, you must protect the getInstance() method through synchronization. If the getInstance() method is not protected, it is possible to return two different instances of the Singleton object. Consider two threads calling the getInstance() method concurrently and the following sequence of events:

1. Thread 1 calls the getInstance() method and determines that instance is null at //1.

2. Thread 1 enters the if block, but is preempted by thread 2 before executing the line at //2.

3. Thread 2 calls the getInstance() method and determines that instance is null at //1.

4. Thread 2 enters the if block and creates a new Singleton object and assigns the variable instance to this new object at //2.

5. Thread 2 returns the Singleton object reference at //3.

6. Thread 2 is preempted by thread 1.

7. Thread 1 starts where it left off and executes line //2 which results in another Singleton object being created.

8. Thread 1 returns this object at //3.

The result is that the getInstance() method created two Singleton objects when it was supposed to create only one. This problem is corrected by synchronizing the getInstance() method to allow only one thread to execute the code at a time, as shown in Listing 2:


Listing 2. Thread-safe getInstance() method

public static synchronized Singleton getInstance()
{
if (instance == null) //1
instance = new Singleton(); //2
return instance; //3
}


The code in Listing 2 works fine for multithreaded access to the getInstance() method. However, when you analyze it you realize that synchronization is required only for the first invocation of the method. Subsequent invocations do not require synchronization because the first invocation is the only invocation that executes the code at //2, which is the only line that requires synchronization. All other invocations determine that instance is non-null and return it. Multiple threads can safely execute concurrently on all invocations except the first. However, because the method is synchronized, you pay the cost of synchronization for every invocation of the method, even though it is only required on the first invocation.

In an effort to make this method more efficient, an idiom called double-checked locking was created. The idea is to avoid the costly synchronization for all invocations of the method except the first. The cost of synchronization differs from JVM to JVM. In the early days, the cost could be quite high. As more advanced JVMs have emerged, the cost of synchronization has decreased, but there is still a performance penalty for entering and leaving a synchronized method or block. Regardless of the advancements in JVM technology, programmers never want to waste processing time unnecessarily.

Because only line //2 in Listing 2 requires synchronization, we could just wrap it in a synchronized block, as shown in Listing 3:


Listing 3. The getInstance() method

public static Singleton getInstance()
{
if (instance == null)
{
synchronized(Singleton.class) {
instance = new Singleton();
}
}
return instance;
}


The code in Listing 3 exhibits the same problem as demonstrated with multiple threads and Listing 1. Two threads can get inside of the if statement concurrently when instance is null. Then, one thread enters the synchronized block to initialize instance, while the other is blocked. When the first thread exits the synchronized block, the waiting thread enters and creates another Singleton object. Note that when the second thread enters the synchronized block, it does not check to see if instance is non-null.


Back to top


Double-checked locking

To fix the problem in Listing 3, we need a second check of instance. Thus, the name "double-checked locking." Applying the double-checked locking idiom to Listing 3 results in Listing 4.


Listing 4. Double-checked locking example

public static Singleton getInstance()
{
if (instance == null)
{
synchronized(Singleton.class) { //1
if (instance == null) //2
instance = new Singleton(); //3
}
}
return instance;
}


The theory behind double-checked locking is that the second check at //2 makes it impossible for two different Singleton objects to be created as occurred in Listing 3. Consider the following sequence of events:

1. Thread 1 enters the getInstance() method.

2. Thread 1 enters the synchronized block at //1 because instance is null.

3. Thread 1 is preempted by thread 2.

4. Thread 2 enters the getInstance() method.

5. Thread 2 attempts to acquire the lock at //1 because instance is still null. However, because thread 1 holds the lock, thread 2 blocks at //1.

6. Thread 2 is preempted by thread 1.

7. Thread 1 executes and because instance is still null at //2, creates a Singleton object and assigns its reference to instance.

8. Thread 1 exits the synchronized block and returns instance from the getInstance() method.

9. Thread 1 is preempted by thread 2.

10. Thread 2 acquires the lock at //1 and checks to see if instance is null.

11. Because instance is non-null, a second Singleton object is not created and the one created by thread 1 is returned.

The theory behind double-checked locking is perfect. Unfortunately, reality is entirely different. The problem with double-checked locking is that there is no guarantee it will work on single or multi-processor machines.

The issue of the failure of double-checked locking is not due to implementation bugs in JVMs but to the current Java platform memory model. The memory model allows what is known as "out-of-order writes" and is a prime reason why this idiom fails.


Back to top


Out-of-order writes

To illustrate the problem, you need to re-examine line //3 from Listing 4 above. This line of code creates a Singleton object and initializes the variable instance to refer to this object. The problem with this line of code is that the variable instance can become non-null before the body of the Singleton constructor executes.

Huh? That statement might be contradictory to everything you thought possible, but it is, in fact, the case. Before explaining how this happens, accept this fact for a moment while examining how this breaks the double-checked locking idiom. Consider the following sequence of events with the code in Listing 4:

1. Thread 1 enters the getInstance() method.

2. Thread 1 enters the synchronized block at //1 because instance is null.

3. Thread 1 proceeds to //3 and makes instance non-null, but before the constructor executes.

4. Thread 1 is preempted by thread 2.

5. Thread 2 checks to see if instance is null. Because it is not, thread 2 returns the instance reference to a fully constructed, but partially initialized, Singleton object.

6. Thread 2 is preempted by thread 1.

7. Thread 1 completes the initialization of the Singleton object by running its constructor and returns a reference to it.

This sequence of events results in a period of time where thread 2 returned an object whose constructor had not executed.

To show how this occurs, consider the following pseudo code for the line: instance =new Singleton();

mem = allocate(); //Allocate memory for Singleton object.
instance = mem; //Note that instance is now non-null, but
//has not been initialized.
ctorSingleton(instance); //Invoke constructor for Singleton passing
//instance.


This pseudo code is not only possible, but is exactly what happens on some JIT compilers. The order of execution is perceived to be out of order, but is allowed to happen given the current memory model. The fact that JIT compilers do just this makes the issues of double-checked locking more than simply an academic exercise.

To demonstrate this, consider the code in Listing 5. It contains a stripped-down version of the getInstance() method. I've removed the "double-checkedness" to ease our review of the assembly code produced (Listing 6). We are interested only in seeing how the line instance=new Singleton(); is compiled by the JIT compiler. In addition, I've provided a simple constructor to make it clear when the constructor is run in the assembly code.


Listing 5. Singleton class to demonstrate out-of-order writes

class Singleton
{
private static Singleton instance;
private boolean inUse;
private int val;

private Singleton()
{
inUse = true;
val = 5;
}
public static Singleton getInstance()
{
if (instance == null)
instance = new Singleton();
return instance;
}
}


Listing 6 contains the assembly code produced by the Sun JDK 1.2.1 JIT compiler for the body of the getInstance() method from Listing 5.


Listing 6. Assembly code produced from code in Listing 5

;asm code generated for getInstance
054D20B0 mov eax,[049388C8] ;load instance ref
054D20B5 test eax,eax ;test for null
054D20B7 jne 054D20D7
054D20B9 mov eax,14C0988h
054D20BE call 503EF8F0 ;allocate memory
054D20C3 mov [049388C8],eax ;store pointer in
;instance ref. instance
;non-null and ctor
;has not run
054D20C8 mov ecx,dword ptr [eax]
054D20CA mov dword ptr [ecx],1 ;inline ctor - inUse=true;
054D20D0 mov dword ptr [ecx+4],5 ;inline ctor - val=5;
054D20D7 mov ebx,dword ptr ds:[49388C8h]
054D20DD jmp 054D20B0


Note: To reference the lines of assembly code in the following explanation, I refer to the last two values of the instruction address because they all begin with 054D20. For example, B5 refers to test eax,eax.

The assembly code is produced by running a test program that calls the getInstance() method in an infinite loop. While the program runs, run the Microsoft Visual C++ debugger and attach it to the Java process representing the test program. Then, break the execution and find the assembly code representing the infinite loop.

The first two lines of assembly code at B0 and B5 load the instance reference from memory location 049388C8 into eax and test for null. This corresponds to the first line of the getInstance() method in Listing 5. The first time this method is called, instance is null and the code proceeds to B9 . The code at BE allocates the memory from the heap for the Singleton object and stores a pointer to that memory in eax. The next line, C3, takes the pointer in eax and stores it back into the instance reference at memory location 049388C8. As a result, instance is now non-null and refers to a valid Singleton object. However, the constructor for this object has not run yet, which is precisely the situation that breaks double-checked locking. Then at line C8, the instance pointer is dereferenced and stored in ecx. Lines CA and D0 represent the inline constructor storing the values true and 5 into the Singleton object. If this code is interrupted by another thread after executing line C3 but before completing the constructor, double-checked locking fails.

Not all JIT compilers generate the code as above. Some generate code such that instance becomes non-null only after the constructor executes. Both the IBM SDK for Java technology, version 1.3 and the Sun JDK 1.3 produce code such as this. However, this does not mean you should use double-checked locking in these instances. There are other reasons it could fail. In addition, you do not always know which JVMs your code will run on, and the JIT compiler could always change to generate code that breaks this idiom.


Back to top


Double-checked locking: Take two

Given that the current double-checked locking code does not work, I've put together another version of the code, shown in Listing 7, to try to prevent the out-of-order write problem you just saw.


Listing 7. Attempting to solve the out-of-order write problem

public static Singleton getInstance()
{
if (instance == null)
{
synchronized(Singleton.class) { //1
Singleton inst = instance; //2
if (inst == null)
{
synchronized(Singleton.class) { //3
inst = new Singleton(); //4
}
instance = inst; //5
}
}
}
return instance;
}


Looking at the code in Listing 7 you should realize that things are getting a little ridiculous. Remember, double-checked locking was created as a way to avoid synchronizing the simple three-line getInstance() method. The code in Listing 7 has gotten out of hand. In addition, the code does not fix the problem. Careful examination reveals why.

This code is trying to avoid the out-of-order write problem. It tries to do this by introducing the local variable inst and a second synchronized block. The theory works as follows:

1. Thread 1 enters the getInstance() method.

2. Because instance is null, thread 1 enters the first synchronized block at //1.

3. The local variable inst gets the value of instance, which is null at //2.

4. Because inst is null, thread 1 enters the second synchronized block at //3.

5. Thread 1 then begins to execute the code at //4, making inst non-null but before the constructor for Singleton executes. (This is the out-of-order write problem we just saw.)

6. Thread 1 is preempted by Thread 2.

7. Thread 2 enters the getInstance() method.

8. Because instance is null, thread 2 attempts to enter the first synchronized block at //1. Because thread 1 currently holds this lock, thread 2 blocks.

9. Thread 1 then completes its execution of //4.

10. Thread 1 then assigns a fully constructed Singleton object to the variable instance at //5 and exits both synchronized blocks.

11. Thread 1 returns instance.

12. Thread 2 then executes and assigns instance to inst at //2.

13. Thread 2 sees that instance is non-null, and returns it.

The key line here is //5. This line is supposed to ensure that instance will only ever be null or refer to a fully constructed Singleton object. The problem occurs where theory and reality run orthogonal to one another.

The code in Listing 7 doesn't work because of the current definition of the memory model. The Java Language Specification (JLS) demands that code within a synchronized block not be moved out of a synchronized block. However, it does not say that code not in a synchronized block cannot be moved into a synchronized block.

A JIT compiler would see an optimization opportunity here. This optimization would remove the code at //4 and the code at //5, combine it and generate the code shown in Listing 8:


Listing 8. Optimized code from Listing 7

public static Singleton getInstance()
{
if (instance == null)
{
synchronized(Singleton.class) { //1
Singleton inst = instance; //2
if (inst == null)
{
synchronized(Singleton.class) { //3
//inst = new Singleton(); //4
instance = new Singleton();
}
//instance = inst; //5
}
}
}
return instance;
}


If this optimization takes place, you have the same out-of-order write problem we discussed earlier.


Back to top


volatile anyone?

Another idea is to use the keyword volatile for the variables inst and instance. According to the JLS (see Resources), variables declared volatile are supposed to be sequentially consistent, and therefore, not reordered. But two problems occur with trying to use volatile to fix the problem with double-checked locking:

* The problem here is not with sequential consistency. Code is being moved, not reordered.

* Many JVMs do not implement volatile correctly regarding sequential consistency anyway.

The second point is worth expanding upon. Consider the code in Listing 9:


Listing 9. Sequential consistency with volatile

class test
{
private volatile boolean stop = false;
private volatile int num = 0;

public void foo()
{
num = 100; //This can happen second
stop = true; //This can happen first
//...
}

public void bar()
{
if (stop)
num += num; //num can == 0!
}
//...
}


According to the JLS, because stop and num are declared volatile, they should be sequentially consistent. This means that if stop is ever true, num must have been set to 100. However, because many JVMs do not implement the sequential consistency feature of volatile, you cannot count on this behavior. Therefore, if thread 1 called foo and thread 2 called bar concurrently, thread 1 might set stop to true before num is set to 100. This could lead thread 2 to see stop as true, but num still set to 0. There are additional problems with volatile and the atomicity of 64-bit variables, but this is beyond the scope of this article. See Resources for more information on this topic.


Back to top


The solution

The bottom line is that double-checked locking, in whatever form, should not be used because you cannot guarantee that it will work on any JVM implementation. JSR-133 is addressing issues regarding the memory model, however, double-checked locking will not be supported by the new memory model. Therefore, you have two options:

* Accept the synchronization of a getInstance() method as shown in Listing 2.

* Forgo synchronization and use a static field.

Option 2 is shown in Listing 10:


Listing 10. Singleton implementation with static field

class Singleton
{
private Vector v;
private boolean inUse;
private static Singleton instance = new Singleton();

private Singleton()
{
v = new Vector();
inUse = true;
//...
}

public static Singleton getInstance()
{
return instance;
}
}


The code in Listing 10 does not use synchronization and ensures that the Singleton object is not created until a call is made to the static getInstance() method. This is a good alternative if your objective is to eliminate synchronization.


Back to top


String is not immutable

You might wonder about the String class given the issue of out-of-order writes and a reference becoming non-null prior to the constructor executing. Consider the following code:

private String str;
//...
str = new String("hello");


The String class is supposed to be immutable. However, given the out-of-order write problem we discussed previously, could that cause a problem here? The answer is it could. Consider two threads with access to the String str. One thread could see the str reference refer to a String object in which the constructor has not run. In fact, Listing 11 contains code that shows this occurring. Note that this code breaks only with older JVMs that I tested. Both the IBM 1.3 and Sun 1.3 JVMs produce immutable Strings as expected.


Listing 11. Example of a Mutable String

class StringCreator extends Thread
{
MutableString ms;
public StringCreator(MutableString muts)
{
ms = muts;
}
public void run()
{
while(true)
ms.str = new String("hello"); //1
}
}
class StringReader extends Thread
{
MutableString ms;
public StringReader(MutableString muts)
{
ms = muts;
}
public void run()
{
while(true)
{
if (!(ms.str.equals("hello"))) //2
{
System.out.println("String is not immutable!");
break;
}
}
}
}
class MutableString
{
public String str; //3
public static void main(String args[])
{
MutableString ms = new MutableString(); //4
new StringCreator(ms).start(); //5
new StringReader(ms).start(); //6
}
}


This code creates a MutableString class at //4 that contains a String reference shared by two threads at //3. Two objects are created, StringCreator and StringReader, on two separate threads at lines //5 and //6, passing a reference to the MutableString object. The StringCreator class enters an infinite loop and creates String objects with the value "hello" at //1. The StringReader also enters an infinite loop and checks to see if the current String object has the value "hello" at //2. If it doesn't, the StringReader thread prints out a message and stops. If the String class is immutable, you should never see any output from this program. The only way for StringReader to see the str reference to be anything other than a String object with "hello" as its value is if the problem of out-of-order writes occurs.

Running this code on old JVMs like Sun JDK 1.2.1 results in the out-of-order write problem, and thus, a non-immutable String.


Back to top


Summary

In an effort to avoid costly synchronization in singletons, programmers, quite ingeniously, invented the double-checked locking idiom. Unfortunately, it was not until this idiom was in fairly wide use that it became apparent that it is not a safe programming construct due to the current memory model. Work is underway to redefine areas of the memory model that are weak. However, even under the newly proposed memory model, double-checked locking will not work. The best solution to this problem is to accept synchronization or use a static field.


Resources

* In his book Practical Java Programming Language Guide (Addison-Wesley, 2000), Peter Haggar covers a multitude of Java programming topics including an entire chapter on multithreading issues and programming techniques.

* The Java Language Specification, Second Edition by Bill Joy, et. al. (Addison-Wesley, 2000) is the definitive technical reference for the Java programming language.

* The Java Virtual Machine Specification, Second Edition by Tim Lindholm and Frank Yellin (Addison-Wesley, 1999) is the definitive document on Java compilers and runtime environments.

* Visit Bill Pugh's Java Memory Model Web site for a wealth of information on this important topic.

* For more information on volatile and 64-bit variables, see Peter Haggar's article "Does Java Guarantee Thread Safety?" in the June 2002 issue of Dr. Dobb's Journal .

* JSR-133 deals with the revision to Java platform's memory model and thread specification.

* Java software consultant Brian Goetz examines when to use synchronization in "Threading lightly: Synchronization is not the enemy" (developerWorks, July 2001).

* In "Threading lightly: Sometimes it's best not to share" (developerWorks, October 2001), Brian Goetz examines ThreadLocal and offers tips for exploiting its power.

* In "Writing multithreaded Java applications" (developerWorks, February 2001), Alex Roetter introduces the Java Thread API, outlines issues involved in multithreading, and offers solutions to common problems.

* Allen Holub proposes significant changes and additions to the Java language in "If I were king: A proposal for fixing the Java programming language's threading problems" (developerWorks, October 2000).

* Find other Java technology resources on the developerWorks Java technology zone.



About the author



Peter Haggar is a Senior Software Engineer with IBM in Research Triangle Park, North Carolina, and the author of the book Practical Java Programming Language Guide published by Addison-Wesley. In addition, he has published numerous articles on Java programming. He has a broad range of programming experience, having worked on development tools, class libraries, and operating systems. At IBM, Peter works on emerging Internet technology and is currently focused on high-performance Web services. Peter is a frequent technical speaker on Java technology at numerous industry conferences. He has worked for IBM for more than 14 years and received a B.S. in Computer Science from Clarkson University. Contact Peter at haggar@us.ibm.com.

Computers 'could store entire life by 2026' by Nic Fleming, Science Correspondent

Audio: You'll be able to record your entire life on video, says Nic Fleming A device the size of a sugar cube will be able to record and store high resolution video footage of every second of a human life within two decades, experts said yesterday. Researchers said governments and societies must urgently debate the implications of the huge increases in computing power and the growing mass of information being collected on individuals. Some fear that the advent of "human black boxes" combined with the extension of medical, financial and other digital records will lead to loss of privacy and a dramatic expansion of the nanny state. Others highlight positive advances in medicine, education, crime prevention and the way history will be recorded. Leading computer scientists, psychologists and neuroscientists gathered to debate these issues at Memories for Life, a conference held at the British Library yesterday. Prof Nigel Shadbolt, president of the British Computer Society and professor of artificial intelligence at the University of Southampton, said: "In 20 years' time it will be possible to record high quality digital video of an entire lifetime of human memories. It's not a question of whether it will happen; it's already happening." A lap top available in the High Street can hold some 80 gigabytes (GB) of information. One hour of high resolution video footage requires 12GB. Since the year 2000, computing processing power has been doubling approximately every 18 months - a phenomenon known as Moore’s Law. Prof Shadbolt has calculated that it would take 5.5 petabytes (PT) to record every awake second of a person’s life in high resolution video. One PT equals one million GB. Experts expect the increase in computing power to lead to advances in “ehealth” with doctors having access to information from devices that monitor physiological data such as heart rate and blood sugar levels. Retailers want to get more information on their customers’ habits than they already have from their loyalty cards. The technological advances will also have a dramatic impact on the writing of biographies and history, with authors and historians able to gain vastly more information on key figures. Cliff Lynch, director of the US think tank Coalition for Networked Information, said the changes would allow the preservation of much more detailed memories, but could lead to a dramatic extension of state interference. “We will be able to replicate and pass on so much more information. In future you are going to have a much more elaborate picture for more and more people. “Biographers and other kinds of scholars who want to understand what someone was thinking are going to be based with an embarrassment of riches. “There is a certain tendency towards a technological nanny state. Imagine having a personal companion that wines at you three times a day, telling you that you are eating the wrong things and that you spent more than you earned today and you’ll never be able to retire. “Imagine we could end up with smart refrigerator that tells you ‘you’ve already had your beer for the day, you can’t have another one’. “I don’t think people would want a world like that, but the scary thing is it might be foisted on them.” Prof Wendy Hall, of the University of Southampton, said: “Technology can play a vital role in memory, for example by providing an artificial aid to help those with memory disorders or enabling communities to create and preserve their collective experiences. “However, we must also consider the social, ethical and legal issues associated with technology development and how increased access to knowledge will affect our society in open, inter-disciplinary forums.”

Physics promises wireless power by Jonathan Fildes

The tangle of cables and plugs needed to recharge today's electronic gadgets could soon be a thing of the past.

US researchers have outlined a relatively simple system that could deliver power to devices such as laptop computers or MP3 players without wires.

The concept exploits century-old physics and could work over distances of many metres, the researchers said.

Although the team has not built and tested a system, computer models and mathematics suggest it will work.

"There are so many autonomous devices such as cell phones and laptops that have emerged in the last few years," said Assistant Professor Marin Soljacic from the Massachusetts Institute of Technology and one of the researchers behind the work.

"We started thinking, 'it would be really convenient if you didn't have to recharge these things'.

"And because we're physicists we asked, 'what kind of physical phenomenon can we use to do this wireless energy transfer?'."

The answer the team came up with was "resonance", a phenomenon that causes an object to vibrate when energy of a certain frequency is applied.

This would work in a room let's say but you could adapt it to work in a factory Marin Soljacic

"When you have two resonant objects of the same frequency they tend to couple very strongly," Professor Soljacic told the BBC News website.

Resonance can be seen in musical instruments for example.

"When you play a tune on one, then another instrument with the same acoustic resonance will pick up that tune, it will visibly vibrate," he said.

Instead of using acoustic vibrations, the team's system exploits the resonance of electromagnetic waves. Electromagnetic radiation includes radio waves, infrared and X-rays.

Typically, systems that use electromagnetic radiation, such as radio antennas, are not suitable for the efficient transfer of energy because they scatter energy in all directions, wasting large amounts of it into free space.

To overcome this problem, the team investigated a special class of "non-radiative" objects with so-called "long-lived resonances".

When energy is applied to these objects it remains bound to them, rather than escaping to space. "Tails" of energy, which can be many metres long, flicker over the surface.

"If you bring another resonant object with the same frequency close enough to these tails then it turns out that the energy can tunnel from one object to another," said Professor Soljacic.

Hence, a simple copper antenna designed to have long-lived resonance could transfer energy to a laptop with its own antenna resonating at the same frequency. The computer would be truly wireless.

Any energy not diverted into a gadget or appliance is simply reabsorbed.

The systems that the team have described would be able to transfer energy over three to five metres.

"This would work in a room let's say but you could adapt it to work in a factory," he said.

"You could also scale it down to the microscopic or nanoscopic world."

Old technology

The team from MIT is not the first group to suggest wireless energy transfer.

Nineteenth-century physicist and engineer Nikola Tesla experimented with long-range wireless energy transfer, but his most ambitious attempt - the 29m high aerial known as Wardenclyffe Tower, in New York - failed when he ran out of money.

Others have worked on highly directional mechanisms of energy transfer such as lasers.

However, these require an uninterrupted line of sight, and are therefore not good for powering objects around the home.

A UK company called Splashpower has also designed wireless recharging pads onto which gadget lovers can directly place their phones and MP3 players to recharge them.

The pads use electromagnetic induction to charge devices, the same process used to charge electric toothbrushes.

One of the co-founders of Splashpower, James Hay, said the MIT work was "clearly at an early stage" but "interesting for the future".

"Consumers desire a simple universal solution that frees them from the hassles of plug-in chargers and adaptors," he said.

"Wireless power technology has the potential to deliver on all of these needs."

However, Mr Hay said that transferring the power was only part of the solution.

"There are a number of other aspects that need to be addressed to ensure efficient conversion of power to a form useful to input to devices."

Professor Soljacic will present the work at the American Institute of Physics Industrial Physics Forum in San Francisco on 14 November.

The work was done in collaboration with his colleagues Aristeidis Karalis and John Joannopoulos.

HOW WIRELESS POWER COULD WORK 1) Power from mains to antenna, which is made of copper 2) Antenna resonates at a frequency of 6.4MHz, emitting electromagnetic waves 3) 'Tails' of energy from antenna 'tunnel' up to 5m (16.4ft) 4) Electricity picked up by laptop's antenna, which must also be resonating at 6.4MHz. Energy used to re-charge device 5) Energy not transferred to laptop re-absorbed by source antenna. People/other objects not affected as not resonating at 6.4MHz

(track back URL : http://news.bbc.co.uk/go/pr/fr/-/2/hi/technology/6129460.stm)

How to Check Your Website with Multiple Browsers on a Single Machine (Cross-Browser Compatibility Checking)

How to Check Your Website with Multiple Browsers on a Single Machine (Cross-Browser Compatibility Checking)
by Christopher Heng, thesitewizard.com

We all know the importance of checking our web pages with multiple browsers, especially when we are designing a new layout for a website. The number of extant browsers we need to check with are enormous: Internet Explorer (IE) 6, IE 5.5, IE 5.0, Netscape 7.X (ie, Mozilla 1.0.X), Netscape 6.X (or Mozilla 0.9.X), Mozilla 1.3.X (and above), Opera 7, Opera 6/5, Netscape 4.X, IE 4.X and so on. And then there are the different platforms: Windows, Macintosh (Mac), Linux, etc. The problem for most people is that multiple versions of certain browsers cannot co-exist with each other, the most notable example of this is IE for Windows. Unless you are privileged to have multiple computers, this presents a certain difficulty for the average webmaster. This article suggests some ways for you to run multiple versions of multiple browsers on one computer.
Note that this article is written primarily from the point of view of a person using Windows (the majority of people reading this article), although it does address the issue of Mac browsers and Linux browsers as well.
Mozilla and Netscape
It's possible for Netscape 4.X, Netscape 6.X (or Mozilla 0.9.X), Netscape 7 (Mozilla 1.0.X), Mozilla 1.1.X, Mozilla 1.2.X, Mozilla 1.3.X (and so on) to all co-exist on the same machine.
1. Netscape 4.X
You should have one version of the Netscape 4.X series installed. Take your pick - they are all approximately the same in their level of support for the Cascading Style Sheets (CSS) standards. Some people prefer to use one of the older versions on the basis that if their page renders correctly on that version, it should theoretically render correctly on the later 4.X versions. My approach is to simply install the latest in this series: I suspect that fixes made in the later versions are mainly security fixes. In any case, my testing with this browser is restricted to making sure that people using the browser can read and navigate thesitewizard.com and thefreecountry.com with the browser. I don't spend any time at all making the site look good for the browser, since the number of people using this browser is decreasing all the time. (It's the law of diminishing returns.)
Netscape makes older versions of its browsers available from http://wp.netscape.com/download/archive.html
2. Netscape 6.X, Netscape 7.X, Mozilla 1.X
If you did not already know, Netscape 6/7 (and later) and Mozilla use the same Gecko rendering engine. As such, if you have Netscape 6.X, you are in effect using the rendering engine of a beta version of Mozilla (one of the 0.9.X series); if you use Netscape 7, you are using the Mozilla 1.0.X engine; and if you use Netscape 7.1 you're using the same engine as Mozilla 1.4. The point is that you don't have to install, say, Mozilla 1.0.X if you're using Netscape 7, and so on. My personal preference is to have one of each of the major releases of Netscape installed (or their Mozilla equivalent), as well as the latest released version of Mozilla. At the time I write this, this works out to be Netscape 6.X, Netscape 7 and Mozilla 1.4 (same as Netscape 7.1).
It is easy to make these versions of Netscape/Mozilla co-exist with each other. Install them into separate directories and create a different profile for each browser you install. (For non-Netscape/Mozilla users, this browser allows you to create different profiles so that you can store different settings for different situations.) To create a different profile, simply start up the Mozilla or Netscape Profile Manager, and answer the questions given by the wizard. Be sure you do this before you start configuring each browser, or the settings you make in one browser may bleed over to the other, and possibly confuse the other version.
Once you've finished creating profiles, you will want to create shortcuts (Windows terminology) to run the different versions of the browser. This makes life easier for you: you can simply click the appropriate icon for the different versions, and it will load using the correct profile. To specify which profile the browser is to load, put the profile name after the "-P" option.
For example, if you have created a profile named "netscape6", your command for running (say) Netscape with that profile may look like:

"C:\Program Files\Netscape\Netscape 6\netscp6.exe" -P netscape6

Similarly, your command to run Mozilla 1.4 with a profile called "mozilla" may look like:

"C:\Program Files\mozilla.org\Mozilla\mozilla.exe" -P mozilla

And so on.
The latest version of Netscape can be obtained from http://channels.netscape.com/ns/browsers/download.jsp
Mozilla can be obtained from http://www.mozilla.org
Opera for Windows/Linux
Opera is the third most used browser used on thesitewizard.com and thefreecountry.com, and is particularly popular among the seasoned webmaster community (which probably explains why so many of my visitors use it).
Opera 6 and 7 can co-exist on one computer. If you want to install both versions on Windows, simply put them in separate directories. No extra steps are required. I don't know if this also works with earlier versions of Opera, since I don't bother to check my site with those.
As for Linux, at the time I write this, I only have version 6 of Opera installed, so I have no idea if two versions can co-exist on that platform.
You can obtain Opera for any of its supported operating systems from Opera's website. To get older versions, just navigate to the downloads page and click the "Opera archives" link.
Internet Explorer 5.0, 5.5, 6.0 for Windows
In all my sites, at the time of this writing, IE users comprise the majority of visitors, with the bulk of them using IE 6.0.
My experience in coding the recent new designs for thesitewizard.com and thefreecountry.com, both of which depend heavily upon Cascading Style Sheets for layout, is that IE 6 is a very different animal from IE 5.X. Contrary to what you may expect, what works in IE 5.5 does not necessarily work in IE 6. In fact, if my limited experience with coding my sites is anything to go by, what works for IE 6 is more likely to work for IE 5.5 than vice versa. As a result, if you can only install one version of IE, and your site uses CSS, a case can be made that it is better to install IE 6 than 5.X.
(It seems that IE 6 has a number of bugs in its CSS box model, causing sites that work in Mozilla/Netscape, Opera and IE 5.X to break under IE 6. That is not to say that IE 5 does not have bugs. All the more reason to install multiple versions.)
Unlike Opera, Mozilla and Netscape, you can only install one version of IE in a single installation of Windows. The bulk of IE's code does not get installed into its own subdirectory (or folder) but into Windows' system directory, so even if you somehow successfully install different versions of IE, they will all wind up using the code for the latest installed version (assuming they don't crash).
1. Running Two or Three Versions of IE on One Machine
The simplest way to run two versions of IE on a single machine is to install two versions of Windows in that machine. That is, install Windows 95/98/ME (ie, either Windows 95 or 98 or 98 Second Edition or ME) onto one partition on your hard drive, and install Windows 2000 or XP in another partition in a dual-boot configuration.
In plain English, this means that you need to partition your hard disk into (at least) two partitions. First install Windows 95/98/98SE/ME into drive C:. When you finish that, run the Windows 2000 or Windows XP setup program from within the first version of Windows you installed. Select the "Clean install" option and not the "Upgrade" option when you're asked. You will be presented with a window later where you can click the "Advanced options" button. In the window that is displayed, check the box labelled "I want to choose the installation partition during setup". Later in the installation process, when you are asked, choose to install Windows 2000 (or XP) in the second partition. Windows 2000 or XP will then (automatically) install a menu that appears when you start up your machine, allowing you to choose the version of Windows you want to boot.
It is apparently also possible to install three versions of Windows (and hence three versions of IE) into one machine without resorting to third party software. You'll need to have at least three partitions on your hard disk to play with. Install Windows 95/98/98SE/ME into C: and use the above procedure to install Windows 2000 into the second partition. Finally, use the same procedure to install Windows XP into the third partition. I have not tried "triple booting" three Windows versions before, but one of thesitewizard.com's visitors has assured me that it works. With three versions of Windows to play with, you should be able to use three versions of IE on the same machine.
Note that Windows 95 installs IE 3 by default, Windows 98 installs IE 4, Windows 98 Second Edition installs IE 5.0, Windows 2000 installs IE 5.0, Windows ME installs IE 5.5 and Windows XP installs IE 6.0, so if you might want to plan carefully which Windows version you install so that you get the IE version you need for testing. As far as I know, you can't easily (if at all) "downgrade" a version of IE (although you can upgrade it), so if you need something as old as IE 4, you might need to install Windows 98 (or even Windows 95 and upgrade IE to 4.0).
2. Running More than Three Versions of Internet Explorer
If you really need to run more than three versions of IE and can't afford to (or don't want to) use another machine, you'll need to install either an emulator or use one of those software that creates a virtual machine (sometimes called a virtualizer).
Loosely speaking, an emulator allows you to run another copy of Windows within your existing version of Windows or Linux (or FreeBSD or whatever). The emulator pretends to be a new computer, and Windows gets installed into a small space on your hard disk which the emulator uses to mimic an entire drive.
You can find a list of free PC emulators and virtualizers listed on thefreecountry.com's Free PC (x86) Emulators and Virtual Machines at http://www.thefreecountry.com/emulators/pc.shtml
Some of the emulators listed there, such as Bochs, allow you to emulate a PC machine on which you can install Windows or Linux or any other PC operating system. Bochs itself may be installed on Windows, Linux, Mac, and possibly other systems and machines as well. If you are a Mac user, this is one way to run the Windows version of IE without having to buy a PC.
Be warned though that full emulators like Bochs are extremely slow. You may be able to tolerate it though, if you are only using it to test your web pages once in a blue moon.
If you already have a PC, another solution is to run a program that can create virtual machines. While emulators can pretend to be a completely different machine (such as a Mac pretending to be a PC), virtual machines merely sets up a space within your existing machine and runs a new copy of the operating system (such as Windows) within that space. The new copy of (say) Windows thinks that it is the only one running (even if you are running it within (say) yet another copy of Windows. Since virtual machines do not have to emulate a completely different machine, they tend to be slightly faster than full emulators.
Free virtual machines can be found on the same page as the emulators on Free PC (x86) Emulators and Virtualizers at http://www.thefreecountry.com/emulators/pc.shtml
Once you have obtained an emulator or a virtualizer, you simply install a new copy of Windows in each "machine" you set up. For each copy of Windows you set up, install a different version of IE, and you're done.
Testing Mac Browsers
As you might expect, the easiest way to test your page on Mac browsers (like Safari, Camino, Mozilla, Opera, etc) is to actually own a Mac.
However, work is under way in the open source software community to create a PowerPC Mac emulator for x86 machines (ie, PCs) that will run Mac OS X. Once this project is complete, you should be able to simply download the emulator, buy a copy of Mac OS X, install them on your PC, and you have a working Macintosh in a window of your Linux or Windows machine that you can use to test your site under Mac browsers. Don't expect your emulated Macintosh to perform at the same speed as a real Mac though. For the purpose of occasionally testing a website or two, though, the emulator will probably suffice if you have a healthy dose of patience.
You can also run Mac emulators for the older 68k Macs (like Quadra, Performa, etc). These emulators, however, require you to have a real Mac around, since you need to copy the ROM from one of those Macs before the emulator will work. In any case, for the purpose of testing web pages, the 68k Macintosh emulators are not very useful, since they can only emulate the older Macs, which only run browsers like IE 4 and Netscape 4. If your site is like mine, you will find that people using such browsers are few and far between (if at all).
Anyway, if you're curious, you can find free Mac emulators listed on thefreecountry.com's Free 68k and PowerPC Macintosh Emulators at http://www.thefreecountry.com/emulators/macintosh.shtml
Testing Linux Browsers
One of the easiest ways to test your site to see how it appears under Linux is to run Linux from a CDROM. There are numerous Linux "live" CDROMs around. These allow you to simply boot your machine from the CDROM directly into Linux without having to install anything onto your hard disk. One of the best-known "live" Linux systems around is Knoppix, which you can obtain from http://www.knopper.net/knoppix/index-en.html. Essentially, all you have to do is to download the ISO (which is just an image of the CDROM), burn it to your CDR, put it in your CDROM drive, and restart your computer. Knoppix is free.
Alternatively, if you prefer to install Linux on your hard disk, it can be set up so that it co-exists with Windows. Make sure you have space for a new partition on your hard disk, install it and you're done.
The default browser that comes on many Linux distributions is Mozilla. However, you will find that even though Mozilla basically renders your page identically for all platforms, the fonts available under Linux are different from those available on Windows. If you don't code your font tags or CSS font-families in a cross-platform compatible way, your site may wind up being rendered with an ugly font. For example, many sites simply specify "Arial" or "Impact" or some such Windows font for their site. Since these fonts are not available by default under non-Windows systems, your site will be rendered using either the default font on those browsers or some other font that the browser thinks matches the type of font you've specified. If you don't want to bother to run Linux to test, be sure that you at least:
Test your pages under Mozilla for your platform.
Specify generally available alternative fonts for your web pages. For example, don't just say,

font-family: Arial ;

in your style sheet, say

font-family: Arial, Helvetica, sans-serif ;

instead.
There are a number of other browsers available on the Linux platform. You may have seen them in your web logs. They include, for example, Konqueror, Opera for Linux and Mozilla spin-offs.
Conclusion
It's a good idea to test your site with multiple versions of multiple browsers, particularly if you plan to do anything fancy with style sheets on your site. This doesn't mean that you have to support all browsers - for example, the pages on thesitewizard.com do not work well (if at all) under IE 4 and Netscape 3 (and earlier). However, when you are able to test your pages this way, you can at least reduce the number of problems your pages have with the different browsers. The tips in this article allow you to test with multiple browsers even if you have only one machine.
Copyright 2003-2004 by Christopher Heng. All rights reserved.Get more free tips and articles like this, on web design, promotion, revenue and scripting, from http://www.thesitewizard.com/.
This article can be found at http://www.thesitewizard.com/webdesign/multiplebrowsers.shtml
thesitewizard™ RSS Site Feed
Do you find this article useful? You can learn of new articles and scripts that are published on thesitewizard.com by subscribing to the RSS feed. Simply point your RSS feed reader or a browser that supports RSS feeds at http://www.thesitewizard.com/thesitewizard.xml. You can read more about how to subscribe to RSS site feeds from our RSS FAQ.
Please Do Not Reprint This Article
This article is copyrighted. Please do not reproduce this article in whole or part, in any form, without obtaining my written permission.
Related Pages
Appearance, Usability and Search Engine Visibility in Web DesignHTML and CSS Validation: Should You Validate Your Web Page?Designing for Browser and Platform CompatibilityDisabling the Image Toolbar in IE 6 for Your WebsiteIs Your Site Ready for the Average User?Two Common Web Design MythsWhich Web Host Would You Recommend? (FAQ)How to Register Your Own Domain NameFree HTML Editors and WYSIWYG Web EditorsFree FTP Clients
New Articles / Pages
Frequently Asked Questions (FAQ) about the Feedback Form WizardNvu Tutorial 5: How to Add a Feedback Form to Your WebsiteHow to Upload a File to Your Website Using the FileZilla FTP ClientNvu Tutorial 4: How to Create a Multiple Column LayoutNvu Tutorial 1: How to Design and Publish Your Website with Nvu (free WYSIWYG web editor)Appearance, Usability and Search Engine Visibility in Web DesignHTML and CSS Validation: Should You Validate Your Web Page?How to Check Your Website with Multiple Browsers on a Single Machine (Cross-Browser Compatibility Checking)Your Website's Spelling and the Search EnginesWhich Web Host Would You Recommend? (FAQ)
How to Link to This Page
To link to this page from your website, simply cut and paste the following code to your web page.
How to Check Your Website with Multiple Browsers on a Single Machine (Cross-Browser Compatibility Checking)

It will appear on your page as

Java Book Reviews

This is the place to find Java book reviews covering all aspects of Java programming, from introductions to specialised topics to J2EE to primers on object oriented development. Also covered are topics dear to the hearts of Java developers, including books on development tools such as Eclipse, XML and web services from a Java perspective to general programming topics and software methodologies.
If you don't find what you're looking for then take a look also at the TechBookReport programming book reviews, the XML book reviews, the web book reviews or software methodologies.



Ant: The Definitive Guide by Steve Holzner
Apache Derby - Off To The Races by Zikopoulous, Scott and Baklarz
Apache Jakarta Commons: Reusable Java Components by Will Iverson
Applied Evolutionary Algorithms in Java by Robert Ghanea-Hercock
Beginning Java 2 (JDK 1.4 Edition) by Ivor Horton
Better, Faster, Lighter Java by Bruce Tate and Justin Gehtland
Beyond Java by Bruce Tate
Code Complete by Steve McConnell
Code Quality by Diomidis Spinellis
Code Reading by Diomidis Spinellis
Cryptography In The Database by Kevin Kenan
Data Crunching by Greg Wilson
Data Structures With Java by John R. Hubbard and Anita Huray
Design Patterns Explained by A. Shalloway and J. Trott
Eclipse - Building Commercial-Quality Plugins by Eric Clayberg and Dan Rubel
Eclipse 3 Live by Bill Dudney
Eclipse 3.0 Kick Start by Carlos Valcarcel
Eclipse by Steve Holzner
Eclipse Cookbook by Steve Holzner
Effective Java by Joshua Bloch
The Elements of Java Style
Embedded Ethernet and Internet Complete by Jan Axelson
FindBugs
From Java To C# - A Developer's Guide by Heng Ngee Mok
Google Hacks by Tara Calishain and Rael Dornfest
Google Hacks, 2 by Tara Calishain and Rael Dornfest
Google, Amazon, and Beyond by Tom Myers and Alexander Nakhimovsky
Guide to J2EE: Enterprise Java by John Hunt and Chris Loftus
Hardcore Java by Robert Simmons, Jr
Head First Design Patterns by Eric and Elisabeth Freeman
Head First Java by Kathy Sierra and Bert Bates
Head First Java, 2e by Kathy Sierra and Bert Bates
Holub On Patterns by Allen Holub
IBM Rational ClearCase, Ant and CruiseControl by Kevin Lee
Integrated Solutions With DB2 by Rob Cutlip and John Medicke
Java 6 Platform Revealed by John Zukowski
Java Application Development On Linux by Carl Albing and Michael Schwarz
Java Concurrency In Practice by Brian Goetz
Java Cookbook by Ian Darwin
Java Data Objects by David Jordan and Craig Russell
Java Developers Almanac 1.4 by Patrick Chan
Java EE and .NET Interoperability by Marina Fisher, Ray Lai, Sonu Sharma and Laurence Moroney
Java Examples In A Nutshell by David Flanagan
Java Garage by Eben Hewitt
Java How To Program (5e) by Deitel and Deitel
Java I/O by Elliotte Rusty Hardold
Java In A Nutshell by David Flanagan
Java Puzzlers by Joshua Bloch and Neal gafter
Java Regular Expressions by Mehran Habibi
JCreator 3.5
JCreator Pro 2.5
JDiskReport 1.2
jEdit 4.2
Just Java 2 by Peter Van Der Linden
Learning Jakarta Stuts 1.2 by Stephan Wiesner
Learning Java, 3e by Patrick Niemeyer and Jonathan Knudsen
Learning UML 2.0 by Russ Miles and Kim Hamilton
Murach's Java Servlets and JSP by Andrea Steelman and Joel Murach
NetBeans IDE Field Guide by Patrick Keegan et al
NetBeans IDE Field Guide, 2e by Patrick Keegan et al
The No Fluff Just Stuff 2006 Anthology by Neal Ford
The Object-Oriented Thought Process by Matt Weisfeld
Objects First With Java by David J Barnes and Michael Kolling
POJOs In Action by Chris Richardson
Processing XML with Java by Elliotte Rusty Harold
Quartz Job Scheduling Framework by Chuck Cavaness
Refactoring: Improving the Design of Existing Code by Martin Fowler et al
Regular Expression Pocket Reference by Tony Stubblebine
RSSOwl 1.1.3
Spring: A Developer's Notebook by Bruce Tate and Justin Gehtland
SQuirreL SQL Client v1.1
Swing Hacks by Joshua Marinacci and Chris Adamson
Teach Yourself J2EE In 21 Days by Bond, Law et al
Teach Yourself Java 2 In 24 Hours by Rogers Cadenhead
Technical Java by Grant Palmer
Test-Driven Devlopment: A J2EE Example by Thomas Hammell
Thinking In Java (4e) by Bruce Eckel
Thinking In Java by Bruce Eckel
Wicked Cool Java by Brian D. Eubanks
XML Hacks by Michael Fitzgerald
XML Primer Plus by Nicholas Chase
XSLT Cookbook by Sal Mangano

Brian Slesinsky's Weblog

Wrap Strings in Classes to Increase Security

Forgetting to validate user input is an increasingly common security hole in web applications. Here's an elegant way to fix a hole and make your code more understandable at the same time.
Code that reads HTTP request parameters often looks something like this:

String productId = request.getParameter("id");
doSomething(productId);

The problem here is that we haven't validated the id parameter, and this string came from the network, so it could contain just about anything. The security holes caused by this can be somewhat surprising. For example, suppose we go on to do a redirect:

response.sendRedirect("https://www.example.com/page2?id=" + productId);

See the bug yet?
Suppose id starts with a newline, such as "\nsomething". The full HTTP response will look something like this:
HTTP/1.x 302 Found
Location: http://www.example.com/page2?id=
something

The attacker can put anything they like into the HTTP response, or even add multiple HTTP responses. (This is known as HTTP response splitting.)
It's relatively easy to spot the problem in a simple example like this because there's so little code. The solution is also easy to state: always validate any string that comes from the network.
However, there are often many method calls between the code that reads the request and the code that prints the response. Maybe we've crossed several layers as well. As the months go by and the code gets changed by multiple developers, it's easy to forget which methods have responsibility for doing input checking and drop the ball. It's very easy to assume that a variable named "productId" actually contains something that at least looks like a productId, but that only works if every request handler did its job.
Software developers have come up with many ways to fix this problem. Some of them are pretty cumbersome, like writing warnings everywhere saying who has responsibility for what, or using Hungarian notation. Some languages (such as Perl and Ruby) use taint-checking to report a runtime error when the program attempts to use untrusted input.
In Java, the approach I prefer is to introduce a new class:

public class ProductId {
private static final Pattern regexp = ...

private final String id;

ProductId(String allegedId) {
if (!regexp.matcher(allegedId).matches()) {
throw new IllegalArgumentException("invalid id: "+allegedId);
}
this.id = allegedId;
}

public String toString() {
return id;
}

...
}


At first glance this class doesn't seem to do very much. Wouldn't a checkProductId() method be sufficient?
The beauty of introducing a class is that it gives verified product id's a type. Any API that doesn't verify input itself can take arguments of type ProductId and be confident that the caller will do the checking, because the only way to get a ProductId type is to call the constructor:

ProductId productId = new ProductId(request.getParameter("id"));
doSomething(productId);


In an application written this way, the convention is that bare Strings are unverified and domain-specific types are verified (at least so far as syntax is concerned). This convention is enforced by the type-checker. When J. Random Coder comes along and writes yet another HTTP request handler, he or she will find that every relevant API takes a ProductId, and will probably complain about the silly programmers who wrote this API and went totally overboard with their do-nothing classes when a simple String would work fine, not even realizing that calling this silly constructor adds a security check.
Comments, code review, or unit testing can't give you the same guarantee because they all assume diligence on the part of the programmer. (Not that there's anything wrong with diligence, but there is a limited supply that we'd rather spend in other ways.) Taint-checking would do it (assuming reasonable test coverage) but we don't have that in Java. What we do have is a pretty good type system, so we might as well get it to do some work for us.
As an added bonus, when you introduce specific types for things, your code gets easier to read. For one thing, naming variables or methods "productId" becomes silly, because then you have:

// Do you think this code uses a product id?
ProductId productId = foo.getProductId();


Now that we have a type for it, we don't have to keep repeating to ourselves that this String is a product id, and so is this String, and this other method returns a String that is also a product id, and the third String argument in this method call is a product id, and so on and so forth. Those sort of naming schemes are for languages with weak type systems, not Java. We can use names for higher-level concepts:

ProductId itemToDisplay = foo.getSelection();

And if that's not enough reason to do it, your favorite IDE will become smarter. When it does method completion on a product id, no longer will it give you irrelevant String methods like toLowerCase() or replaceFirst(), things that nobody should want to do with a product id anyway. (Or if they really want to, they can call toString() first.) Now it will give you intelligent suggestions like getShard() or isISBN(), because ProductId becomes the logical place to put these methods instead of hiding them in some utility class somewhere. And when you get usages on a product id, the IDE will no longer show you every place a String is used (which is everywhere, which is a useless search result). Instead you'll see code that actually has something to do with product id's.

New to Java technology

alphaWorks provides emerging Java technologies for every skill level: learning the Java programming language, fine-tuning your skills, or using emerging technology components to speed development time as you innovate with your own applications. In addition, demos, discussion forums, and resources allow you to interact with creators of the technology and the broader user community.

1. What is Java technology?
Java technology is both an object-oriented programming language and a platform developed by Sun Microsystems. Java technology is based on the concept of a single Java virtual machine (JVM) -- a translator between the language and the underlying software and hardware. All implementations of the programming language must emulate the JVM, thus enabling Java programs to run on any system that has a version of the JVM. Learn more about Java technology from the developerWorks library of articles and tutorials.


2. Getting started with emerging Java technologies
Emerging Java technology is available in the following categories on alphaWorks:
APIs - Application Programming Interfaces are sets of classes, interfaces, and principles of operation that constitute a Java extension. They are scalable for use in domains ranging from first-party call control in a consumer device to third-party call control in large, distributed call centers.
Application Development - Application development resources vary from information for developers and software managers to tools and applications that provide time- and cost-effective foundations for solution development.
Components - Java components are self-contained elements of software that can be controlled dynamically and assembled to form applications.
Developer Kits - These include Software Development Kits for compiling and class files for coding Java.
IDEs - Integrated Development Environments (IDEs) use an editor pane to display source code and indicate the correct line. An IDE allows collaboration on projects using a platform of choice.
Reference Implementation - This category includes extended classes and code for adding to existing Java functionality.
Utilities – These are a large collection of useful tools for creating Java applications, including tools that parse numbers into integer, long, or double values, non-numerics, and string padding.


3. How can I improve my Java programming skills?
Various alphaWorks technologies can help you learn and improve your Java programming skills. If you’re a beginner, try out the following technologies: CodeRuler or CodeRally, both of which are programming games ideal for helping Java novices to become familiar with the Java programming language while competing in fun games.
If diagnostics and testing are what you are after, here are some popular alphaWorks technologies to try out on your applications:
Structural Analysis for Java, a technology that analyzes structural dependencies of Java applications in order to measure their stability.
Diagnostic Tool for Java Garbage Collector, A diagnostic tool for optimizing parameters affecting the garbage collector when using the IBM Java Virtual Machine.
HeapAnalyzer, which allows the finding of a possible Java heap leak area through its heuristic search engine and analysis of the Java heap dump in Java applications.
In addition, the developerWorks Java technology zone provides a wealth of resources about XML; these include articles, tutorials, and tips.
Browse through the numerous new Java technologies or search for a Java topic to find a technology of interest to you. You can also join the discussion about any alphaWorks technology in order to learn more. And let us know what you think; your feedback is important to us is shaping the alphaWorks site and what we bring you.

(Back track URL : http://www.alphaworks.ibm.com/java/newto#03)

Why employees leave organizations ? By Azim Premji , CEO- Wipro

Every company faces the problem of people leaving the company for better
pay or profile.

Early this year, Mark, a senior software designer, got an offer from a
prestigious international firm to work in its India operations
developing specialized software. He was thrilled by the offer.

He had heard a lot about the CEO. The salary was great. The company had
all the right systems in place employee-friendly human resources (HR)
policies, a spanking new office,and the very best technology,even a
canteen that served superb food.

Twice Mark was sent abroad for training. "My learning curve is the
sharpest it's ever been," he said soon after he joined.

Last week, less than eight months after he joined, Mark walked out of
the job.

Why did this talented employee leave ?

Arun quit for the same reason that drives many good people away.

The answer lies in one of the largest studies undertaken by the Gallup
Organization. The study surveyed over a million employees and 80,000
managers and was published in a book called "First Break All The Rules".
It came up with this surprising finding:

If you're losing good people, look to their immediate boss .Immediate
boss is the reason people stay and thrive in an organization. And he 's
the reason why people leave. When people leave they take
knowledge,experience and contacts with them, straight to the
competition.

"People leave managers not companies," write the authors Marcus
Buckingham and Curt Coffman.

Mostly manager drives people away?

HR experts say that of all the abuses, employees find humiliation the
most intolerable. The first time, an employee may not leave,but a
thought has been planted. The second time, that thought gets
strengthened. The third time, he looks for another job.

When people cannot retort openly in anger, they do so by passive
aggression. By digging their heels in and slowing down. By doing only
what they are told to do and no more. By omitting to give the boss
crucial information. Dev says: "If you work for a jerk, you basically
want to get him into trouble. You don 't have your heart and soul in the
job."

Different managers can stress out employees in different ways - by being
too controlling, too suspicious,too pushy, too critical, but they forget
that workers are not fixed assets, they are free agents. When this goes
on too long, an employee will quit - often over a trivial issue.

Talented men leave. Dead wood doesn't.

"Jack Welch of GE once said. A company's value lies "between the ears of
its employees".If it’s bleeding talent, it’s bleeding value.

Unfortunately, many senior executives busy traveling the world, signing new deals and developing a vision for the company, have little idea of what may be going on at home. That deep within an organization that otherwise does all the right things, one man could be driving its best people away.

10 security problems unique to IT By Jeff Relkin

Takeaway:
Organizations face a host of security concerns driven by the power of technology and the vulnerabilities inherent in its use. IT pros have to be vigilant about all these issues, from system penetration threats to hardware portability to employee turnover.

Security is not an area newly arisen in the wake of the 9/11 tragedy. There have always been reasons to be concerned: conflicting priorities, business environmental factors, information sensitivity, lack of controls on the Internet, ethical lapses, criminal activity, carelessness, and higher levels of connectivity and vulnerability. It's a tradeoff between limiting danger versus affecting productivity: 100 percent security equals 0 percent productivity, but 0 percent security doesn't equal 100 percent productivity.

No one wants to be controlled. It's demeaning and stifles productivity, and we resent the implication that we can't be trusted not to break our own networks. On the other hand, organizations have to decide how long they could operate without computers or networks and how reliant they are on the availability and accuracy of data. Absolute security is unattainable and undesirable, so proper security controls seek to reduce risk to acceptable levels.

#1: System penetration threats

There are all kinds of ways in which systems can be compromised. A popular expression during World War II was "Loose lips sink ships," which was meant in a possibly somewhat paranoid way to heighten awareness that you never knew who was listening to you, even over a beer at the local pub. Most of us routinely have contact with other professionals whether at industry gatherings, social events, or any number of other venues. It's all too easy to accidentally disclose critical information that can be used, however unethically or even illegally, to benefit one organization at the expense of another.

Carelessly discarding access codes and other kinds of personal identification information without shredding them has made dumpster diving the number one method of obtaining this kind of data. Systems that are poorly or inadequately secured (single-level security, easily guessed passwords, unencrypted data, etc.) are an invitation to problems ranging from low data quality to unauthorized infiltration.

Networks can be easily breached due to poorly maintained firewalls and/or virus and spam filters. Security budgets must be adequately funded; management literally puts organizational survival at risk by viewing funding for security measures as a no-return or discretionary expense. Taking responsibility for our own actions (or inactions) coupled with a solid comprehensive security policy is the best defense to prevent breaches from occuring in the first place.

#2: Internet security realities

Originally built for military use, the Internet today incorporates little inherent protection for information. Administrators at any Internet site can see packets flying by, and without adequate encryption, messages are subject to compromise. The Internet doesn't automatically protect organizational information--companies must do so independently. Without adequate control, and even with it, employees can access just about anything and bring it in-house. External intruders can access networks and PCs. External message sources typically can't be found, and message senders don't know who else, in addition to or instead of the intended recipient, is reading the message.

The hacking community is increasingly organized, and by cooperating with each other, networks can be even more easily, and profoundly, compromised. The Internet is an open, uncontrolled network that doesn't change to suit organizational needs. Identified exposures are not automatically fixed, and most security problems on the Internet are not really Internet problems. Organizations must assume a potentially hostile environment and protect themselves through full message encryption for sensitive information, digital signature for message authentication, high quality maintained firewalls and other filters, employee communication and awareness programs, and any inbound controls that are at least adequate without being excessive.

#3: Portability of hardware

Corporate road warriors traveling with laptops represent a variety of security challenges. Larger, faster hard drives and more powerful processors provide the ability to download and use local copies of sensitive or confidential databases. Ubiquitous Internet access allow us to stay connected with the same networks and systems we use in the office. Web-based services such as Groove can be used to circumvent corporate document policies.

Laptops need to be secured with at least two-phase security controls consisting of a combination of encryption, local userid/password combinations, biometric devices, etc., and organizations need to implement and enforce strict policies on technology use while traveling.

#4: Proliferation of new communication methods

Does your organization provide PDAs such as BlackBerrys or Treos with network connectivity? Are these devices secured in any way? Many companies have little understanding of just how big a security threat these handy little gizmos represent. Typically connected to central corporate services, such as Outlook or Notes, and providing continuous wireless automatic synchronization with e-mail, calendar, and contact lists, a lost device that's unsecured by a password can be used to gain authorized entry into those systems. At the very least, they can be used to run up a pretty impressive cell phone bill.

Corporations should require that despite the inconvenience, all such devices must have local passwords, subject to the same rules as those used to access the network, including format and frequency of change. They should also require by policy that lost devices be reported immediately so kill signals wiping all local data and rendering the device useless can be issued.

#5: Complexity of software

The fact that systems and applications have many integrated components that are difficult to individually secure is a poor excuse for not requiring multiple levels of security. Users who have been authenticated for general network access do not necessarily deserve authorization for specific functional components of that network or even within a single integrated environment, such as an ERP. Studies and surveys tell us that employees consider too many different passwords a valid reason for leaving an organization; some large corporations require users to memorize in excess of 15 userid/password combinations. Single sign-on techniques provide the ability to secure systems one component at a time on the basis of one individual access, so there's no reason to make security onerous to the user community.

#6: Degree of interconnection

This is just another form of complexity and requires a recognition of the realities of the public access Internet. Supply chain processes connect raw material providers, manufacturers, assemblers, and retailers. As the saying goes, a chain is only as strong as the weakest link. Even if individual organizations within the supply chain have proper security controls in place, one lapse by one of the partners can bring the entire operation to a halt.

Consider a situation in which a parts supplier's network is infiltrated and/or compromised. All the downstream component processes can be negatively affected, either by the delay or loss of a critical ingredient or by a contaminated input, in the same manner that a glitch at the start of an assembly line brings the entire operation to a screetching halt. Organizations need to conduct a comprehensive risk assessment and try to require their partners and suppliers to adhere to adequate security controls, or at the very least, develop contingencies around the possibility of losing access to critical partnerships.

#7: Density and accessibility of media

Information is currency, and knowledge is power. Knowing this, we're all responsible for maintaining the integrity and security of the corporate data to which we have authorized access. New forms of higher density portable media make it even more necessary to take this responsibility seriously. CDs, DVDs, flash drives, and other dense portable media are capable of storing multi-gigabytes of data in a form that all too often grows legs and walks away.

Corporate users should be circumspect about how they use these media. IT security policy should require that any data moved through USB ports or any other method of creating media do so on an encrypted basis. Policy, and common sense, should also dictate that these same media types never be used for single copies of any data, especially mission critical or business confidential, and limit their use to temporary movement of data from one location to another.

#8: Centralization

Single points of failure can be security nightmares. As important as it is to secure corporate networks, systems, and data, it's especially critical to do so when those assets are centrally located. Smaller organizations with limited technology resources are particularly vulnerable because they typically have one LAN room or one server rack, which is the entire network for the whole organization.

Unauthorized access, power problems, communications glitches, protocol incompatibilities, and questionable system philosophies can all contribute to catastrophic consequences. When technology assets are centralized either as a result of limited resources or simply due to a valid design consideration, attention must be given to special security requirements to ensure continuous operation.

#9: Decentralization

The opposite situation comes with security considerations of its own. Multiple copies of individual systems or databases all must be equally well secured; one compromised copy renders the entire application suspect. One of the more difficult situations to deal with in global organizations with presences in various countries occurs where Internet access is neither robust, consistent, nor reliable. In this case, the best solution is often to install a distributed DNS server for offline synch with the main corporate network, providing a local facility that while not real time, is at least a comprehensive copy no more than one half day old of necessary data. Since this requires putting sensitive or confidential information out into the field, policies and procedures must be enforced that provide the same level of security for the decentralized facility as that for the main corporate network to avoid the same risks of infiltation and compromise.

#10: Turnover

Employees changing jobs represent a particularly difficult security challenge. A generation ago, you'd simply turn in your keys and go on with your life, but it's not so easy to do that when the keys are virtual entries into secure systems.

Every access granted to individual employees has to be tracked so that at departure time, those accesses can be turned off. In some cases, security systems will have to be cycled for everyone remaining with an organization when a key employee having a deep level of access goes elsewhere.

Jeff Relkin has 30+ years of technology-based experience at several Fortune 500 corporations as a developer, consultant, and manager. He has also been an adjunct professor in the master's program at Manhattanville College. At present, he's the CIO of the Millennium Challenge Corporation (MCC), a federal government agency located in Washington, DC. The views expressed in this article do not necessarily represent the views of MCC or the United States of America.

(http://articles.techrepublic.com.com/5102-1009-6112847.html)

Thread Dump JSP in Java 5 by Dr. Heinz M. Kabutz (JDK version: JDK 1.5 )

Abstract:
Sometimes it is useful to have a look at what the threads are doing in a light weight fashion in order to discover tricky bugs and bottlenecks. Ideally this should not disturb the performance of the running system. In addition, it should be universally usable and cost nothing. Have a look at how we do it in this newsletter.

Thread Dump JSP in Java 5

Ten days ago, I received a desperate phone call from a large company in Cape Town. Their Java system tended to become unstable after some time, and especially during peak periods. Since the users were processing millions of dollars on this system, they should be able to log in at any time.

We managed to solve their problem. As you probably guessed, it was due to incorrectly handled concurrency. I cannot divulge how we find such problems or how to fix it, that is our competitive advantage. Contact me offlist [http://www.javaspecialists.co.za/contact.jsp] if your company has bugs or performance issues that you cannot solve and where an extra pair of eyes can be useful.

One of the measurements we looked at was to inspect what the threads were doing. In this case, it did not reveal much, but it can be of great value in finding other issues. For example, at another customer, we stumbled upon an infinite loop by looking at what the threads were up to.

There are several ways of doing that. If you are using Unix, you can send a "kill -3" to the process. With Windows, CTRL+Break on the console will give you that information.

This server was running on Windows (don't laugh). The application server did not allow us to start the JVM in a console window, which meant that we could not press CTRL+Break.

Another approach would have been to painstakingly step through the threads with JConsole. That was not an option to me.

One of the annoying parts of the typical thread dump is that the threads are not sorted, so it becomes a bit tricky to group them. It would also be nice to see a summary of the state in a table, to make it easier to find problems. In addition, we should be able to copy the text and diff it to see how things change between refreshes.

In good OO fashion, we separate model and view. Let's first define the model:

package com.cretesoft.tjsn.performance;

import java.io.Serializable;
import java.util.*;

public class ThreadDumpBean implements Serializable {
private final Map traces;

public ThreadDumpBean() {
traces = new TreeMap(THREAD_COMP);
traces.putAll(Thread.getAllStackTraces());
}

public Collection getThreads() {
return traces.keySet();
}

public Map getTraces() {
return traces;
}

/**
* Compare the threads by name and id.
*/
private static final Comparator THREAD_COMP =
new Comparator() {
  public int compare(Thread o1, Thread o2) {
    int result = o1.getName().compareTo(o2.getName());
    if (result == 0) {
      Long id1 = o1.getId();
      Long id2 = o2.getId();
      return id1.compareTo(id2);
    }
    return result;
  }
};
}

We also write a bit of JSP, making use of the Expression Language ${}.

    <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

Thread Summary:







  






  
Thread
  
State
  
Priority
  
Daemon
    
${thr.name}




    
${thr.state}




    
${thr.priority}




    
${thr.daemon}




  

Stack Trace of JVM:
${trace.key}
       at ${traceline} 

This will generate first a summary of the threads with hyperlinks to the individual stack traces. The summary shows the state of each thread.

Have a look at a sample snapshot [http://www.javaspecialists.co.za/samples/sample.htm(l)] .

A word of warning: you should not make this JSP page publicly accessible on your server, as it opens up the guts of the app server to the general population. Even if they cannot change the state of the threads, it might be bad enough for them to see what methods are being executed.

You might have to change the GET_STACK_TRACE_PERMISSION setting to allow yourself access into the application server.

This is a took that I will keep handy whenever I do performance tuning or difficult bug fixing on a J2EE server running Java 5.

I look forward to hearing from you how you expanded this idea to make it even more useful :)

For those of you lucky enough to be at the JavaZone conference this week, do come and say "hi" to me :) It would be great to meet you.

Kind regards

Heinz

(http://www.javaspecialists.co.za/archive/newsletter.do?issue=132&print=yes&locale=en_US)