Enums why cant we override equals

in the java.lang.Enum class equals method is like

 
 public final boolean equals(Object other) {
       return this==other;
 }
 
actually overriding it with something else does not make sense hence its final. As for Enums equals() and == are the same things.

Java Generic < ? > vs < T >

Using "?" is the same as "any", whereas "T" means "a specific type". So, compare these interfaces:

public interface StrictClass {
 public T doFunction(Class class);
}


public interface EasyClass {
 public < ? >  doFunction(Class class);
}


When to use which one

There are also use cases for choosing over (or vice versa) that apply when you don't add type parameter to the class that encloses the method. For example, consider the difference between

public boolean add(List j) {
    boolean t = true;
    for (JLabel b : j) {
        if (b instanceof JLabel) {
            t = t && labels.add(b);
        }
    }
    return t;
}
and

public boolean add(List j) {
    boolean t = true;
    for (JLabel b : j) {
        if (b instanceof JLabel) {
            t = t && labels.add(b);
        }
    }
    return t;
}
The first method will actually not compile UNLESS you add an appropriate type parameter to the enclosing class, whereas the second method WILL compile regardless of whether the enclosing class has a type parameter

Using Type Tokens to Retrieve Generic Parameters

Interesting read

http://www.jquantlib.org/index.php/Using_TypeTokens_to_retrieve_generic_parameters

Type Erasure : Why the information is dropped at compile time

We all know that, at compile-time, the compiler has full type information available but this information is intentionally dropped in general when the binary code is generated, in a process known as type erasure. 

So to put in different words this feature is offered by javac :)

one needs to realize the concept of type erasure derives from a need of compatibility with previous versions of java.

• Source compatibility (Nice to have...)
• Binary compatibility (Must have!)
• Migration compatibility
  
  • Existing programs must continue to work
  • Existing libraries must be able to use generic types
  • Must have!

This is done this way due to compatibility issues... The intention of language designers was providing full source code compatibility and full binary code compatibility between versions of the platform. If it was implemented differently, you would have to recompile your legacy applications when you migrate to newer versions of the platform. The way it was done, all method signatures are preserved (source code compatibility) and you don't need to recompile anything (binary compatibility).

Hibernate Query vs Criteria Performance

For some reason HQL seems more faster than Criteria

If we write a query like

select count(*) from R r where r.ISREPLACEDBY = 0 and r.STATUS='OK' and r.A = ? and r.C in (select distinct RC from CX cx where cx.FROMDATE >= ? and cx.FROMDATE <= ?)

Using both HQL and Criteria , then HQL will run much faster.

It seems that the criteria api creates new variable names each time a prepared statement is executed. The database (in our case, DB2) calculates then a new query execution plan each time the statement is executed. On the other hand, HQL uses the same variable names, allowing the database to re-use the query execution plans.

Another issue i noticed when using HQL , I was using HQL like

from employee emp where emp.id=123
at one place, and HQL like
from employee e where e.id=123
at another place.

Although i was using a query level cache BUT still it was not being cached BECAUSE query cache was not being used here as the key for query cache is the query itself.