¿Qué es un archivo clase en Java?
Un archivo clase en Java es una forma compilada de un archivo de código fuente de Java. Cuando compilamos el programa Java que esta escrito en el archivo de código fuente de Java termina con la extensión .java , produce mas de un archivo de clase dependiendo de cuántas clases se declaran y definen en ese archivo origen de Java. Un archivo de Java puede contener solo una clase pública y su nombre debe coincidir con el nombre del archivo, por ejemplo: HelloWorld.java, este archivo puede contener una clase pública cuyo nombre debe ser HelloWorld como se muestra a continuacion:
Si compilas este archivo de Java por
=> javac HellowWorld.java
Generará lo siguiente
=> HelloWorld.class
Detalles de un archivo Clase en Java.
Un archivo clase en Java tiene la extensión .class y contienen el bytecode, el cual es la instrucción para la Máquina Virtual de Java o Java Virtual Machine (JVM), que luego traduce ese bytecode en instrucciones de nivel máquina dentro de la plataforma especifica sobre la cual se esta ejecutando el programa Java sea Windows o Linux. De hecho esta combinación del archivo de la clase, bytecode y JVM logra la independencia de plataforma de Java. Si alguien pregunta, ¿Que es el bytecode en Java, es la instrucción en lenguaje máquina?, tú puedes responderle que es justo el lenguaje para la JVM no para una maquina en especifico.
Cuando ejecutas un programa Java como se describe en este tutorial paso a paso para ejecutar un programa Java usando comandos, proporcionamos el nombre del archivo de la clase que contiene el método principal en java. La JVM primero carga ese archivo y ejecuta el método principal que es el punto de entrada de la aplicación de Java. Recuerda que el compilador de Java o comando de javac es usado para crear un archivo de la clase desde el archivo fuente Java y el comando Java es utilizado para ejecutar el programa Java almacenado en un archivo clase.
Dado que el archivo de la clase contiene bytecode en formato hexadecimal y el formato del archivo de la clase esta bien documentado cualquiera puede moderar al archivo de la clase y romper los beneficiarios de seguridad de Java. Con el fin de evitar eso cada archivo de clase de Java es verificado por el verificador, después de cargar durante el proceso de verificación del bytecode y el verificador rechaza el archivo de clase que violan las restricciones del lenguaje de programación Java.
Eso es todo sobre Que es un archivo clase en Java y cómo crear un archivo clase en Java. En resumen el archivo clase es un archivo binario que contiene bytecode y el compilador de Java es usado para encriptar el archivo clase en Java.
***El Artículo fue obtenido de Java67 y fue modificado ligeramente para su traducción. Para revisar el contenido original dar clic aquí.
Mostrando entradas con la etiqueta java core. Mostrar todas las entradas
Mostrando entradas con la etiqueta java core. Mostrar todas las entradas
miércoles, 28 de junio de 2017
lunes, 24 de abril de 2017

Diferencias entre Abstracción y Encapsulación en Java. POO
Tanto la Abstracción como la Encapsulación son dos de los cuatros conceptos básicos de la Programación Orientada a Objetos (POO) con los cuales puedes modelar las cosas del mundo real en objetos y puedas implementarlas en tu programa y código. Muchos principiantes tienden a confundir estos términos por lo similar que pueden llegar a lucir. Si tu le preguntas a alguien ¿que es la Abstracción?, esa persona te responderá que es un concepto de la POO que se centra en la información pertinente ocultando detalles innecesarios, y cuando preguntas acerca de la Encapsulación, muchos te responden que es otro concepto de la POO el cual oculta datos del mundo exterior. Las definiciones no son erróneas ya que tanto la Abstracción como la Encapsulación ocultan algo, pero la diferencia clave esta en la intención.
La abstracción oculta la complejidad para dar una imagen mas abstracta, mientras que la encapsulación oculta el trabajo interno para que puedas cambiarlo posteriormente. En otras palabras, la Abstracción oculta detalles a nivel de diseño, mientras que la Encapsulación oculta detalles a nivel de implementación.
Por ejemplo, cuando describes un objeto por primera vez, hablas en términos mas abstractos, como: "Vehículo que se puede mover", no dices cómo se moverá el vehículo, si se moverá usando neumáticos, si volará o si navegará. Solo se mueve. A esto llamamos Abstracción. Estamos hablando de una de las cosas mas esenciales, y es que esta en movimiento, en vez de centrarse en detalles sobre cómo se mueve, si por tierra, volando o por agua.
Están también los diferentes niveles de Abstracción y es una buena práctica que las clases deberían interactuar con otras clases con un mismo nivel de Abstracción o mayor nivel de Abstracción. De manera que a medida que incrementa el nivel de Abstracción, las cosas empiezan a ser cada vez mas simples, dejando a un lado los detalles.
Por otro lado, la Encapsulación trata sobre la implementación. Su único propósito es ocultar el trabajo interno de los objetos del mundo exterior para que pueda cambiarlo mas tarde sin afectar a los clientes externos.
Por ejemplo, tenemos un HashMap que permite almacenar el objeto utilizando el método put() y recuperar el objeto utilizando el método get(). Cómo HashMaps implementa este método (lee mas aquí) es un detalle interno de HashMap, el cliente solo se preocupa por almacenar los objetos y devolverlo, a él no le concierne si HashMap esta usando un arreglo, cómo esta resolviendo la colisión, si esta usando una lista o un árbol binario para almacenar el intercambio de los objetos en la memoria, etc.
Debido a la Encapsulación, tu puedes cambiar el funcionamiento interno de HashMap con facilidad sin interferir con los clientes que están usando HashMap. Por ejemplo, en Java 8, el java.util.HashMap cambia su implementación para usar un árbol binario en lugar de una lista para almacenar los objetos en el mismo lugar después de cierto punto (lee mas aquí).
El cliente no necesita hacer ningún cambio para beneficiarse de este cambio de código porque esos detalles no están expuestos a ellos. Si el cliente tuviera conocimiento de ello, es decir, que de alguna manera pudiesen tener referencia del arreglo interno del HashMap, no habría sido posible cambiar la implementación sin afectar a los demás clientes.
Existen muchos principios de diseño basados en la Abstracción, como por ejemplo, "Codificación para interfaces después de la implementación" que ayuda a escribir código flexible en Java o C++. La idea es que una clase dependa de una interfaz, un nivel de abstracción mas alto que la clase, un un menor nivel de abstracción. Esto resulta en un código flexible que puede funcionar con cualquier implementación de la interfaz.
Por ejemplo, si tu necesitas HashMap, tu clase debe depender de Map en lugar de HashMap. De igual forma, si tu necesitas ArrayList, asegúrate de usar la List. Afortunadamente, el tío Bob ha compartido varios principios de diseño sobre Clean Code, conocidos colectivamente como principios de diseño SOLID, que es algo que cada programador POO debe aprender y entender.
***El Artículo fue obtenido de JavaRevisited y fue modificado ligeramente para su traducción. Para revisar el contenido original dar clic aquí.
La abstracción oculta la complejidad para dar una imagen mas abstracta, mientras que la encapsulación oculta el trabajo interno para que puedas cambiarlo posteriormente. En otras palabras, la Abstracción oculta detalles a nivel de diseño, mientras que la Encapsulación oculta detalles a nivel de implementación.
Por ejemplo, cuando describes un objeto por primera vez, hablas en términos mas abstractos, como: "Vehículo que se puede mover", no dices cómo se moverá el vehículo, si se moverá usando neumáticos, si volará o si navegará. Solo se mueve. A esto llamamos Abstracción. Estamos hablando de una de las cosas mas esenciales, y es que esta en movimiento, en vez de centrarse en detalles sobre cómo se mueve, si por tierra, volando o por agua.
Están también los diferentes niveles de Abstracción y es una buena práctica que las clases deberían interactuar con otras clases con un mismo nivel de Abstracción o mayor nivel de Abstracción. De manera que a medida que incrementa el nivel de Abstracción, las cosas empiezan a ser cada vez mas simples, dejando a un lado los detalles.
Por otro lado, la Encapsulación trata sobre la implementación. Su único propósito es ocultar el trabajo interno de los objetos del mundo exterior para que pueda cambiarlo mas tarde sin afectar a los clientes externos.
Por ejemplo, tenemos un HashMap que permite almacenar el objeto utilizando el método put() y recuperar el objeto utilizando el método get(). Cómo HashMaps implementa este método (lee mas aquí) es un detalle interno de HashMap, el cliente solo se preocupa por almacenar los objetos y devolverlo, a él no le concierne si HashMap esta usando un arreglo, cómo esta resolviendo la colisión, si esta usando una lista o un árbol binario para almacenar el intercambio de los objetos en la memoria, etc.
Debido a la Encapsulación, tu puedes cambiar el funcionamiento interno de HashMap con facilidad sin interferir con los clientes que están usando HashMap. Por ejemplo, en Java 8, el java.util.HashMap cambia su implementación para usar un árbol binario en lugar de una lista para almacenar los objetos en el mismo lugar después de cierto punto (lee mas aquí).
El cliente no necesita hacer ningún cambio para beneficiarse de este cambio de código porque esos detalles no están expuestos a ellos. Si el cliente tuviera conocimiento de ello, es decir, que de alguna manera pudiesen tener referencia del arreglo interno del HashMap, no habría sido posible cambiar la implementación sin afectar a los demás clientes.
Existen muchos principios de diseño basados en la Abstracción, como por ejemplo, "Codificación para interfaces después de la implementación" que ayuda a escribir código flexible en Java o C++. La idea es que una clase dependa de una interfaz, un nivel de abstracción mas alto que la clase, un un menor nivel de abstracción. Esto resulta en un código flexible que puede funcionar con cualquier implementación de la interfaz.
Por ejemplo, si tu necesitas HashMap, tu clase debe depender de Map en lugar de HashMap. De igual forma, si tu necesitas ArrayList, asegúrate de usar la List. Afortunadamente, el tío Bob ha compartido varios principios de diseño sobre Clean Code, conocidos colectivamente como principios de diseño SOLID, que es algo que cada programador POO debe aprender y entender.
Abstracción Vs. Encapsulación.
A continuación y a modo de resumen, desglosamos por puntos las principales diferencias entre Encapsulación y Abstracción.
- La diferencia mas importante entre Abstracción y Encapsulación es que la Abstracción resuelve el problema en un nivel de diseño mientras que la Encapsulación lo resuelve en un nivel de implementación.
- La Abstracción busca esconder detalles no deseados mientras genera detalles mas esenciales, mientras que la Encapsulación busca ocultar el código y los datos dentro de una sola unidad, es decir, una clase o un método protegen su trabajo interno de objetos externos. En otras palabras, la Abstracción solo extrae detalles comunes o generaliza cosas.
- La Abstracción permite centrarse en lo que el objeto hace en lugar de como lo hace, mientras la Encapsulación busca ocultar los detalles internos o forma de trabajar de un objeto. Cuando mantienes privados los detalles internos de trabajo de un objeto, se pueden editar posteriormente por un método mejor. El libro Head First Object Oriented Analysis and Design tiene algunos ejemplos excelentes de estos conceptos de POO, le sugiero que lean este libro al menos una vez para revisar los fundamentos de la POO.
- El enfoque de la abstracción es externo, por ejemplo: Desplazamiento del vehículo. Mientras que la encapsulación se ocupa del trabajo interno, por ejemplo: como se mueve exactamente el vehículo.
- En Java, la Abstracción esta apoyada por el uso de interfaces y clases abstractas mientras que la Encapsulación esta soportada por el uso de los modificadores de accesos: public, private and protected.
Esto es todo acerca de las diferencias entre la Abstracción y la Encapsulación en Java y POO. Yo entiendo, ambos parecen muy similares, pero como he dicho son conceptos totalmente diferentes. Solo recuerda que la Abstracción resuelve los problemas en el nivel de diseño mientras la Encapsulación los resuelve en el nivel de implementación. Ambos son muy importantes para un programador POO pero algunas veces resulta difícil de explicar.
Como dije anteriormente, la mejor manera de aprender y volverse un master de la Programación Orientada a Objetos es escribiendo código y leyendo el código de otros. Cuanto mas se exponen al código, mas se dan cuenta de cómo funcionan estos conceptos en la práctica. Hay varios principios de diseño que se basan en términos de abstracción, por ejemplo, codificación de interfaz en lugar de implementación, el cual permite escribir codigo flexible.
Otras entradas sobre POO que podrían gustarte:
- Diferencias entre Clase y Objeto en Java y POO (haz clic aquí).
- Diferencias entre Herencia y Polimorfismo en Java (Pronto traducido aquí).
- Diferencias entre Agregación, Composición y Asociación en POO (Pronto traducido aquí).
- Diferencias entre patrones de diseño de Estado y Estrategia (Pronto traducido aquí).
- ¿Que es el Polimorfismo?¿Sobrecarga o Anulación? (Pronto traducido aquí).
- ¿Cual es la diferencia entre Sobrecarga y Anulación en POO? (Pronto traducido aquí).
- Diferencias entre instancia y objetos en Java (Pronto traducido aquí).
- ¿Cual es la diferencia entre un descubrimiento estático y dinámico en Java? (Pronto traducido aquí).
Gracias por leer este articulo, si de verdad te gusto, no dejes de compartirlo con tus amigos y colegas. Si tienes alguna pregunta o sugerencia, por favor déjala en los comentarios. Y si quieres saber mas sobre conceptos de POO, principios de diseño SOLID y aplicación de los conceptos de POO en la vida real, no dejes de leer Clean Code.
lunes, 24 de octubre de 2016

¿Para qué se usa la clase "java.lang.Class" en Java?
java.lang.Class es una de las clases más importantes pero ignoradas por los desarrolladores Java. Es muy importante en el sentido de que provee muchos métodos de utilidad. Por ejemplo los métodos getClass(), forName() que son usados para encontrar y cargar una clase, quizá tu las has usado para cargar los drivers de Oracle o MySQL.
También provee métodos como Class.newInstance() la cual es el corazón de reflection y te permite crear una instancia de una clase sin utilizar el operador new(). La clase no tiene constructores públicos y sus instancias son creadas por la JVM cuando la clase es cargada. El objeto de clase tipo Class también es usado para representar clases, enumeraciones, interfaces, y anotaciones corriendo en una aplicación Java. Los tipos primitivos como byte, short, char, int, float, double, boolean así como la palabra reservada void también son representados como instancias de Class.
Puedes obtener la instancia correspondiente a Class usando la literal class, por ejemplo int.class, float.class o boolean.class. También es usada para representar una instancia de un arreglo en Java. Todos los arreglos con el mismo tipo y la misma dimensión comparten la misma instancia de la clase Class.
Otro uso de java.lang.Class es mientras se implementa el método equals() para verificar si dos objetos son del mismo tipo o no.
Cada vez que la JVM crea un objeto, también se crea un objeto de la clase java.lang.Class que describe el tipo de objeto. Todas las instancias del la misma clase comparten el mismo objecto de la clase Class y así puedes obtener el objecto Class llamando el método getClass() de cualquier objeto. Además, este método es heredado de la clase java.lang.Object.
Imagina que tu creas dos instancias de una clase llamada Persona por ejemplo
En este caso, se imprimirá "A y B son instancias de la misma clase" porque ambas son instancias de la clase Persona.
Necesitamos forName() y newInstance() porque varias veces no sabemos el nombre de la clase que hay que inicializar mientras escribimos el código, podría ser que estamos obteniéndolo desde archivos de configuración, bases de datos, red o desde algún flujo de información de una aplicación Java externa.
Es por eso que llamamos de forma reflectiva la creación del objeto, la cual es una de las más poderosas características en Java y que es utilizada por muchos frameworks, por ejemplo Spring, Struts utilizan Java reflection
***El Artículo fue obtenido de JavaRevisited y fue modificado ligeramente para su traducción. Para revisar el contenido original dar clic aquí.
También provee métodos como Class.newInstance() la cual es el corazón de reflection y te permite crear una instancia de una clase sin utilizar el operador new(). La clase no tiene constructores públicos y sus instancias son creadas por la JVM cuando la clase es cargada. El objeto de clase tipo Class también es usado para representar clases, enumeraciones, interfaces, y anotaciones corriendo en una aplicación Java. Los tipos primitivos como byte, short, char, int, float, double, boolean así como la palabra reservada void también son representados como instancias de Class.
Puedes obtener la instancia correspondiente a Class usando la literal class, por ejemplo int.class, float.class o boolean.class. También es usada para representar una instancia de un arreglo en Java. Todos los arreglos con el mismo tipo y la misma dimensión comparten la misma instancia de la clase Class.
Otro uso de java.lang.Class es mientras se implementa el método equals() para verificar si dos objetos son del mismo tipo o no.
java.lang.Class en Java
Cada vez que la JVM crea un objeto, también se crea un objeto de la clase java.lang.Class que describe el tipo de objeto. Todas las instancias del la misma clase comparten el mismo objecto de la clase Class y así puedes obtener el objecto Class llamando el método getClass() de cualquier objeto. Además, este método es heredado de la clase java.lang.Object.
Imagina que tu creas dos instancias de una clase llamada Persona por ejemplo
En este caso, se imprimirá "A y B son instancias de la misma clase" porque ambas son instancias de la clase Persona.
Necesitamos forName() y newInstance() porque varias veces no sabemos el nombre de la clase que hay que inicializar mientras escribimos el código, podría ser que estamos obteniéndolo desde archivos de configuración, bases de datos, red o desde algún flujo de información de una aplicación Java externa.
Es por eso que llamamos de forma reflectiva la creación del objeto, la cual es una de las más poderosas características en Java y que es utilizada por muchos frameworks, por ejemplo Spring, Struts utilizan Java reflection
***El Artículo fue obtenido de JavaRevisited y fue modificado ligeramente para su traducción. Para revisar el contenido original dar clic aquí.
viernes, 21 de octubre de 2016

¿Por qué String es Inmutable en JAVA?
El tipo de dato String es Inmutable(es decir que no puede ser modificada) porque cualquier objeto String creado es almacenado en un espacio de memoria llamado String pool. Y ya que las literales tipo String son compartidas entre múltiples clientes siempre existe un riesgo donde alguna de las acciones de un cliente puede afectar a otro.
Por ejemplo, si uno de los clientes cambia el valor del String "Test" a "TEST", el resto de los clientes también verían ese valor como se explicó anteriormente.
Debido a que mantener en memoria los objetos de tipo String es importante por razones de performance, este riesgo se evita haciendo la clase String Inmutable. Al mismo tiempo, String es de tipo final así nadie puede comprometer la inmutabilidad ya sea extendiendo o sobreescribiendo sus comportamientos. Otra razón por la que la clase String es inmutable puede ser debido al uso de HasdMap.
Ya que las variables de tipo String son muy populares como llaves al usar HashMap, es importante que estas sean inmutables de esta manera esas llaves pueden devolver el valor del objeto que se ha almacenado en el HashMap. Ya que HashMap trabaja bajo el principio de Hashing, el cual requiere que el valor se mantenga para funcionar adecuadamente. Un tipo String Mutable, produciría dos diferentes hashcodes al tiempo de la inserción y retorno si el contenido de los Strings fuera modificado después de la inserción, lo que llevaría potencialmente a la pérdida de los objetos valor en el Map.
Si eres un fan del cricket, entonces serás capaz de relacionar mi siguiente frase. El string es VVS Laxman de Java, o sea una clase muy muy especial. No he visto un solo programa de Java que sea escrito sin usar String, Esa es la razón por la cual un sólido conocimiento de String es muy importante para un Desarrollador Java.
La importancia y popularidad de String como tipo de dato, objeto de transferencia y mediador ha lo ha hecho tan popular en entrevistas de Java. ¿Por qué String es inmutable en Java? es una de las preguntas más frecuentemente utilizadas en las entrevistas, lo que inicia con una discusión sobre, qué es String, cómo es la String en Java diferente de String en C y C++, y luego cambiando hacia qué es un objeto inmutable en Java, cuáles son los beneficios de los objetos inmutables, por qué los usarías y en cuáles escenarios los usarías. Entre estas preguntas algunas veces se pregunta, ¿Por qué String es final en Java?.
En una nota similar, si tu te estás preparando para hacer entrevistas sobre Java, te recomiendo que eches un vistazo al libro Java Programming Intervied exposed, un excelente recurso para programadores Java Senior y nivel medio. Ya que contiene preguntas de todos los temas más importantes en Java como multithreading, collections, GC, JVM internals y frameworks como Spring y Hibernate,
Como dije, puede haber múltiples posibles respuestas a esta pregunta, y el único diseñador de esta clase puede responderla con seguridad. Esperaba alguna pista en el libro de Joshua Bloch's Effective Java, pero el tampoco lo mencionó. Yo creo en las siguientes dos razones que tienen mucho sentido de por qué String es una clase hecha Inmutable o fina en Java:
1) Imagina el String pool sin hacer String inmutable, no es posible del todo porque en el caso de que un objeto string contenido en el pool esté referenciado a diferentes referencias de variable, entonces si alguna de ellas cambia el valor, entonces las otras de manera automática se ven affectadas.
Digamos
String A = "Test"
String B = "Test"
Ahora la llamada a String B, "Test".toUpperCase() cambiará el mismo objeto a "TEST". entonces A también será "TEST" lo que no es deseable. Aquí hay un diagrama que muestra como las literales String son creadas en el espacio de memoria y el String literal pool.
2)String ha sido ampliamente utilizado como parámetro para muchas clases de Java, por ejemplo para abrir conexiones de red, tú puedes pasar el hostname y el número de puerto como String, puedes pasar la URL de la base de datos para abrir una conexión o puedes abrir un archivo en Java pasando el nombre del archivo como argumento a las clases I/O de Java.
En el caso de que String no fuera inmutable, esta sería una seria amenaza a la seguridad, quiero decir que alguien podría acceder a cualquier archivo para el cual el tiene autorización y entonces cambiar el nombre del archivo ya sea deliberada o accidentalmente y obtener acceso a ese archivo. Debido a la inmutabilidad, no necesitas preocuparte de ese tipo de amenazas. Esta razón también responde a ¿Por qué String es final en Java? Haciendo final a String, el diseñador de Java se asegura que nadie puede sobreescribir ningún comportamiento en la clase String.
3) Ya que String es inmutable puede ser compartido de forma segura entre varios hilos lo cual es muy importante en la programación multihilos, y para evitar cualquier problema de sincronización en Java. Inmutabilidad, también hace que las instancias String sean thread-safe en Java, eso significa que no necesitas sincronizar las operaciones con String externamente. Otro punto importante sobre String es la pérdida de memoria por Substring, el cual no es un problema relacionado a los hilos, pero es algo de lo que hay que tener cuidado.
4) Otra razón de ¿Por qué String es inmutable en Java? es permitir a String mantener en cache su hashcode, siendo inmutable String en Java mantiene su hashcode en cache, y esto no se calcula cada vez que llamamos al método hashcode de String, lo que lo hace muy rápido de usar como llave en el hashmap de Java. Esto es también sugerido por Jaroslav Sedlacek en los comentarios. En resumen debido a que String es inmutable, nadie puede cambiar su contenido una vez creado lo cual garantiza que el hashcode sea el mismo en diferentes invocaciones.
5) Otra buena razón de Por qué es String Inmutable en Java es la sugerida por Dan Bergh Johnsson en los comentarios: La razón más importante es que es usada por el mecanismo de carga de clases, y de ahí que
***El Artículo fue obtenido de JavaRevisited y fue modificado ligeramente para su traducción. Para revisar el contenido original dar clic aquí.
Por ejemplo, si uno de los clientes cambia el valor del String "Test" a "TEST", el resto de los clientes también verían ese valor como se explicó anteriormente.
Debido a que mantener en memoria los objetos de tipo String es importante por razones de performance, este riesgo se evita haciendo la clase String Inmutable. Al mismo tiempo, String es de tipo final así nadie puede comprometer la inmutabilidad ya sea extendiendo o sobreescribiendo sus comportamientos. Otra razón por la que la clase String es inmutable puede ser debido al uso de HasdMap.
Ya que las variables de tipo String son muy populares como llaves al usar HashMap, es importante que estas sean inmutables de esta manera esas llaves pueden devolver el valor del objeto que se ha almacenado en el HashMap. Ya que HashMap trabaja bajo el principio de Hashing, el cual requiere que el valor se mantenga para funcionar adecuadamente. Un tipo String Mutable, produciría dos diferentes hashcodes al tiempo de la inserción y retorno si el contenido de los Strings fuera modificado después de la inserción, lo que llevaría potencialmente a la pérdida de los objetos valor en el Map.
Si eres un fan del cricket, entonces serás capaz de relacionar mi siguiente frase. El string es VVS Laxman de Java, o sea una clase muy muy especial. No he visto un solo programa de Java que sea escrito sin usar String, Esa es la razón por la cual un sólido conocimiento de String es muy importante para un Desarrollador Java.
La importancia y popularidad de String como tipo de dato, objeto de transferencia y mediador ha lo ha hecho tan popular en entrevistas de Java. ¿Por qué String es inmutable en Java? es una de las preguntas más frecuentemente utilizadas en las entrevistas, lo que inicia con una discusión sobre, qué es String, cómo es la String en Java diferente de String en C y C++, y luego cambiando hacia qué es un objeto inmutable en Java, cuáles son los beneficios de los objetos inmutables, por qué los usarías y en cuáles escenarios los usarías. Entre estas preguntas algunas veces se pregunta, ¿Por qué String es final en Java?.
En una nota similar, si tu te estás preparando para hacer entrevistas sobre Java, te recomiendo que eches un vistazo al libro Java Programming Intervied exposed, un excelente recurso para programadores Java Senior y nivel medio. Ya que contiene preguntas de todos los temas más importantes en Java como multithreading, collections, GC, JVM internals y frameworks como Spring y Hibernate,
¿Por qué String es Final en Java?
Como dije, puede haber múltiples posibles respuestas a esta pregunta, y el único diseñador de esta clase puede responderla con seguridad. Esperaba alguna pista en el libro de Joshua Bloch's Effective Java, pero el tampoco lo mencionó. Yo creo en las siguientes dos razones que tienen mucho sentido de por qué String es una clase hecha Inmutable o fina en Java:
1) Imagina el String pool sin hacer String inmutable, no es posible del todo porque en el caso de que un objeto string contenido en el pool esté referenciado a diferentes referencias de variable, entonces si alguna de ellas cambia el valor, entonces las otras de manera automática se ven affectadas.
Digamos
String A = "Test"
String B = "Test"
Ahora la llamada a String B, "Test".toUpperCase() cambiará el mismo objeto a "TEST". entonces A también será "TEST" lo que no es deseable. Aquí hay un diagrama que muestra como las literales String son creadas en el espacio de memoria y el String literal pool.
2)String ha sido ampliamente utilizado como parámetro para muchas clases de Java, por ejemplo para abrir conexiones de red, tú puedes pasar el hostname y el número de puerto como String, puedes pasar la URL de la base de datos para abrir una conexión o puedes abrir un archivo en Java pasando el nombre del archivo como argumento a las clases I/O de Java.
En el caso de que String no fuera inmutable, esta sería una seria amenaza a la seguridad, quiero decir que alguien podría acceder a cualquier archivo para el cual el tiene autorización y entonces cambiar el nombre del archivo ya sea deliberada o accidentalmente y obtener acceso a ese archivo. Debido a la inmutabilidad, no necesitas preocuparte de ese tipo de amenazas. Esta razón también responde a ¿Por qué String es final en Java? Haciendo final a String, el diseñador de Java se asegura que nadie puede sobreescribir ningún comportamiento en la clase String.
3) Ya que String es inmutable puede ser compartido de forma segura entre varios hilos lo cual es muy importante en la programación multihilos, y para evitar cualquier problema de sincronización en Java. Inmutabilidad, también hace que las instancias String sean thread-safe en Java, eso significa que no necesitas sincronizar las operaciones con String externamente. Otro punto importante sobre String es la pérdida de memoria por Substring, el cual no es un problema relacionado a los hilos, pero es algo de lo que hay que tener cuidado.
4) Otra razón de ¿Por qué String es inmutable en Java? es permitir a String mantener en cache su hashcode, siendo inmutable String en Java mantiene su hashcode en cache, y esto no se calcula cada vez que llamamos al método hashcode de String, lo que lo hace muy rápido de usar como llave en el hashmap de Java. Esto es también sugerido por Jaroslav Sedlacek en los comentarios. En resumen debido a que String es inmutable, nadie puede cambiar su contenido una vez creado lo cual garantiza que el hashcode sea el mismo en diferentes invocaciones.
5) Otra buena razón de Por qué es String Inmutable en Java es la sugerida por Dan Bergh Johnsson en los comentarios: La razón más importante es que es usada por el mecanismo de carga de clases, y de ahí que
***El Artículo fue obtenido de JavaRevisited y fue modificado ligeramente para su traducción. Para revisar el contenido original dar clic aquí.
Suscribirse a:
Entradas (Atom)


