em qualquer lugar abordando o java5 (inclusive o javadoc) fala que eh melhor usar Double.valueOf (double ) ao inves de new Double (double) e até hoje acreditei nisso, sempre chamando o primeiro.
Muito bem, eis que, sem querer, abri o source do Double.valueOf (double) e me deparei com o codigo a seguir:
/**
* Returns a <tt>Double</tt> instance representing the specified
* <tt>double</tt> value.
* If a new <tt>Double</tt> instance is not required, this method
* should generally be used in preference to the constructor
* {@link #Double(double)}, as this method is likely to yield
* significantly better space and time performance by caching
* frequently requested values.
*
* @param d a double value.
* @return a <tt>Double</tt> instance representing <tt>d</tt>.
* @since 1.5
*/
public static Double valueOf(double d) {
return new Double(d);
}
estou usando o jdk 1.5.0.06-b05 para windows.
alguem por acaso tem o mustang para ver se continua igual? do jeito que esta, este método é inútil…
Chutando: Aparemente eles dizem isso para todos os métodos valueOf dos classes wrapper para tipos primitivos. Talvez no caso do Double não faz sentido tentar evitar a criação de um novo objeto, mas tentando manter consistencia eles dão o mesmo conselho.
Já no caso do Integer o método valueOf(int) é um pouco mais sofisticado (como você talvez já sabe):
/**
* Returns a <tt>Integer</tt> instance representing the specified
* <tt>int</tt> value.
* If a new <tt>Integer</tt> instance is not required, this method
* should generally be used in preference to the constructor
* {@link #Integer(int)}, as this method is likely to yield
* significantly better space and time performance by caching
* frequently requested values.
*
* @param i an <code>int</code> value.
* @return a <tt>Integer</tt> instance representing <tt>i</tt>.
* @since 1.5
*/
public static Integer valueOf(int i) {
final int offset = 128;
if (i >= -128 && i <= 127) { // must cache
return IntegerCache.cache[i + offset];
}
return new Integer(i);
}
[]s,
Sami
JDK 1.6.0 ( build 1.6.0-rc-b90 )
O javadoc manifesta a intenção; o código diz outra coisa.
De qualquer maneira, no caso específico do Double, não deve haver muitos valores significativos que fossem muito freqüentes e valessem a pena serem obtidos a partir de um cache. (Talvez 0.0, 1.0 e -1.0). É que a operação de comparação já é lenta por si só, se não houver suporte a números de ponto flutuante por hardware - lembrem-se que o Java é multiplataforma - portanto nesse caso acaba sendo mais eficiente usar um novo objeto.
/**
* Returns a <tt>Double</tt> instance representing the specified
* <tt>double</tt> value.
* If a new <tt>Double</tt> instance is not required, this method
* should generally be used in preference to the constructor
* {@link #Double(double)}, as this method is likely to yield
* significantly better space and time performance by caching
* frequently requested values.
*
* @param d a double value.
* @return a <tt>Double</tt> instance representing <tt>d</tt>.
* @since 1.5
*/
public static Double valueOf(double d) {
return new Double(d);
}