¿Por qué no hay String.Empty en Java? [closed]

8 minutos de lectura

avatar de usuario
tom tresansky

Entiendo que cada vez que escribo el literal de cadena ""se hace referencia al mismo objeto String en el grupo de cadenas.

Pero, ¿por qué la String API no incluye un public static final String Empty = "";por lo que podría usar referencias a String.Empty?

Ahorraría tiempo de compilación, como mínimo, ya que el compilador sabría hacer referencia a la cadena existente y no tendría que verificar si ya se había creado para su reutilización, ¿verdad? Y personalmente, creo que una proliferación de cadenas literales, especialmente las pequeñas, en muchos casos es un “olor a código”.

Entonces, ¿hubo una gran razón de diseño detrás de String.Empty, o los creadores del lenguaje simplemente no compartieron mis puntos de vista?

  • Aidanc: Creo que se refiere a situaciones en las que haces cosas como outputBlah = ""y probablemente prefiera something == String.Empty sobre something.Length > 0 también (se salta una verificación nula).

    – Skurmedel

    10 de agosto de 2010 a las 15:31


  • @Aidanc: estaba buscando un “miembro vacío” como Colecciones.EMPTY_SETno es una función para verificar la cadena “vacío”.

    –Tim Stone

    10 de agosto de 2010 a las 15:31


  • @Aidanc: Lo que inspiró esto es en realidad ‘TextBox.setText(“”);’.

    – Tom Tresanski

    10 de agosto de 2010 a las 15:34

  • Hay una String.isEmpty() función… ¿por qué querrías String.EMPTY?

    – Buhake Sindi

    10 de agosto de 2010 a las 15:42

  • String.isEmpty() no devuelve una cadena vacía.

    –Steve Kuo

    10 de agosto de 2010 a las 18:57

avatar de usuario
noel m

String.EMPTY tiene 12 caracteres y "" es dos, y ambos estarían haciendo referencia exactamente a la misma instancia en la memoria en tiempo de ejecución. No estoy completamente seguro de por qué String.EMPTY ahorraría tiempo de compilación, de hecho creo que sería lo último.

especialmente considerando Strings son inmutables, no es como si primero pudiera obtener una cadena vacía y realizar algunas operaciones en ella; es mejor usar una StringBuilder (o StringBuffer si quiere ser seguro para subprocesos) y conviértalo en una Cadena.

Actualizar

De tu comentario a la pregunta:

Lo que inspiró esto es en realidad
TextBox.setText("");

Creo que sería totalmente legítimo proporcionar una constante en su clase apropiada:

private static final String EMPTY_STRING = "";

Y luego haga referencia a él como en su código como

TextBox.setText(EMPTY_STRING);

De esta manera, al menos, es explícito que desea una Cadena vacía, en lugar de olvidarse de completar la Cadena en su IDE o algo similar.

  • Seguiré haciéndote +1, pero me siento sucio porque mencionaste StringBuilder sin hablar de cómo nueve de cada diez veces es totalmente inapropiado usar StringBuilder en lugar de concatenación.

    – Randolfo

    10 de agosto de 2010 a las 15:36

  • Tiendo a preferir string.empty, principalmente porque es más explícito. Además, hay situaciones de tarifas en las que puede ser más difícil diferenciar visualmente “” y cosas como “‘”. Al final, como otros han notado, es solo una de esas cosas de estilo sin sentido que nos dan forraje para discutir cuando estamos aburridos con el trabajo real. =)

    – JuanFx

    10 de agosto de 2010 a las 15:42

  • @Nodel M: con respecto al tiempo de compilación, supongo que si hay 2 literales de cadena definidos en 2 archivos fuente diferentes con el mismo valor de cadena, cuando el compilador llega al segundo, necesita hacer algún tipo de verificación para averiguarlo ” oye, ya sé sobre esta cadena de aquí atrás”. Es cierto que no soy un experto en el compilador de Java, pero ¿cómo podría NO ser este el caso? Y creo que omitir esa verificación daría como resultado una mejora minúscula en los tiempos de compilación.

    – Tom Tresanski

    10 de agosto de 2010 a las 15:52

  • @Randolpho Cuando usa la concatenación de cadenas, en realidad está usando un StringBuilder debajo del capó.

    – whiskysierra

    10 de agosto de 2010 a las 19:23


  • Y no olvide que para “” tenemos que agregar //$NON-NLS-1$ que son 13 caracteres + 2 de “”. Entonces String.EMPTY ganaría tanto en longitud como en estética.

    – Yaza

    20 de abril de 2020 a las 17:25

avatar de usuario
jade

Usar org.apache.commons.lang.StringUtils.EMPTY

  • Se ve mucho mejor y más fácil de leer que un “”. Espero que no sea solo yo.

    – Lakatos Gyula

    26 de enero de 2015 a las 21:09

  • @LakatosGyula: creo que podría ser (solo tú). Los programadores avanzados de Java no tienen problemas para leer "" … y la mayoría probablemente objetaría en voz alta sobre el uso de EMPTY excepto en situaciones específicas en las que EMPTY tiene un significado específico de dominio. (Y en tales casos, probablemente haya un nombre más apropiado).

    – Esteban C.

    10 de febrero de 2015 a las 22:59


  • @LakatosGyula No eres solo tú. Pasé del desarrollo de Java al .NET, y String.Empty fue una característica que me complació encontrar en el marco. Me gusta la naturaleza explícita de la misma sobre un conjunto vacío de comillas.

    – yohohoho

    27 de febrero de 2015 a las 4:07

  • @StephenC Cuando veo un “” vacío, lo primero que me viene a la mente es que es un error, que alguien no terminó la función, etc. Con String.EMPTY sé exactamente que el desarrollador tenía la intención de devolver una cadena vacía.

    – Lakatos Gyula

    3 de marzo de 2015 a las 18:32

  • También es útil para todos esos momentos en los que el linter dice “use una constante con nombre en lugar de bla, bla, bla”. Todo programador sabe que “” no es magia, pero es mejor no tener que explicárselo al cliente.

    – LizH

    22 de junio de 2016 a las 12:46

Si desea comparar con una cadena vacía sin preocuparse por los valores nulos, puede hacer lo siguiente.

if ("".equals(text))

En última instancia, debes hacer lo que creas que es más claro. La mayoría de los programadores asumen que “” significa una cadena vacía, no una cadena en la que alguien olvidó poner algo.

Si cree que hay una ventaja de rendimiento, debe probarlo. Si no cree que valga la pena probarlo usted mismo, es una buena indicación de que realmente no vale la pena.

Parece que intentas resolver un problema que se resolvió cuando se diseñó el lenguaje hace más de 15 años.

  • Llegué bastante tarde a la fiesta pero, dado que las cadenas de Java son inmutables, creo que todas las cadenas vacías dentro de una JVM son solo referencias diferentes al mismo objeto String. Así que simplemente lo siguiente también es correcto: if ("" == text)

    – Ajoy Bhatia

    4 de abril de 2012 a las 22:14


  • @AjoyBhatia El problema es que puedes crear nuevas cadenas vacías. if ("" == new String()) Es falso. una mejor prueba if(text.isEmpty())

    – Peter Lawrey

    5 de abril de 2012 a las 5:52

  • @AjoyBhatia: solo si las cuerdas están internas. stackoverflow.com/questions/10578984/what-is-string-interning

    – Davor

    4 sep 2014 a las 11:57

avatar de usuario
Slawomir

No diga simplemente “el conjunto de cadenas de memoria se reutiliza en forma literal, caso cerrado”. Lo que hacen los compiladores bajo el capó no es el punto aquí. La pregunta es razonable, especialmente dada la cantidad de votos a favor que recibió.

se trata de la simetría, sin ella, las API son más difíciles de usar para los humanos. Los primeros SDK de Java ignoraron notoriamente la regla y ahora es demasiado tarde. Aquí hay algunos ejemplos en la parte superior de mi cabeza, siéntase libre de agregar su ejemplo “favorito”:

  • BigDecimal.ZERO, pero no AbstractCollection.EMPTY, String.EMPTY
  • Array.length pero List.size()
  • List.add(), Set.add() pero Map.put(), ByteBuffer.put() y no olvidemos StringBuilder.append(), Stack.push()

Apache StringUtils también aborda este problema.

Fallas de las otras opciones:

  • isEmpty() – no nulo seguro. Si la cadena es nula, lanza un NPE
  • length() == 0 – nuevamente no nulo seguro. Tampoco tiene en cuenta las cadenas de espacios en blanco.
  • Comparación con la constante EMPTY: no puede ser nulo seguro. Problema de espacio en blanco

Concedido StringUtils es otra biblioteca para arrastrar, pero funciona muy bien y ahorra un montón de tiempo y molestias en la comprobación de nulos o el manejo elegante de NPE.

  • entonces… parece que la única opción segura es la terrible condición de Yoda: "".equals(s)?

    – miente ryan

    15 de septiembre de 2012 a las 5:36


avatar de usuario
Benoit Courtine

Si realmente desea una constante String.EMPTY, puede crear una clase final estática de utilidad llamada “Constantes” (por ejemplo) en su proyecto. Esta clase mantendrá sus constantes, incluida la cadena vacía…

En la misma idea, puede crear CERO, UNO int constantes … que no existen en la clase Integer, pero como comenté, sería un dolor escribir y leer:

for(int i=Constants.ZERO; ...) {
    if(myArray.length > Constants.ONE) {
        System.out.println("More than one element");
    }
}

Etc.

  • entonces… parece que la única opción segura es la terrible condición de Yoda: "".equals(s)?

    – miente ryan

    15 de septiembre de 2012 a las 5:36


avatar de usuario
djangofan

Parece que esta es la respuesta obvia:

String empty = org.apache.commons.lang.StringUtils.EMPTY;

Impresionante porque el código de “inicialización vacía” ya no tiene una “cadena mágica” y usa una constante.

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad