miércoles, noviembre 26, 2008

Impensando acerca de las referencias en Java

Fue hace ya algún tiempo que pase un rato discutiendo con algunos compañeros acerca de si existe o no el paso por referencia; el discurso fue mucho hacia que en Java el comportamiento, en el supuestamente pasamos por referencia un objeto y por valor los objetos primitivos creo mucha polémica.

Para ubicarnos en contexto veamos el siguiente ejemplo.

public static void main(String[] args) {

int value = 10;

changeValue(value);

System.out.println("value = " + value);

User user = new User();
Name name = new Name();

user.setName(name);
name.setName("jsanca");
name.setLastName("XXX");

user.setPassword("123queso");

System.out.println("user: " + user.getName().getName() + ", "
+ user.getName().getLastName() + ", " + user.getPassword());

changeValue1(user);

System.out.println("user: " + user.getName().getName() + ", "
+ user.getName().getLastName() + ", " + user.getPassword());

changeValue2(user);

System.out.println("user: " + user.getName().getName() + ", "
+ user.getName().getLastName() + ", " + user.getPassword());

changeValue3(user);

System.out.println("user: " + user.getName().getName() + ", "
+ user.getName().getLastName() + ", " + user.getPassword());
}


// lost the reference
private static void changeValue3(User user) {

Name name = new Name ();
name.setName("anotheruser");
name.setLastName("somelastname");
user = new User (); // here lost the reference.
user.setPassword("xxxxxx");
}

// change the password, used reference for user object.
private static void changeValue2(User user) {

user.setPassword("654321");
}

// change the name for new name object, used reference for user object.
private static void changeValue1(User user) {
Name name = new Name ();
name.setName("hackuser");
name.setLastName("trocker");

user.setName(name);
}

private static void changeValue(int value) {

value *= 20;
}

Resultado:

value = 10
user: jsanca, XXX, 123queso
user: hackuser, trocker, 123queso
user: hackuser, trocker, 654321
user: hackuser, trocker, 654321

Como se puede notar, cuando pasamos un valor primitivo (llamese entero, carácter, etc) y el valor se modifica en el método, el resultado no se refleja al salir del "scope" del método, de aquí le recomiendo pasar los valores primitivos como final y así se asegura que los programadores no van a tener confusiones.

El segundo y tercero método, consiste en la supuesta referencia y la misma es modificada, la tercera pierde la referencia, pues cuando se realiza un "new" el compilador otorga una nueva casilla de memoria, perdiendo totalmente la referencia pasada por parámetro.

Si analizamos, por ejemplo C++, cuando una variable inclusive nula, se le pasa &miVar en un parámetro, realmente pasamos un referencia, pero esto sucede porque en C++ la memoria es gestionada por los programadores, al contrario de Java, donde es tarea del Garbage Collector; en C++ existen los punteros, así como las instrucciones new y delete o free y malloc en el caso de C, pero en Java no existen los punteros, por lo que discutir acerca si el paso por referencia es estrictamente igual que el que esperamos en C++ no tiene sentido, pues la referencias pueden solo existir en un lenguaje con soporte de punteros, al no tener Java esta característica, en realidad no existe el paso por referencia, solo podemos concluir que Java no cambia los datos primitivos en una función, pero puede cambiar las propiedades de un objeto siempre y cuando el objeto en si, no sea cambiado, es decir que no suceda como en el método "changeValue3()" donde se le realiza un "new" al objeto pasado por parámetro.

La unica excepción a esta regla, la podemos encontrar en el contexto de RMI, donde todos los objetos así como los primitivos son pasados por valor (por razones obvias de perfomance), aunque extendiendo una interface se le puede indicar que esta variable debe ser sincronizada entre el cliente y el server, es decir que se pase una referencia al estilo de Java.

13 comentarios:

Carlos P. dijo...

En realidad los punteros son de alta importancia en Java, ya que sólo primitivos no son lo son, y esto da la apariencia de que no existen.
Los punteros simplemente se declaran de manera implícita, en otras palabras, comparando de manera simplista con C++, es similar a decir que el “*” viene incluido.
Otra cuestión es que en Java todos los argumentos son pasados por valor.
Vamos a ver a continuación que todos los no primitivos tienen todas las características y el comportamiento de punteros.

Una de las características es que requiere la asignación de memoria ó la asignación a nulo.
Ej:

UnaClase unaClase1 = null;
UnaClase unaClase2 = new UnaClase();

En C++ equivale a:
UnaClase * unaClase1 = null;
UnaClase * unaClase2 = new UnaClase();

En C++ se podría hacer una instancia a una clase sin asignación de memoria dinámica:
Ej: UnaClase a;
a.setValue(20);

Lo anterior no se puede hacen en Java.

Veamos los siguientes ejemplos para mostrar porqué los argumentos se pasan por referencia y no por valor (indistintamente del tipo):

public void swap (int a, int b){
int temp = a;
a = b;
b = temp;
}

public void swap (UnaClase a, UnaClase b){
UnaClase temp = a;
a = b;
b = temp;
}

Suponiendo que en el segundo caso se pasan los argumentos por referencia, “a” y “b” se verían intercambiados, pero no sucede. En el siguiente ejemplo de C++ hacemos lo mismo pasando los argumentos por referencia:

void swap (UnaClase &a, UnaClase &b){
UnaClase temp = a;
a = b;
b = temp;
}

“a” y “b” en efecto son intercambiados, lo cual no se dio en los ejemplos de Java. En realidad análogamente lo que ocurre en Java es esto:

void swap(UnaClase *a, UnaClase *b){;
UnaClase *tmp = a;
a = b;
b = tmp;
}

Alguien dirá ¿Y entonces porqué se modifican las propiedades? Eso significaría que es por referencia.

La respuesta es No. No necesariamente porque se modifiquen las propiedades significa que sea el argumento haya sido pasaoo por referencia. Veamos:

public void changeValue (UnaClase a){
a.setValue(15);
}

Ahora, con el comportamiento análogo mostrado anteriormente para C++ se da esto:

void changeValue(UnaClase *a, UnaClase *b){;
a->setValue(15);
}

La propiedad en efecto se ve modificada en ambos casos, aunque en el segundo ejemplo el argumento fue pasado por valor.

En los ejemplo de C++ cuyos comportamientos son los mismos en Java, los argumentos son punteros pasados por valor, y no se puede atribuir el mismo comportamiento que tendrían si se pasaran por referencia.

Carlos P. dijo...

Por cierto, me gustaría también aclarar que si bien hay punteros, el modelo en Java es distinto al de C++, ya que no es físico y Java mismo gestiona el uso de memoria y no el programador, por lo que sólo se pueden usar para hacer referencia a objetos y no manipularse para apuntar a direcciones cualquiera en memoria.
Yo diría que son punteros seguros.

jsanca dijo...

Me parece que asegurar que un objeto en Java es un puntero es muy apresurado. Insisto que en Java no existen los punteros, cosa diferente a C#, donde se puede utilizar el keyword "ref" para pasar una refencia y además existe la posibilidad de utilizar segmentos no seguros.
Como describe el articulo, los objetos en Java se comportan de cierta forma cuando se pasan por parametro.

jsanca dijo...

Es tan valido decir que en Java existen los punteros, como que en ActionScript existen los hilos, puede que la implementación utilice hilos para renderizar cosas, etc, pero el lenguaje no soporta hilos, como tal, asi como Java no soporta punteros y sin punteros el paso por referencia, no tiene sentido.

Carlos P. dijo...

El uso de los punteros es más limitado en Java y además son implícitos, sin embargo eso no los hace inexistentes o irrelevantes.

Anteriormente se vio que el comportamiento de los no primitivos es igual a de los punteros usados como referencia a objetos en C++.

Sobre si son relevantes o no, eso depende. Son relevantes para mí. Jajaja. El tema ayuda a comprender el comportamiento de las referencias y de los métodos en Java. Conozco varia gente que no sabía que no se puede hacer un void swap(a,b) en Java. También permite entender la simpleza del asunto, sin suposiciones complicadas de que el JVM hace esto para los primitivos o aquello para los objetos.

Sobre los hilos en ActionScript, existe una forma de manejo de hilos primitiva que es el setTimeOut(), el cual funciona para crear un hilo de ejecución, pero que no tiene “yield”, “stop”, “wait” o “sleep”. Suponiendo que no existe el setTimeOut() en ActionScript, la analogía sobre hilos en AS y punteros en Java no aplica de la misma manera. No se puede inferir el comportamiento de los hilos como tales ni decir con certeza qué es un hilo y qué no es un hilo a partir del modelo de ActionScript, ni siquiera a nivel de eventos. A cambio en Java, sí se puede inferir el comportamiento de los punteros como tales, tal es el caso de los ejemplos descritos en mi primera aportación.

jsanca dijo...

Carlos si los punteros existieran en Java uno podría:

1 - Asignar memoria.
2 - Borrar memoria.
3 - Hacer un puntero a función.
4 - Hacer un puntero a algo.
5 - Hacer referencias.
6 - Un podría conocer la posición de memoria donde se encuentra almacenado, el objeto, etc.

De estas, la unica que se cumple, podriamos decir que es la primera. Y que la segunda, que la maneje el GC, no tiene nada que ver, no hay punteros, usted puede decir que medio se parece, pero en JavaScript medio parece que los pseudo objetos son OOP, pero no existe herencia, polimorfismo, encapsulación, por lo tanto no es un lenguaje orientado a objetos, como si lo es C# o Java. Tampoco hay hilos en JavaScript o AS, por que podes hacer bloqueos, notificaciones, dormir hilos, etc. El setTimeOut, es simplemente un rutina que hacer algo "parecido" a un Hijo, pero usted no lo maneja.
Basandome en esa analogia, no hay punteros en Java, por lo tanto no existe los pasos por referencia, por lo tanto uno tiene que tener en cuenta, cual sera el comportamiento esperado al pasar primitivos o objetos, a una función, tal como lo dice el articulo.

jsanca dijo...

Por ejemplo veamos un lenguaje como C++, que cuenta con punteros y referencias, a diferencia de Java que no los tiene:

#include <cstdlib>
#include <iostream>

using namespace std;

void frefence(int* i);
void fvalue (int i);

int main(int argc, char *argv[])
{

int i = 2;
fvalue(i);
cout << i << endl;
frefence(&i);
cout << i << endl;
cin >> i;
return EXIT_SUCCESS;
}

void frefence(int *i) {

*i *= 2;
}

void fvalue (int i) {

i *= 2;
}

Resultado
2
4

Esto no se puede lograr con Java.

Gabriel S. dijo...

Mi humilde opinión es que podrían haber dos preguntas, qué comportamiento vemos nosotros como programadores cuando pasamos nuestros parámetros a las funciones? y cómo se implementa por debajo? Si yo paso un objeto a una función y esta misma la modifica y cuando regresa ha cambiado, pues para mi es por referencia. Y si paso un valor primitivo y cuando regresa no ha cambiado aunque la función lo haga, para mi es por valor. Los detalles de cómo lo hace por debajo el lenguaje podrían o no ser relevantes pero igual el comportamiento que ve el programador es el que vale.

David Chang dijo...

Desde una perspectiva práctica comparto lo que dice Gabriel, existen mecanismos que se comportan similar o iguales a los ojos del programador (sin importar lo que hagan por debajo) y eso es lo que cuenta a la hora de trabajar.

Desde una perspectiva teórica los punteros son variables que contienen direcciones de memoria y permite acceder a su contenido, y lo usamos usualmente para referenciar a "algo"... tomando en cuenta esto en el caso de un lenguaje administrado cualquier objeto tiene que tener un ID o algo que lo identifique en el VM (llamese JVM o CLR) y en mi opinion podriamos llamar ese ID/referencia como un "managed pointer", independientemente de que en el lenguaje de alto nivel haya muchos o pocos mecanismos para manipularlos.

jsanca dijo...

Excelente chino, sería cool que nos regalaras una pequeña introducción a los pases por referencia en C# y si no es mucho pedir, los puntos a tomar en cuenta, en los segmentos de código no seguros.

David Chang dijo...

Pura vida Jon, normalmente es muy similar a Java. De hecho a nivel de MSIL (que es el codigo intermedio q corre el CLR de .NET), entre los tipos de datos q maneja existe el "managed pointer" (indicado con el simbolo & en IL-DASM) y el "unmanaged pointer" (indicado con el simbolo * en IL-DASM).

Normalmente en C# pasamos el valor (como Java), de modo que el siguiente codigo:

int a = 2;
int b = 2;
swap(a, b);

Aparte del hecho de que no funciona, se compilaría a algo asi en MSIL (los comentarios los agrego para explicar el codigo):

.maxstack 3 //crea una pila para 3 datos
.locals init ([0] int32 a, [1] int32 b) //crea las variables locales a y b de tipo int32
IL_0000: nop
IL_0001: ldc.i4.2 //carga 2 a la pila como entero de 4 bytes
IL_0002: stloc.0 //carga de la pila a la variable local 0
IL_0003: ldc.i4.2 //carga 2 a la pila como entero de 4 bytes
IL_0004: stloc.1 //otro "STore LOCal" pero a la variable 1
IL_0005: ldarg.0 //podemos ignorar esta instruccion por ahora
IL_0006: ldloc.0 //carga el valor de la variable 0 a la pila
IL_0007: ldloc.1 //"LoaD LOCal" pero de la variable 1
IL_0008: call instance void Prueba.Form1::swap(int32,
int32)

IL_000d: nop
IL_000e: ret

Si cambiamos el codigo usando "ref":

int a = 2;
int b = 2;
swap(ref a, ref b);

Este seria el MSIL resultante:

.maxstack 3
.locals init ([0] int32 a,
[1] int32 b)
IL_0000: nop
IL_0001: ldc.i4.2
IL_0002: stloc.0
IL_0003: ldc.i4.2
IL_0004: stloc.1
IL_0005: ldarg.0
IL_0006: ldloca.s a //hace un LoaD LOCal Address
IL_0008: ldloca.s b
IL_000a: call instance void Prueba.Form1::swap(int32&,
int32&) // usar los managed pointers de un int32

IL_000f: nop
IL_0010: ret

Osea efectivamente en .NET la variable pasa por referencia, y eso es soportado por el CLR sin truco raros.

jsanca dijo...

Excelente comentario Chino!

Jorge Eduardo dijo...

En este link esta claro y es de sun, y se menciona que todos los parametros se pasan por valor, inicializando copias nuevas de cada uno ya sean estas valor primitivos o objectos compuestos, por lo tanto si hay punteros en java.

http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#37472