Java SE 8, @Deprecated public String getText() wrote:For security reasons, this method is deprecated. Use the * getPassword method instead.
Java SE 8, getPassword() wrote:For stronger security, it is recommended that the returned character array be cleared after use by setting each character to zero.
If anybody gains access to your computer directly or indirectly they can probably do a memory dump and find the password.Ganesh Patekar wrote:. . . Is there anyway to access that String which is in heap and referred only by String literal pool? . . .
Fred Kleinschmidt wrote:
What you should store is the encrypted value of the password. Then when the user types in the password, encrypt it and compare to the stored encryption
That's what I was actually looking for, I know It may not be that necessary but I adore to verify it If possible, so Is there any way I can verify that practly by writing code or using some tools?Campbell Ritchie wrote:
If anybody gains access to your computer directly or indirectly they can probably do a memory dump and find the password.Ganesh Patekar wrote:. . . Is there anyway to access that String which is in heap and referred only by String literal pool? . . .
I think hashing is used to store particular group of values into same place which are having same hashcode so while searching a value it will be easier to find that value into a particular group having same hashcode as value which we are searching for, so rather comparing that value with each value. IMO hashing is one way process means once you calculate hash code of a value then by using that hascode you can't get original value because two different values may also have same hash code.Dave Tolls wrote:They should be hashed (using appropriate techniques), not encrypted.
public int hashCode() method returns the hash code value as an integer. This integer need not remain consistent from one execution of an application to another execution of the same application.
Equal objects must produce the same hash code as long as they are equal, however unequal objects need not produce distinct hash codes.
I think hashing is used to store particular group of values into same place which are having same hashcode so while searching a value it will be easier to find that value into a particular group having same hashcode as value which we are searching for, so rather comparing that value with each value. IMO hashing is one way process means once you calculate hash code of a value then by using that hascode you can't get original value because two different values may also have same hash code.Dave Tolls wrote:They should be hashed (using appropriate techniques), not encrypted.
public int hashCode() method returns the hash code value as an integer. This integer need not remain consistent from one execution of an application to another execution of the same application.
Equal objects must produce the same hash code as long as they are equal, however unequal objects need not produce distinct hash codes.
This line confusing me. It means If I get hash code "1234" for password "abcd" then next time when user try to login and provides password "abcd" then it is not guarantee that has code produced this time will be same as previous one i.e. 1234 which was stored in database during user's registeration.This integer need not remain consistent from one execution of an application to another execution of the same application.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
That means that whenever somebody finds that using 2047 as a prime number multiplicand instead of 31 in the Objects#hash() method, and they change the algorithm in Java13, it will still fulfil the requirements of its general contract. Serialised old hash maps might not work, but that is a different problem.Stephan van Hulst wrote:The hash that you get from the hashCode() method is not the same as a cryptographic hash. It's only intended to be used to implement hash tables. . . .
The video talks about recent tutorials, so I went to look for dates. It said, Published on 20 Nov 2013.fred rosenberger wrote:I found this very interesting to watch. . . .
Ganesh Patekar wrote:But when user 1 try to login and enters password "ABC" how does this check whether entered password matches to password which is in database?
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
Stephan van Hulst wrote:There's a link to a page that will show you instance counts of classes (including platform classes). Then you click the link to String instances. Then the password you entered will be among the instances listed, if it hasn't been garbage collected yet.
do you mean they store separate salt value of password entered by use during registeration and plus has code of that password?Dave Tolls wrote:Anyway, when the user logs in what happens is the password is salted using the salt value in the db for that user and then against the hash generated.
Ganesh Patekar wrote:Does that mean "JAVA" has been GC?
Will you please tell me exactly where you found that link I mean under which titles or subtitles? I searched a lot for that but couldn't found so tried with VisulVm.Joe Bishara wrote:Using jhat (not VisualVm), I found the String object in the heap dump even after setting its reference to null.
P.S.
Setting an object's reference to null makes the object eligible for GC (if it is no longer referenced); however there is no guarantee that an object that is eligible for garbage collection will be garbage collected because you never know when the garbage collector will run.
Strings, Literally by Corey McGlone wrote:Just before the main method ends, how many objects are available for garbage collection? 0? 1? 2?
The answer is 1. Unlike most objects, String literals always have a reference to them from the String Literal Pool. That means that they always have a reference to them and are, therefore, not eligible for garbage collection. This is the same example as I used above so you can see what our picture looked liked originally there. Once we assign our variables, one and two, to null, we end up with a picture that looks like this:
Ganesh Patekar wrote:Will you please tell me exactly where you found that link I mean under which titles or subtitles? I searched a lot for that but couldn't found so tried with VisulVm.
Stephan van Hulst wrote:There's a link to a page that will show you instance counts of classes (including platform classes). Then you click the link to String instances. Then the password you entered will be among the instances listed, if it hasn't been garbage collected yet.
Ganesh Patekar wrote:But here Strings, Literally by Corey McGlone says...
Ganesh Patekar wrote:Does that mean "JAVA" has been GC?
This is what I wanted to confirm.Joe Bishara wrote:String literals are never eligible for GC while a program is running because they are always referenced.
Stephan van Hulst wrote:If an object is created inside a method call, and a reference to that object doesn't escape the method, then the object may live on the stack rather than the heap and will be 'collected' automatically when the method call finishes.
Yes that is NoEscape state, one of the three possible escape states of an object.Stephan van Hulst wrote:If an object is created inside a method call, and a reference to that object doesn't escape the method, then the object may live on the stack rather than the heap and will be 'collected' automatically when the method call finishes. Because String literals refer to objects that are outside the method (in the String pool), they can't live on the stack.
Java SE 8 doc wrote:Escape analysis is a technique by which the Java Hotspot Server Compiler can analyze the scope of a new object's uses and decide whether to allocate it on the Java heap.
Escape analysis is supported and enabled by default in Java SE 6u23 and later.
I also think so.Campbell Ritchie wrote:You don't need to know about such optimisations to write good programs, however.
When the JVM loads a class, it checks all String literals (and String compile‑time constants). If two String literals have the same contents (i.e. string1.equals(string2) returns true), they are interned. If they both have the same content, they are converted to the same object in the String pool.Ganesh Patekar wrote:. . . I think if both are not at same location then strOne == strTwo should return false. Why It is returning true?
Ganesh Patekar wrote:When method compareStrings gets invoked then strTwo String object will be created in the frame of compareStrings method on stack...
Stephan van Hulst wrote:Because String literals refer to objects that are outside the method (in the String pool), they can't live on the stack.