#89 Tener la sesión abierta desde el principio hasta el final puede provocar que el servidor de bd te la cierre mientras que no le envías nada(dependiendo del server y de la config) de todas maneras, mientras no necesitas hacer consultas, no tiene sentido tener memoria ahí al tuntún.

Yo suelo abrir conexión por cada grupo lógico de consultas que puede ir en conjunto con una o varias transacciones dependiendo del caso. Abrir conexión para cada consulta puede ser contraproducente, piensa que por cada consulta habrá 2 mensajes que se manden al server por haber abierto y cerrado la sesión, así que bueno.. ya te puedes imaginar como se pondría la red para apps con muchas consultas XD. Además que abrir y cerrar sesión por cada consulta es perder el concepto de transacción y no podrás hacer rollbacks en caso de error.

#91 #92 Muchas gracias por la respuesta a los dos

Ahora me viene otra duda.

Tengo un Thread en una clase que lo que viene siendo es un cronómetro (una clase visual) y que tiene un botón.

Cuando ese botón se pulsa el Thread se pausa y se abre otro frame que tiene una Progressbar con otro Thread.

Ahora bien, cierro el frame que creo ¿cómo puedo reanudar el primer Thread?

He intentado metiéndole el método cuando el frame hace el dispose pero obviamente como esa clase no es la que lleva el Thread está un tanto complicado...

#94 me estoy empezando a enamorar de tus explicaciones x'DDD Muchas gracias... este tipo de cosas nos las tendrían que haber enseñado en el ciclo x'DDD

#95 estoy mirando, ahora mismo lo detengo con un interrupt (crono.interrupt(); sería en este caso)

Como si no pusiera nada

#94 pausa por polling = mala idea. MUY MALA IDEA xD

#95 wait y notify son tus amigos.

EDIT: vale, veo que en #96 comentas wait y notify.

#100 No llego a entenderlo demasiado bien, he de crear una mini aplicación para que cargue todos los bundles, que son los .jar (plugins), y cada bundle tiene un start() que es lo que se inicia cada vez que arranca, no?

Buenas. Tengo una duda más bien genérica de Java y casi del resto de lenguajes.
Según me dicen los profesores, lo mejor es tenerlo TODO separado por métodos (incluso me han dicho que no superen las 9 - 12 lineas cada método).
Divide y vencerás, tiene su lógica, pero también pienso que puede que sea más lento, menos optimizado, al tener que estar haciendo constantes llamadas a métodos externos y clases.
Llevo tiempo aprendiendo pero todavía me faltan muchas cosas por asimilar, espero que me podáis aclarar esta en particular.

#104 Gracias por la aclaración, realmente lo necesitaba y no me importa si alguien quiere alargar la explicación 400 líneas más, me lo leeré encantado.
Lo del límite de líneas me imagino que me lo dijeron simplemente para hacerme ver que no se deben hacer métodos muy largos.
Hay alguna diferencia notable entre tener una clase y 25724 métodos en ella y tener 25724 clases y un método en cada una?
El programa puede perder funcionalidad? Qué es mas adecuado?
Pongo extremos para que se entienda mejor la pregunta.

Tengo una clase que contiene un método que crea un frame y le da la información básica (tamaño, titulo, setBounds, resizable, visible y exit_on_close).
Hay forma de dibujarle gráficos desde el método paint(Graphics g) estando este en otra clase?

#105 : No te compliques con lo de los métodos y las clases. Cada clase tendrá los métodos que les correpondan. Una puede tener uno o dos y otra quince.

Creo que es imprescindible que el la clase que contiene paint(Graphics g) herede de alguna clase gráfica de Java para que el JFrame pueda utilizar lo que pongas en el paint.

Por otro lado no entiendo bien porqué creas una clase que hereda de JFrame y luego le pones un JFrame jf con un método estático que le mande a ese método que se inicialice y recoja al objeto DefaultGraphics df: puedes hacerlo todo con un método window(DefaultGraphics) de HeliFrame que haga todo eso para sí mismo; no sé si me explico. En cualquier caso yo he hecho este código a partir del tuyo; en principio a mí me compila y hace lo que quiero que haga:



el Jframe



El JComponent/DefaultGraphics


la clase con main:


Es la primera vez que pego código en el foro así que si el formato sale horrible o no sale nada no quiero saber nada

#112 : http://docs.oracle.com/javase/1.4.2...lang/Thread.html

#114 comorl? X no está apuntando a Y, es al revés :S

Tu main "desenrollado", sin llamar a doStuff:

x.add("3");
x.add("7");
x.add("5");
// Aquí viene la llamada a doStuff(x)
x.add("9");
List<String> y = x;
y.add("1");

Que eliminando la asignación superflua queda como:

x.add("3");
x.add("7");
x.add("5");
x.add("9");
x.add("1");

No sé qué es lo que no entiendes xD ¿Cuál de los dos pasos previos de "simplificación" es el que te parece raro?

PD: En Java, todo tipo que no sea basico (los que empiezan por minúscula, i.e. int, char, boolean, etc.) se pasa por referencia. SIEMPRE. Hay gente que te discutirá esto por cuestiones semánticas, pero me da igual.

#116 sigo sin entender qué es lo que no ves. ¡VETE A DESCANSAR HOMBRE! xD

Para que lo veas bien, doStuff bien podría ser un método estático que haría lo mismo. No estás accediendo a miembros, ¿qué más dará a qué haga referencia?

List<String> y = StaticMyPancake.doStuff(x);

doStuff recibe un argumento y devuelve ese mismo argumento con "9" añadido. ¡No toca miembro alguno!

Aparte, no estás guardando un objeto MyPancake sino un List<String>, el que devuelve la llamada a (new MyPancake()).doStuff(x)

---

#116 En efecto, esa es la explicación a la que siempre hace alusión la gente. UNA MIERDA En Java el paso de hijos de Object es por referencia.

Por eso al pasar a una función como argumento un objeto, pasamos la referencia al mismo
Osea que dice que no está pasando por referencia, y tan pancho añade pasamos la referencia al mismo. ¡Qué calidad!

La única excepción es la clase String , cuyos objetos no son mutables. Cualquier modificación de un objeto String lleva aparejada la creación de una nueva instancia del objeto.
Esto ya es retarded total. Que el objeto sea inmutable hace que se convierta mágicamente en... ¿qué exactamente?

Ese texto lo he visto cientos de veces ya y nunca entiendo la argumentación que hace.

En realidad, el tío entendió mal que en Java el paso es por "valor de referencia", es decir, que es el valor de un puntero C de toda la vida, un int pusheado a la pila con un valor concreto... La historia es que en Java tú no puedes cambiar el valor del puntero (¡sólo el valor al que apuntan las variables locales que referencian los argumentos!) mientras que en C/C++ sí, de ahí que la gente se invente estas mamonadas de discusiones semánticas.

Te redirijo a http://stackoverflow.com/questions/...ass-by-reference donde en efecto, se enteran más (y explican mejor) que el menda este que siempre aparece en Google xD

I believe that much of the confusion on this issue has to do with the fact that different people have different definitions of the term "reference". People coming from a C++ background assume that "reference" must mean what it meant in C++, people from a C background assume "reference" must be the same as "pointer" in their language, and so on. Whether it's correct to say that Java passes by reference really depends on what's meant by "reference".

Más y mejor: http://stackoverflow.com/questions/...y-reference-mean

---

#116 De todas formas, vaya peligro. Lo suyo es que hubiera un indicador previo al objeto que se pasa. Pero claro, como no hay punteros...
¿Ein? ¿A qué te refieres con indicador previo?

Aún así, en Java si hay punteros. Otra cosa es que tú no lo veas, pero prueba a hacer:

String prueba = null;
prueba.charAt(0);

Obtendrás un bonito NullPointerException.

#118 es decir, como el ByRef y ByVal de VB. Eso son "qualifiers", cualificadores, a falta de un término mejor.

Para aclararte, piensa que en Java todo es como si viniese ByVal (de ahí lo de paso-de-referencia-por-valor), es decir, el comportamiento es el mismo que en VB sin cualificar.

Lo que falta para acabar con estas discusiones semánticas es terminología clara, porque en estas discusiones siempre se mezcla la implementación del paso y del objeto. La cuestión viene porque en C los pasos por referencia los hace por indirección (son básicamente lo mismo, con una sintaxis más tersa.)

paso-de-valor-por-valor (C sin punteros y los tipos unboxed en Java)
paso-de-referencia-por-valor (Java e indirección C, *)
paso-de-*-por-referencia (operador & en C)

De hecho yo a Java le llamaría, para ser propios, paso por indirección (y le podría dar la razón en ese caso a los que dicen que NO es paso por referencia.)