2010-01-09 14 views
9

Soy un gran fanático del auto-boxing en Java, ya que ahorra un montón de código de placa de caldera feo. Sin embargo, he encontrado que el auto-unboxing es confuso en algunas circunstancias donde el objeto Number puede ser nulo. ¿Hay alguna manera de detectar dónde se está produciendo un desempaquetado automático en una base de código con una advertencia javac? Cualquier otra solución para detectar las apariciones de unboxing solamente (como FindBugs o la advertencia del compilador específica de Eclipse) sería apreciada ya que no puedo encontrar ninguna.Unboxing automático de Java: ¿hay una advertencia del compilador?

Para aclarar, no quiero que se generen advertencias en el boxeo, solo unboxing.

Aquí está un ejemplo simple de un código que puede causar confusión NullPointerExceptions:

class Test { 
    private Integer value; 

    public int getValue() { 
     return value; 
    } 
} 

Respuesta

1

Eclipse le permitirá operaciones de boxing y unboxing color de sintaxis (pero no una u otra). Los tengo configurados en rojo brillante: si cualquiera de los dos sucede, significa que he sido descuidado en la coincidencia de parámetros y argumentos.

+0

Gracias, creo que haré lo mismo. Incluso si no detecta el problema, debería facilitar la depuración del problema. –

+2

Existe un problema para separar el boxeo de las advertencias de unboxing: https://bugs.eclipse.org/bugs/show_bug.cgi?id=163065 – Kyle

5

Sip. En Eclipse:

Preferencias-> Java-> Compiler-> Errores/ADVERTENCIAS-> Potencial Programación problemas-> Boxing y unboxing conversiones

+0

Lo siento, tal vez debería ser más claro (voy a modificar la pregunta). Quiero una advertencia sobre unboxing pero no sobre el boxeo. –

+0

Ah, ningún Eclipse no le permitirá distinguir entre los dos. – skaffman

+0

@skaffman Esperamos que esto: https://bugs.eclipse.org/bugs/show_bug.cgi?id=163065 se implemente. – Kyle

2

Por desgracia no lo hay. Este es uno de los problemas con los números de unboxing automático. Puede

  • inicializarlo a un valor predeterminado, como private Integer value = 0
  • Compruebe si hay un nulo return value != null ? value : 0

personalmente prefiero el primer método. En general, creo que no tendrías demasiados casos en los que deberías tener un número nulo.

Además, ¿por qué está utilizando un gran número entero para almacenar el valor. Si solo regresas un poco int, ¿por qué no almacenarlo de esa manera?

+0

Algunas veces, la operabilidad de la API/interfaz requiere devolver int mientras Long/BigInteger esté disponible. ¡Oh, cómo me gustaría tener una 'Lista' con entradas' Long.MAX_VALUE' pero, ay, no puedo hacer eso. – Esko

+0

Puedes tener una 'Lista' tan grande; simplemente no puede decirte que es tan grande. En 'LinkedList', por ejemplo, mantiene un campo' size' de tipo 'int', pero nunca verifica para asegurarse de que el tamaño no se desborde. Sin embargo, hay algunas operaciones que fallarán, basadas en asegurarse de que el índice actual sea * menor que * el tamaño, lo que no se mantendría si el campo 'tamaño 'se hubiera desbordado a un valor negativo. – seh

+0

No puedo usar una 'Lista' con elementos Long.MAX_VALUE como un reemplazo directo en mi código y es allí donde importa. Conozco muy bien la semántica de 'AbstractList' y similares, sin embargo, siempre que la interfaz en sí dice' int', estoy obligado a ello. – Esko

1

Dudo que esto sea un caso de advertencia. Esta es una de las peculiaridades del auto-boxeo.

Joshua Bloch aborda esto en su libro "Effective Java". Básicamente, el compilador está tratando de hacer más por usted que lo que se espera. En otras palabras, este tipo de problema se relaciona más comúnmente con el uso y, como resultado, es difícil "detectar el error" ya que el error es, semánticamente hablando, simplemente que no existe.

Cuestiones relacionadas