Monday, September 29, 2003

public class Mod{
public static void main(String argv[]){
}
public static native void amethod();
}
=========================================================

This will be compiled and Executed...

Here the method is declared as native.The native key word alerts the

compiler that the method will be defined externally.Native methods will not

conatin any coding in Java language.

This code will compile and run with out any error.But if you try to use the

method in another class,during run time it will throw

exception "UnsatisfiedLinkError",since JVM doesn't know how to find

aMethod().

So before using native methods,load the library file containg the method

definition for aMethod()developed in a language other than Java like C/C++.

You can do this by System.loadLibrary("moose.dll");

Sunday, September 28, 2003

http://java.sun.com/features/2003/05/bloch_qa.html New Language Features for Ease of Development in the Java 2 Platform, Standard Edition 1.5: A Conversation with Joshua Bloch

INTERFACES AND CONSTANTS

When you want to use global constants in an application, it is often tempting to define the constants in an interface and then implement the interface in the class using the constants. For example, suppose you have the following interface that contains approximations for the numbers pi and e.

public interface TranscendentalConstants {
public static final double PI = 3.14159;
public static final double E = 2.71828;
}

Suppose too that you have a second collection of constants that contains approximations for the square roots of two and three.

public interface IrrationalConstants {
public static final double SQRT_TWO = 1.414;
public static final double SQRT_THREE = 1.732;
}

A common strategy for using these constants is to create a class like the following.

public class BadUseOfConstants implements
TranscendentalConstants, IrrationalConstants {

public double sinPiOverFour(){
return SQRT_TWO / 2;
}

public double sinPiOverThree(){
return SQRT_THREE / 2;
}

private void outputResults() {
System.out.println("Pi is approximately " + PI);
System.out.println(
"The sin of Pi/4 is approximately " +
sinPiOverFour());
System.out.println(
"The sin of Pi/3 is approximately " +
sinPiOverThree());
}

public static void main(String[] args) {
new BadUseOfConstants().outputResults();
}
}

Even though this code runs, it is an improper use of interfaces. That's because BadUseOfConstants is not an extension of the type TranscendentalConstants. Instead, BadUseOfConstants is a consumer of TranscendentalConstants. There are two reasons why using interfaces in this way is so attractive. First, you can easily use constants defined in two different interfaces. If the constants were used in different classes instead, multiple inheritance would be required to perform the same task. Second, by implementing the interfaces, you can refer to the constants without qualifying them as SQRT_TWO instead of as IrrationalConstants.SQRT_TWO.

You can address this second problem of having to qualify constants by caching the variables locally like this.

public class OKUseOfConstants {

private double PI = TranscendentalConstants.PI;
private double SQRT_TWO =
IrrationalConstants.SQRT_TWO;
private double SQRT_THREE =
IrrationalConstants.SQRT_THREE;

public double sinPiOverFour() {
return SQRT_TWO / 2;
}

public double sinPiOverThree() {
return SQRT_THREE / 2;
}

public void outputResults() {
System.out.println("Pi is approximately " + PI);
System.out.println(
"The sin of Pi/4 is approximately " +
sinPiOverFour());
System.out.println(
"The sin of Pi/3 is approximately " +
sinPiOverThree());
}

public static void main(String[] args) {
new OKUseOfConstants().outputResults();
}
}

When J2SE 1.5 is released, a new mechanism for importing specific constants will be introduced that will address both of these issues. In the meantime, you might want to introduce an inner class or a different class that collects all of the interfaces containing the constants you want to use. Here's an example. In the BetterUseOfConstants program that follows, the inner class ConstantCollector is used to collect the constants declared in TranscendentalConstants and IrrationalConstants.

public class BetterUseOfConstants {

private ConstantCollector constants =
new ConstantCollector();

public double sinPiOverFour(){
return constants.SQRT_TWO / 2;
}

public double sinPiOverThree(){
return constants.SQRT_THREE / 2;
}

private void outputResults() {
System.out.println(
"Pi is approximately " +
constants.PI);
System.out.println(
"The sin of Pi/4 is approximately " +
sinPiOverFour());
System.out.println(
"The sin of Pi/3 is approximately " +
sinPiOverThree());
}

public static void main(String[] args) {
new BetterUseOfConstants().outputResults();
}

private class ConstantCollector implements
TranscendentalConstants, IrrationalConstants{}
}

Running this code should produce the following results:

Pi is approximately 3.14159
The sin of Pi/4 is approximately 0.707
The sin of Pi/3 is approximately 0.866

In this case ConstantCollector is a type extension of the two interfaces.

Friday, September 26, 2003

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler

The greater the difficulty,the more the glory in surmounting it.

http://patterndigest.com/ A good URL for Patterns

Monday, September 22, 2003

Understanding that parameters are passed by value and not by reference

common misconception exists that parameters in Java are passed by reference. They are not. Parameters are passed by value. The misconception arises from the fact that all object variables are object references. This leads to some unexpected results if you do not understand exactly what is happening. For example:



import java.awt.Point;
class PassByValue
{
public static void modifyPoint(Point pt, int j)
{
pt.setLocation(5,5); //1
j = 15;
System.out.println("During modifyPoint " + "pt = " + pt +
" and j = " + j);
}
public static void main(String args[])
{
Point p = new Point(0,0); //2
int i = 10;
System.out.println("Before modifyPoint " + "p = " + p +
" and i = " + i);
modifyPoint(p, i); //3
System.out.println("After modifyPoint " + "p = " + p +
" and i = " + i);

}
}



This code creates a Point object, initialized to (0,0) , and assigns it to the object reference variable p at //2. It then assigns the primitive int i the value 10 . The static modifyPoint method is then called at //3, passing p and i. The modifyPoint method calls the setLocation method on the first parameter, pt , changing its location to (5,5) . In addition, the second parameter, j , is assigned the value 15. When the modifyPoint method returns, method main prints the values for p and i . What is the output of this code and why?

The output of this code is as follows:



Before modifyPoint p = java.awt.Point[x=0,y=0] and i = 10
During modifyPoint pt = java.awt.Point[x=5,y=5] and j = 15
After modifyPoint p = java.awt.Point[x=5,y=5] and i = 10




This output shows that the modifyPoint method changed the Point object created at //2 but not the int,i . In main , i is assigned the value 10. Parameters are passed by value, therefore, a copy of i is passed to the modifyPoint method. This method changes the value of the copy to 15 and returns. The original value, i in main , is not changed.

On the other hand, you might think the Point object created at //2 is unmodified by the modifyPoint method. After all, Java passes parameters by value. Therefore, when modifyPoint is called with the Point object created at //2, a copy is made for the modifyPoint method to work with. Changes to the Point object in modifyPoint are not reflected in main because there are two different objects. Right? Wrong.

Actually, the modifyPoint method is working with a copy of a reference to the Point object, not a copy of the Point object. Remember that p is an object reference and that Java passes parameters by value. More specifically, Java passes object references by value. When p is passed from main to the modifyPoint method, a copy of the value of p, the reference, is passed. Therefore the modifyPoint method is working with the same object but through the alias, pt . After entering the modifyPoint method, but before the execution of the code at //1, the object looks like this:

Figure 1


Therefore, after the code at //1 is executed, the Point object has changed to (5,5) . What if you want to disallow changes to the Point object in methods such as modifyPoint ? There are two solutions for this:

Pass a clone of the Point object to the modifyPoint method.
Make the Point object immutable.


Understand that for instance methods, synchronized locks objects, not methods or code

The synchronized keyword is used as either a method modifier or as a statement inside of a method. This dual usage causes some confusion about exactly what the synchronized keyword does. It is often described in terms of mutual exclusion (mutex) or a critical section. This causes many programmers to incorrectly think that because code is protected by synchronized , it can be accessed by only one thread at a time.

For instance methods, the synchronized keyword does not lock a method or code; it locks objects. Remember that there is only one lock associated with each object.

When synchronized is used as a method modifier, the lock obtained is that for the object on which the method was invoked.When it is used on an object refer-ence, the lock obtained is that for the object referred to. For example, consider the following code:

class Test
{
public synchronized void method1()
{
//...
}

public void method2()
{
synchronized(this) {
//...
}
}

public void method3(SomeObject someObj)
{
//...
synchronized(someObj) {
//...
}
}
}


The first two methods, method1 and method2 , are functionally identical regarding the object being locked. (They differ in the amount of code generated and in how they perform.) Both methods are synchronized on this . In other words, a lock is obtained for the object on which the method was invoked. Because both methods are of the class Test , the lock is obtained for an object of class Test . The method3 method is synchronized on the object referenced by someObj .

What exactly does it mean to synchronize on an object? It means that the thread that invoked the method has that object s lock. To hold an object s lock means another thread requesting a lock for the same object through a synchronized method or a synchronized statement cannot obtain that lock until it is released. However, another thread executing the same synchronized method or block on a different instance of the same class can obtain that instance s lock.

Thus, code in a synchronized method or block can be executed at the same time by multiple threads if the method is invoked on two different objects. For example, consider the following code:


class Foo extends Thread
{
private int val;
public Foo(int v)
{
val = v;
}

public synchronized void printVal(int v)
{
while(true)
System.out.println(v);
}

public void run()
{
printVal(val);
}
}
class Bar extends Thread
{
private Foo sameFoo;
public Bar(Foo f)
{
sameFoo = f;
}
public void run()
{
sameFoo.printVal(2);
}
}

class Test
{
public static void main(String args[])
{
Foo f1 = new Foo(1);
f1.start();
Bar b = new Bar(f1);
b.start();
Foo f2 = new Foo(3);
f2.start();
}
}


Class Foo contains a synchronized method, printVal . This method is executed by three different threads. You might think that because printVal is declared synchronized , it is executed by only one thread at a time. However, this code demonstrates that even though the printVal method is declared synchronized , it can be executed by multiple threads concurrently. Running this code generates output of the form:


1
1
1
1
3
3
3
3
1
1
1
3
3
3


What might be surprising is the interleaved execution of two of the threads. If only one thread could execute a synchronized method at a time, you would never see interleaved output. In fact, what happens is the code that prints the 1 s and 3 s is executing the printVal method concurrently. Examining this code shows why this happens.

An object of the class Foo , referenced by f1 , is created, passing the value 1, and then run on another thread. The run method of class Foo is called, which then calls the synchronized printVal method. When the printVal method is entered, it has obtained the lock for the Foo object. It then begins printing the value 1. Because it has entered an infinite loop, the lock for this Foo object is never released.

Then an object of type Bar , referenced by b , is created, passing the same Foo object currently in use. It is run on another thread and calls the same printVal method, with the value 2, on the same Foo object. Because the printVal method is synchronized , this call attempts to obtain the lock for the object on which the method is called. The printVal method is called on the same Foo object as the previous invocation, so this call blocks until the first execution of the printVal method is finished. Because the first thread holds this lock and is in an infinite loop, the code never outputs both a 1 and a 2. The first thread to obtain the lock blocks out the other thread forever. Therefore, you do not see any interleaved execution of these two invocations of the printVal method.

Finally, a second object of the Foo class, referenced by f2 , is created, passing the value 3, and then run on a third thread. The run method of class Foo is called, which then calls the synchronized printVal method. When that method is called, it attempts to obtain the lock for the object on which it is called. The attempt to get this lock succeeds regardless of whether the thread for f1 or b still holds a lock. Because this invocation of the printVal method is called on a different object, it can obtain that object s lock.

Thus, you can see interleaved execution between the threads for f1 and f2 , but never between the threads for b and f1 . The threads for f1 and f2 operate on unique objects and therefore are not affected by the synchronized keyword. The threads for f1 and b , however, operate on the same Foo object and therefore must synchronize on its lock.

Remember that synchronization locks objects, not methods or code. Simply because a method, or section of code, is declared synchronized does not necessarily mean it is executed by only one thread at a time. This is important if the code in the synchronized method or block alters a mutually shared resource.

If the code alters an instance variable of the object, no problem results. In the previous example, f1 and f2 are two distinct objects and therefore contain two distinct instance variables. If the printVal method alters the instance variable val , then the code works as expected without conflict because the threads for f1 and f2 alter different data. However, if the printVal method shares some other non-object resource, such as a static variable, a conflict might result. In this case, you must synchronize on a mutually shared object in order to prevent conflicts.

One final note about the synchronized keyword. The Java language does not allow constructors to be declared synchronized . (A compiler error is generated if the synchronized keyword is present on a constructor declaration.) This is because two threads that call the same constructor concurrently operate on two distinct pieces of memory for two distinct instances of the same class. However, if these constructors contain code that contends for a mutually shared resource, you must synchronize on that resource in order to avoid conflicts.

Friday, September 19, 2003

Enable-AutoComplete Feature In Command Line


change registry by using regedit. If you have XP you can do this also by using powertoys (tweakxp)

HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Command Processor

Right click on CompletionChar
DWORD change that to 9

restart and you are done. Pressing tab in the command line can complete the next match of the command that you are typing.

The Java language does not allow constructors to be declared synchronized . (A compiler error is generated if the synchronized keyword is present on a constructor declaration.) This is because two threads that call the same constructor concurrently operate on two distinct pieces of memory for two distinct instances of the same class. However, if these constructors contain code that contends for a mutually shared resource, you must synchronize on that resource in order to avoid conflicts.

http://www-106.ibm.com/developerworks/java/library/j-praxis/pr46.html Understand that for instance methods, synchronized locks objects, not methods or code.

Wednesday, September 10, 2003

"He who controls vocabulary controls thought" - Luigi Wittgenstein

Monday, September 08, 2003

http://books.wontstop.com/ Good E-Books on .NET

javacoder.net the on-line resource for Java(tm) coders. http://javacoder.net/