Class Object

public Object()

The basic constructor. Object is special, because it has no superclass, so there is no call to super().

protected Object clone()
            throws CloneNotSupportedException

This method may be called to create a new copy of the Object. The typical behavior is as follows:

• o == o.clone() is false
• o.getClass() == o.clone().getClass() is true
• o.equals(o) is true

However, these are not strict requirements, and may be violated if necessary. Of the three requirements, the last is the most commonly violated, particularly if the subclass does not override equals(Object).

If the Object you call clone() on does not implement Cloneable (which is a placeholder interface), then a CloneNotSupportedException is thrown. Notice that Object does not implement Cloneable; this method exists as a convenience for subclasses that do.

Object's implementation of clone allocates space for the new Object using the correct class, without calling any constructors, and then fills in all of the new field values with the old field values. Thus, it is a shallow copy. However, subclasses are permitted to make a deep copy.

All array types implement Cloneable, and override this method as follows (it should never fail):

 public Object clone()
 {
   try
     {
       super.clone();
     }
   catch (CloneNotSupportedException e)
     {
       throw new InternalError(e.getMessage());
     }
 }
 

Returns:

a copy of the Object

Throws:

CloneNotSupportedException - If this Object does not implement Cloneable

See Also:

Cloneable

public boolean equals(Object obj)

Determine whether this Object is semantically equal to another Object.

There are some fairly strict requirements on this method which subclasses must follow:

• It must be transitive. If a.equals(b) and b.equals(c), then a.equals(c) must be true as well.
• It must be symmetric. a.equals(b) and b.equals(a) must have the same value.
• It must be reflexive. a.equals(a) must always be true.
• It must be consistent. Whichever value a.equals(b) returns on the first invocation must be the value returned on all later invocations.
• a.equals(null) must be false.
• It must be consistent with hashCode(). That is, a.equals(b) must imply a.hashCode() == b.hashCode(). The reverse is not true; two objects that are not equal may have the same hashcode, but that has the potential to harm hashing performance.

This is typically overridden to throw a ClassCastException if the argument is not comparable to the class performing the comparison, but that is not a requirement. It is legal for a.equals(b) to be true even though a.getClass() != b.getClass(). Also, it is typical to never cause a NullPointerException.

In general, the Collections API (java.util) use the equals method rather than the == operator to compare objects. However, IdentityHashMap is an exception to this rule, for its own good reasons.

The default implementation returns this == o.

Parameters:

obj - the Object to compare to

Returns:

whether this Object is semantically equal to another

See Also:

hashCode()

public final Classextends Object> getClass()

Returns the runtime Class of this Object.

The class object can also be obtained without a runtime instance by using the class literal, as in: Foo.class. Notice that the class literal also works on primitive types, making it useful for reflection purposes.

Returns:

the class of this Object

protected void finalize()
            throws Throwable

Called on an object by the Virtual Machine at most once, at some point after the Object is determined unreachable but before it is destroyed. You would think that this means it eventually is called on every Object, but this is not necessarily the case. If execution terminates abnormally, garbage collection does not always happen. Thus you cannot rely on this method to always work. For finer control over garbage collection, use references from the java.lang.ref package.

Virtual Machines are free to not call this method if they can determine that it does nothing important; for example, if your class extends Object and overrides finalize to do simply super.finalize().

finalize() will be called by a Thread that has no locks on any Objects, and may be called concurrently. There are no guarantees on the order in which multiple objects are finalized. This means that finalize() is usually unsuited for performing actions that must be thread-safe, and that your implementation must be use defensive programming if it is to always work.

If an Exception is thrown from finalize() during garbage collection, it will be patently ignored and the Object will still be destroyed.

It is allowed, although not typical, for user code to call finalize() directly. User invocation does not affect whether automatic invocation will occur. It is also permitted, although not recommended, for a finalize() method to "revive" an object by making it reachable from normal code again.

Unlike constructors, finalize() does not get called for an object's superclass unless the implementation specifically calls super.finalize().

The default implementation does nothing.

Throws:

Throwable - permits a subclass to throw anything in an overridden version; but the default throws nothing

See Also:

System.gc(), System.runFinalizersOnExit(boolean), java.lang.ref

public int hashCode()

Get a value that represents this Object, as uniquely as possible within the confines of an int.

There are some requirements on this method which subclasses must follow:

• Semantic equality implies identical hashcodes. In other words, if a.equals(b) is true, then a.hashCode() == b.hashCode() must be as well. However, the reverse is not necessarily true, and two objects may have the same hashcode without being equal.
• It must be consistent. Whichever value o.hashCode() returns on the first invocation must be the value returned on all later invocations as long as the object exists. Notice, however, that the result of hashCode may change between separate executions of a Virtual Machine, because it is not invoked on the same object.

Notice that since hashCode is used in Hashtable and other hashing classes, a poor implementation will degrade the performance of hashing (so don't blindly implement it as returning a constant!). Also, if calculating the hash is time-consuming, a class may consider caching the results.

The default implementation returns System.identityHashCode(this)

Returns:

the hash code for this Object

See Also:

equals(Object), System.identityHashCode(Object)

public final void notify()
            throws IllegalMonitorStateException

Wakes up one of the Threads that has called wait on this Object. Only the owner of a lock on this Object may call this method. This lock is obtained by a synchronized method or statement.

The Thread to wake up is chosen arbitrarily. The awakened thread is not guaranteed to be the next thread to actually obtain the lock on this object.

This thread still holds a lock on the object, so it is typical to release the lock by exiting the synchronized code, calling wait(), or calling Thread.sleep(long), so that the newly awakened thread can actually resume. The awakened thread will most likely be awakened with an InterruptedException, but that is not guaranteed.

Throws:

IllegalMonitorStateException - if this Thread does not own the lock on the Object

See Also:

notifyAll(), wait(), wait(long), wait(long,int), Thread

public final void notifyAll()
            throws IllegalMonitorStateException

Wakes up all of the Threads that have called wait on this Object. Only the owner of a lock on this Object may call this method. This lock is obtained by a synchronized method or statement.

There are no guarantees as to which thread will next obtain the lock on the object.

This thread still holds a lock on the object, so it is typical to release the lock by exiting the synchronized code, calling wait(), or calling Thread.sleep(long), so that one of the newly awakened threads can actually resume. The resuming thread will most likely be awakened with an InterruptedException, but that is not guaranteed.

Throws:

IllegalMonitorStateException - if this Thread does not own the lock on the Object

See Also:

notify(), wait(), wait(long), wait(long,int), Thread

public String toString()

Convert this Object to a human-readable String. There are no limits placed on how long this String should be or what it should contain. We suggest you make it as intuitive as possible to be able to place it into System.out.println() and such.

It is typical, but not required, to ensure that this method never completes abruptly with a RuntimeException.

This method will be called when performing string concatenation with this object. If the result is null, string concatenation will instead use "null".

The default implementation returns getClass().getName() + "@" + Integer.toHexString(hashCode()).

Returns:

the String representing this Object, which may be null

See Also:

getClass(), hashCode(), Class.getName(), Integer.toHexString(int)

public final void wait()
            throws IllegalMonitorStateException,
                   InterruptedException

Waits indefinitely for notify() or notifyAll() to be called on the Object in question. Implementation is identical to wait(0).

The Thread that calls wait must have a lock on this Object, obtained by a synchronized method or statement. After calling wait, the thread loses the lock on this object until the method completes (abruptly or normally), at which time it regains the lock. All locks held on other objects remain in force, even though the thread is inactive. Therefore, caution must be used to avoid deadlock.

While it is typical that this method will complete abruptly with an InterruptedException, it is not guaranteed. So, it is typical to call wait inside an infinite loop:

 try
   {
     while (true)
       lock.wait();
   }
 catch (InterruptedException e)
   {
   }
 

Throws:

IllegalMonitorStateException - if this Thread does not own a lock on this Object

InterruptedException - if some other Thread interrupts this Thread

See Also:

notify(), notifyAll(), wait(long), wait(long,int), Thread

public final void wait(long ms)
            throws IllegalMonitorStateException,
                   InterruptedException

Waits a specified amount of time (or indefinitely if the time specified is 0) for someone to call notify() or notifyAll() on this Object, waking up this Thread.

The Thread that calls wait must have a lock on this Object, obtained by a synchronized method or statement. After calling wait, the thread loses the lock on this object until the method completes (abruptly or normally), at which time it regains the lock. All locks held on other objects remain in force, even though the thread is inactive. Therefore, caution must be used to avoid deadlock.

Usually, this call will complete normally if the time expires, or abruptly with InterruptedException if another thread called notify, but neither result is guaranteed.

The waiting period is only *roughly* the amount of time you requested. It cannot be exact because of the overhead of the call itself. Most Virtual Machiness treat the argument as a lower limit on the time spent waiting, but even that is not guaranteed. Besides, some other thread may hold the lock on the object when the time expires, so the current thread may still have to wait to reobtain the lock.

Parameters:

ms - the minimum number of milliseconds to wait (1000 milliseconds = 1 second), or 0 for an indefinite wait

Throws:

IllegalArgumentException - if ms < 0

IllegalMonitorStateException - if this Thread does not own a lock on this Object

InterruptedException - if some other Thread interrupts this Thread

See Also:

notify(), notifyAll(), wait(), wait(long,int), Thread

public final void wait(long ms,
                       int ns)
            throws IllegalMonitorStateException,
                   InterruptedException

Waits a specified amount of time (or indefinitely if the time specified is 0) for someone to call notify() or notifyAll() on this Object, waking up this Thread.

The Thread that calls wait must have a lock on this Object, obtained by a synchronized method or statement. After calling wait, the thread loses the lock on this object until the method completes (abruptly or normally), at which time it regains the lock. All locks held on other objects remain in force, even though the thread is inactive. Therefore, caution must be used to avoid deadlock.

Usually, this call will complete normally if the time expires, or abruptly with InterruptedException if another thread called notify, but neither result is guaranteed.

The waiting period is nowhere near as precise as nanoseconds; considering that even wait(int) is inaccurate, how much can you expect? But on supporting implementations, this offers somewhat more granularity than milliseconds.

Parameters:

ms - the number of milliseconds to wait (1,000 milliseconds = 1 second)

ns - the number of nanoseconds to wait over and above ms (1,000,000 nanoseconds = 1 millisecond)

Throws:

IllegalArgumentException - if ms < 0 or ns is not in the range 0 to 999,999

IllegalMonitorStateException - if this Thread does not own a lock on this Object

InterruptedException - if some other Thread interrupts this Thread

See Also:

notify(), notifyAll(), wait(), wait(long), Thread