Recent articles:
Popular archives:
Java: A platform for platforms
Sun's reorg may seem promising to shareholders but it's also a scramble for position. The question now is whether Sun can,
or wants to, maintain its hold on Java technology. Especially with enterprise leaders like SpringSource and RedHat investing
heavily in Java's future as a platform for platforms
Also see:
Discuss: Tim Bray on 'What Sun Should Do'
his Q&A is a bit different in that I'm going to tackle four quick questions in one swoop. We'll look at green versus native
threads, Class.forName(), returning multiple values from a method, and shallow copying. So, let's get to it.
Question: What is the difference between green threads and native threads?
Answer: Green threads, the threads provided by the JVM, run at the user level, meaning that the JVM creates and schedules the threads itself. Therefore, the operating system kernel doesn't create or schedule them. Instead, the underlying OS sees the JVM only as one thread.
Green threads prove inefficient for a number of reasons. Foremost, green threads cannot take advantage of a multiprocessor system. Since the JVM simply runs from within one thread, the threads that the JVM creates are not threads at the OS level. Instead, the JVM splits its timeslice among the various threads that it spawns internally. Thus, the JVM threads are bound to run within that single JVM thread that runs inside a single processor.
In contrast, native threads are created and scheduled by the underlying operating system. Rather than create and schedule threads itself, the JVM creates the threads by calling OS-level APIs. As a result, native threads can benefit from multiple processors. Performance can improve because an IO-blocked thread will no longer block the entire JVM. The block will only block the thread waiting for the IO resource.
There are times when you might want to run green threads. First, native threads are not always available. Second, if your code is not thread-safe, you may experience errors when running native threads.
Question: What exactly does the Class.forName(); statement do? Why is this construct encountered only with JDBC? (I have not seen any code that uses Class.forName() in other contexts.) Answer: Every object has a corresponding class object. This class object instance is shared among all instances of that class type.
Class.forName() loads and returns the class object for the given class name. So, for example, if you write:
Class object = Class.forName("java.io.FileNotFoundException");
the JVM will load and return the class object for FileNotFoundException. Class objects play an important role in reflection. For example, you may call:
try
{
Class object = Class.forName("java.io.FileNotFoundException");
Object ex = object.newInstance();
}
catch (ClassNotFoundException ex) {}
catch (InstantiationException ex) {}
catch (IllegalAccessException ex) {}
In the example above, newInstance() goes out and instantiates an object for class if it has a no arguments constructor. You can also use the class object to
obtain field, method, and interface information.
The example given above is a bit contrived. However, let's say you define an interface that provides a proxy to some backend server. Your program knows how to manipulate the interface; it does not, however, know which interface implementation to instantiate at compile time. Instead, you provide that class name as a command line argument. Your program can use reflection to go out and instantiate that object.