imaya Munusamy

The difference is mainly because of cost extra method calls checkForComodification() and get(). method calls has to do some work to set up stack frame and return value to caller

it you implement your own implementation avoiding this methos then it 'll be same as enumaration.

public Object next() {
//checkForComodification(); --comment

try {
//replace the get method with the get method implementation directly
//Object next = get(cursor);
/*****get method implementation start ******/
if (cursor >= elementCount)
throw new ArrayIndexOutOfBoundsException(cursor);

Object next = elementData[cursor];
/*****get method implementation end ******/

lastRet = cursor++;
return next;
} catch (IndexOutOfBoundsException e) {
checkForComodification();
throw new NoSuchElementException();
}

Hi i am learning Struts2, I am not able to find any article or book to integrate Struts2, Velocity and tile. can some one suggest where i can find it.

you can try Base64 Encryption. this encryption is used in mail attachments.

There is semicolon at the end of every "if" statement so the indCost = value; is not part of the if block.

Originally posted by John Todd:
Yes but Timestamp class contains the nano second part which java.util.Date doesn't handle it.
When I'm trying to display the converted Date object (according to my previous posted code), I got:
date info .. 00:00:00 ...
Obviously, I lost the time.

When you convert from timestamp to date, time will not be lost. the problem might be when you get date from database it might truncate time.

see the below eg:

the long value of timestamp, util.date, sql.date will be same. only when it is printed it will be printed in different way. but you are converting into util.date so will not loose time only nano sec. will not come

Timestamp st = new Timestamp(System.currentTimeMillis());
java.util.Date date1 = new java.util.Date(st.getTime());
java.sql.Date date2 = new java.sql.Date(st.getTime());

System.out.println(st); print date,Time, nano sec
System.out.println(date1); print date, time
System.out.println(date2); print date

Originally posted by rahul dravid:
If I use select statement than what happens?

It will return ResultSet Object but the ResultSet.next() method will return false

Originally posted by Campbell Ritchie:
That's a good idea, Joanne.

And Imama, I have told you, you might not agree with the decision to use the Object implementation. I don't myself, but I think we are stuck with it. I have looked on the lists of requests and bugs at Sun, and this has come up before and they are sticking by their decision. So we are stuck with it!

campbell, Thankx for your clarification

Originally posted by Campbell Ritchie:
But equals() IS implemented in StringBuilder; it isnot overridden. We have already told you why it isn't overridden, and I have told you a workaround. Because StringBuilder is expected to change rapidly. You might not agree with that, but that it the reason.

Yea Campbell you are right, i couldn't convince with this reason. Any method of class going to operate on current state of the object. equals also do the same thing. using equal method we are checking whether the state of two objects are same or not at that time. doesn't matter whether it 'll change or not in future.

if the state of the object changes then next time when we call the method its going to give different value.

For Eg: ArrayList class has implemented equals method. i guess ArrayList values may change more often than Stringbuffer . if that is the reason then it should not have been implemented in ArrayList also.

sorry Paul,
i didn't read your message properly. it will not break. it works as per javadoc.

Jim,
there is no good reason to use Stringbuffer as key. but my first question is still remains...what is the reason that the equal method is not implemented in that class.

Originally posted by Paul Sturrock:


No, it won't. The Map will work as expected. It will match based on the equals() method defines in the Object class. If you were expecting it to work based on the value this would be a misreading of the JavaDocs on your part.

It will definitely break if you use StringBuffer as key because the equal method is not implemented in the class it uses Object class equal method.



HashMap first check hash code to identify bucket then it uses equal method to identify the object from the bucket. as the equal method is not implemented it will call super class (object class) equal method. object class equal method check only memory address of object (obj1 == obj2) . if the StringBuffer we put initially and the one we used to get again are different object it will return null.


see the below eg:

HashMap hm = new HashMap();

StringBuffer sb1 = new StringBuffer("key1");
StringBuffer sb2 = new StringBuffer("key2");

hm.put(sb1 , "value1");
hm.put(sb2 , "value2");

//This will return null
System.out.println("Value = " + hm.get( new StringBuffer("key1")) );

//this will return value1 as we are using same object to retrive
System.out.println("Value = " + hm.get( sb1) );

Changing value of key will affect in hashMap but that has to be taken care by developer. this should not be the reason for not implementing equal method in StringBuffer class.

Originally posted by Campbell Ritchie:
The explanation is that StringBuilder and StringBuffer are expected to change their values repeatedly, so equality based on content would change.

You can always say
if (builder.toString().equals(otherBuilder.toString())) . . .

In case of if condition we can check like this but if you use Stringbuffer as key in HashMap it will break

hi Jim ,

do you mean we should use only immutable object in Hashmap or Hashset? lot of time we 'll use our custom class (Eg: Student.class) objects as key in hashmap which is mutable which can be modified even after put in collection. developer has to take care of this.



this shouldn't be the reason for not implementing equals in Stringbuffer

I couldn't imagin any reason why Stringbuffer has not implemented equals method....it will break if we use String buffer in HashMap or HashSet.. can some one explain it

Originally posted by Joanne Neal:
You can find the source code for the Java API classes in a file called src.zip in your JDK installation directory. Have a look at the code for the String class and you will get the answer.

I couldn't imagin any reason why Stringbuffer has not implemented equals method....it will break if we use String buffer in HashMap or HashSet.. can some one explain it