🚀 go-pugleaf

leonardoazpurua@cantv.net escribió:
> El asunto es que estoy comenzando con Java, practicamente desde cero.
> 
> Programo para ganarme la vida desde 1972, y llevo anhos dandole a la
> OO, de manera que eso no deberia ser problema. Pero durante los
> ultimos anhos he estado encerrado en la "burbuja MS", de donde me
> sacaron a fuerza de innovaciones: uno no puede pasarse la vida
> aprendiendo cosas nuevas cada vez que a una empresa se le ocurre
> "relanzar" sus tecnologias y romper la compatibilidad con todo.
> 
> La primera pregunta es cuan estable es Java: para quienes llevan
> tiempo con el lenguaje, ha habido cambios en los cuales el codigo de
> una version (digamos de la 1.1) haya presentado problemas al
> compilarse sobre una version posterior (1.4, por ejemplo)?


Yo no llevo mucho tiempo, así que aquí no puedo darte mucha
información. Sí te puedo decir que me hice cargo de un proyecto
open-source basado en Java 1.4 y de momento lo he compilado con Java
1.5 sin problemas; ahora lo probaré con la 1.6. También sé que, cuando
cambian algo, lo que suelen hacer es marcar la manera vieja de hacerlo
como "deprecated" y la mantienen al menos una versión para dar tiempo
a cambiarlo. Pero, como te digo, no tengo mucha experiencia, y podría
ser que otras personas con más experiencia te cuenten casos en los que
no haya sido así.


> 
> La segunda: he estado evaluando algunos IDE gratuitos: el Studio One
> de Sun, el JBuilder Foundation de Borland y recientemente NetBeans
> 5.5. Este ultimo me gusta, pero he leido muchas criticas y oposicion
> al uso de IDEs en general. Me gustaria escuchar algunas opiniones al
> respecto.


Ahora mismo, las opciones son dos en la práctica: Eclipse y NetBeans.
También hay otros, como JDeveloper (de Oracle, gratuito, creo) e
IntelliJ (de pago), pero son más bien nichos de mercado. JBuilder está
muerto en cuanto a desarrollo, por lo que sé, y Sun está convirtiendo
NetBeans en el IDE de referencia; hasta en los tutoriales genéricos de
Java lo usan para explicar muchas cosas.

Que haya dos IDEs importantes quiere decir, inevitablemente, que hay
una guerra religiosa. :-) Que yo sea de la fe de NetBeans puede
afectar a mi opinión, y quizá a mis fuentes (leo sobre todo blogs de
gente que trabaja en NetBeans), pero si son tan objetivos como
parecen, entonces el editor de Eclipse es aún algo mejor (la distancia
se reducirá mucho con NB 6.0) y en el resto, NetBeans parece ganar por
goleada: facilidad de instalación y configuración (yo lo sufrí con
Eclipse), simplicidad de conceptos (yo lo sufrí con Eclipse), y
mejores complementos de diseño UML, SOA, BPEL y J2ME.

Donde Eclipse parece tener también un punto a favor es si pretendes
trabajar con múltiples lenguajes a la vez: NetBeans es, sobre todo,
Java, aunque tiene un pack para C/C++ y están incorporando soporte de
Ruby, Groovy y otras cosas raras de esas. :-) Pero Eclipse parece
mejor si pretendes usar PHP a la vez que Java, por ejemplo.

En cualquier caso, como son gratuitos, puedes probar los dos (si
tienes buen ancho de banda, claro) y decidir. Un consejo: no olvides
descargar algunos plugins/complementos de cosas que pienses que vas a
querer usar. La dificultad de configuración de plugins en Eclipse (y
muchas funcionalidades de Eclipse están basadas en plugins) parece ser
un problema creciente, y ya fue uno de los factores por los que me
decidí por NetBeans hace un año y pico.


> La tercera: como programador "viejo", se me hace mucho mas facil
> adaptar mis recursos al lenguaje que adoptar recursos preexistentes.
> En algun lugar de toda la documentacion que he estado revisando los
> ultimos dias (creo que en la pagina de descarga del JDBC para MySQL)
> recomiendan no utilizar directamente el JDBC, sino utilizarlo a traves
> de alguna libreria de persistencia (mencionan Hibernate, entre otras).
> Es esto realmente indispensable? El codigo de ejemplo basado en JDBC
> es aparentemente simple. Hay algun tipo de dificultad no evidente que
> pueda saltar en algun momento futuro?


¿Es realmente indispensable? En modo alguno. ¿Hay dificultades no
evidentes? Si vienes del mundo MS, puedes encontrar algunas. En Java
no existen los controles gráficos "data aware". Es decir, pones un
ComboBox en un formulario y, a diferencia de lo que tenía VB la última
vez que lo miré, no tienes un par de propiedades con las que decirle
que recoja su contenido de una consulta SQL o tabla de una base de datos.

En su lugar, Java tiene el concepto de "modelos". Si sabes mucho de
OOP, conocerás el patrón M-V-C (modelo, vista y controlador). En Java
es más bien M-VC. Básicamente, consiste en que el tratamiento de los
datos (M) se gestiona por clases totalmente separadas de las que
gestionan la visualización y entrada de los datos (V) y las que
controlan esa visualización y entrada (C). Por cierto, creo que
Microsoft lo mezcla con cierta alegría en .NET. :-)

Bien, el caso es que cada control gráfico en Java tiene una propiedad
"model" que permite escribir ahí un objeto que sirva como modelo. Java
tiene interfaces que definen lo que tiene que tener una clase para
poder actuar como modelo de un control, y clases (abstractas y
concretas) que implementan total o parcialmente esos interfaces.

A partir de aquí, si tienes un JList (una lista, o "una tabla de una
columna", si lo prefieres) que tiene que tomar sus datos de una tabla,
si no utilizas un framework ORM como JPA o Hibernate, tienes que
asegurarte tú mismo de ejecutar las consultas y cargarlas en clases
modelo, y sobre todo, tienes que asegurarte de que cuando cambien los
datos en la tabla podrás detectarlo y reflejarlo en la lista.

En cambio, un framework ORM lo que hace es "atar" tus clases POJO
(Plain Old Java Objects, un acrónimo pomposo para decir que son clases
normales que no tienen que implementar un interfaz concreto) a tablas
en la base de datos, y mediante métodos específicos, carga las filas
de consultas SQL como listas de objetos, ocupándose además si
modificas propiedades de alguno de esos objetos de actualizar la base
de datos subyacente.

Aparentemente, no hay discusión posible: si no usas un ORM, estás
muerto. En cambio, yo de momento no quiero usarlo. :-) ¿Por qué?
Porque, a mi juicio, el ORM oculta tanto de JDBC que siento que pierdo
el control de si los objetos con los que trato en el programa afectan
a los datos en la base de datos o no. Introduce, además, un montón de
conceptos nuevos, y como soy un poco novato, ya me sobran conceptos
que asimilar.

Algunos de los problemas que te he contado antes también están
parcialmente solucionados con las APIs estándar. Por ejemplo, el
paquete javax.sql.rowset define interfaces (e implementa una clase de
referencia) que los proveedores de drivers JDBC pueden (¿deben?)
implementar y que es capaz de lidiar más fácilmente con
actualizaciones en la base de datos hechas por otra instancia de tu
programa, como sería el caso en entornos multiusuario.

Así que yo, particularmente, de momento no quiero usar un ORM. Si te
haces muy deprisa a Java, y dado que tienes mucha más experiencia de
trabajo con OOP, quizá te lo debas plantear.


> La cuarta: hay muchos comentarios acerca de la estabilidad de Swing en
> los entornos multihilos. Todos los ejemplos en el tutorial ejecutan
> los Frames en un thread independiente.


Ojo, esas dos cosas no tienen nada que ver. De hecho, yo no he leído
nada sobre la estabilidad de Swing. Swing se ejecuta en un thread
independiente para que la gestión de sus eventos no afecte a la
respuesta de la interfaz gráfica, y cada proceso de duración
apreciable debería lanzarse como una tarea independiente haciendo que
la clase que inicia el proceso implemente Runnable, o bien extienda
Thread, a menos que efectivamente quieras que el programa "se bloquee"
para que el usuario no haga nada mientras se realiza dicho proceso.


> Si abro varias ventanas
> simultaneamente, debe abrir un thread para cada una de ellas, o
> bastara con el thread principal (el del frame creado desde Main)?


Depende de si cada ventana tiene procesos interactivos que requieren
cierto tiempo. Por ejemplo, si en cada ventana se cargan
constantemente imágenes actualizadas desde una web que se bajan
comprimidas y hay que descomprimirlas con su coste de CPU antes de
poder mostrarlas, probablemente quieras varios threads, porque si no,
lo más fácil es que una de ellas funcione constantmente mientras la
otra se queda bloqueada. Pero, seguramente, esos threads no se usarán
realmente para pintar las ventanas y responder a pulsaciones en los
botones que contengan, sino para recuperar los datos de Internet,
descomprimirlos y asignarlos a los controles gráficos de las ventanas.

En términos generales, suele ser suficiente con un thread separado
para la interfaz gráfica de un programa de gestión.


> 
> Gracias de antemano por las respuestas, y ya seguire molestando.
>


Espero no haberte liado demasiado, y bienvenido al grupo. :-)

Saludos.

-- 
If it's true that we are here to help others,
then what exactly are the OTHERS here for?

On 7 Apr 2007 17:20:21 -0700, leonardoazpurua@cantv.net wrote:

>El asunto es que estoy comenzando con Java, practicamente desde cero.
>


Hola Leonardo, me alegro de leerte, espero que est�s bien ;-)

Lamentablemente no puedo ayudarte en lo que preguntas, porque
yo apenas he usado java, ahora trato de hacer un midlet para
un telefono movil, nada m�s.

Finalmente estoy usando netbeans (con el add-on Mobility),
no se si proporciona ayuda sensible al contexto pulsando F1, 
pero tal como vas escribiendo c�digo aparece una peque�a ventana 
de ayuda, adem�s de la funcion autocompletar al estilo de vb,
que funciona muy bien.

Lo de no usar un IDE creo que va m�s bien porque el IDE te
resuelve una serie de cosas, y si solo has programado as�
nunca las aprendes, pero total para lo que hay por debajo 
(solo javac) tampoco se pierde uno tanto, en C ser�a mucho
m�s importante aprender a compilar a mano, y nadie lo hace.

>(a pesar de que si me regalaron la Suscripcion Universal a MSDN)

  Y a pesar de todo microchof no fu� a la ruina, lo cual demuestra
que no era tan dificil tratar bien a la gente que les hace el trabajo 
gratis ;-) 

Saludos :-)           -Pedro-

  http://www.maicas.net/ 

  e-mail en www.maicas.net

Ricardo Palomares Martinez escribió:

Me corrijo en algunas cosas que, al releer mi mensaje, veo un poco
confusas...

> Yo no llevo mucho tiempo, así que aquí no puedo darte mucha
> información. Sí te puedo decir que me hice cargo de un proyecto
> open-source basado en Java 1.4 y de momento lo he compilado con Java
> 1.5 sin problemas; ahora lo probaré con la 1.6. También sé que, cuando
> cambian algo, lo que suelen hacer es marcar la manera vieja de hacerlo
> como "deprecated" y la mantienen al menos una versión para dar tiempo
> a cambiarlo.

...quería decir "para dar tiempo a los que programamos en Java a
cambiarlo en nuestro código fuente, dejando de usar lo anticuado y
pasando a usar lo nuevo".


> 
> En cualquier caso, como son gratuitos, puedes probar los dos (si
> tienes buen ancho de banda, claro) y decidir.


Lo del ancho de banda es porque cada IDE puede superar fácilmente los
100 MBytes de descargas en cuanto incluyas algún plugin/complemento.
Te aconsejo que NO descargues el bundle JDK+NetBeans si no pretendes
tener un JDK específico para programar; a algunos les ha dado
problemas al intentar actualizar el JDK sin actualizar el entorno.


> A partir de aquí, si tienes un JList (una lista, o "una tabla de una
> columna", si lo prefieres)

una lista *en pantalla*, o "una tabla *en pantalla* de una columna"

> que tiene que tomar sus datos de una tabla,

...de una tabla *de base de datos*


> si no utilizas un framework ORM como JPA o Hibernate, tienes que
> asegurarte tú mismo de ejecutar las consultas y cargarlas en clases
> modelo, y sobre todo, tienes que asegurarte de que cuando cambien los
> datos en la tabla podrás detectarlo y reflejarlo en la lista.

...cuando cambien los datos en la tabla *de base de datos* por otros
usuarios accediendo simultánemanete a la misma, podrás detectarlo y
reflejarlo en la lista *en pantalla*.


> 
> Aparentemente, no hay discusión posible: si no usas un ORM, estás
> muerto. En cambio, yo de momento no quiero usarlo. :-) ¿Por qué?
> Porque, a mi juicio, el ORM oculta tanto de JDBC que siento que pierdo
> el control de si los objetos con los que trato en el programa afectan
> a los datos en la base de datos o no. Introduce, además, un montón de
> conceptos nuevos, y como soy un poco novato, ya me sobran conceptos
> que asimilar.


Como ejemplo, si usas Hibernate y recuperas datos de una tabla en
forma de objetos, si cambias un dato de alguno de esos objetos y luego
cierras la sesión (no recuerdo el nombre exacto que le dan al concepto
de sesión, creo que no es transacción), lo que has cambiado en ese
objeto en memoria se traslada a la base de datos. Eso está muy bien si
sólo cambias una cosa, pero implica que tienes que llevar mucho
cuidado con qué objetos tocas en memoria, porque quizá algunos datos
podrían trasladarse a la base de datos sin que realmente quisieras
hacerlo. No hay un "UPDATE este registro que te digo yo", sólo un
"vaya, voy a cambiar esta propiedad de este objeto un momentito en
memoria y ahora voy y cierro la sesión; ¡mierda, ya lo he grabado sin
querer en la base de datos!". Al menos, éste es mi temor.

Saludos.

-- 
If it's true that we are here to help others,
then what exactly are the OTHERS here for?

leonardoazpurua@cantv.net escribió:
> La segunda: he estado evaluando algunos IDE gratuitos: el Studio One
> de Sun, el JBuilder Foundation de Borland y recientemente NetBeans
> 5.5. Este ultimo me gusta, pero he leido muchas criticas y oposicion
> al uso de IDEs en general. Me gustaria escuchar algunas opiniones al
> respecto.


Había leído mal tu duda (creí que eran críticas y dudas al uso de
NetBeans en concreto). Sobre las críticas y oposición al uso de IDEs
en general, o quien las hace es un fundamentalista, o lo dijo con
matices. El problema de los IDEs es, como dice Pedro, que te ocultan
una serie de cosas, y nunca las aprendes.

Discrepo con Pedro, no obstante, en que lo que hay por debajo "sólo
sea javac"; también hay cuestiones relativas al empaquetado, a la
ejecución desde la línea de órdenes, y (muy importante) al uso de Ant,
que es como el make de Java.

Sí que creo, no obstante, que acometer un proyecto que vaya más allá
de los simples ejemplos sin el apoyo de un IDE es una locura. En
particular, hasta que me acostumbré a usar NetBeans bien me
desesperaba seguir la cadena de dependencias entre clases e
interfaces. Si tenía una clase definida así:

public class Class1 extends Class0 implements Interface1, Interface2 {
...
}

public class Class0 extends ClassAbstract0 implements Interface3 {
...
}

cuando luego veía esto otro:

Class1 myObject;

myObject.methodX();

me volvía loco hasta encontrar la definición del método methodX, que
podía estar en Class1, Class0 o ClassAbstract0, y cuyo significado
podía estar descrito o no en Interface1, Interface2 o Interface3. Si,
además, alguna de las clases de la cadena es parte de la API, con lo
cual no tienes su código fuente, sino sólo el Javadoc, ya es para
volverse loco a menos que te apoyes en un IDE, que te dice esas cosas
de manera mucho más clara (seleccionas el nombre del método y botón
derecho, opción GoTo -> Source o GoTo -> Declaration, o bien Find
Usages, según los casos). Seguro que nadie pensaba que GoTo fuera a
ser tan útil en un lenguaje OOP como Java. :-P

Saludos.

-- 
If it's true that we are here to help others,
then what exactly are the OTHERS here for?

On 8 abr, 12:55, Ricardo Palomares Martinez <rpm.PU...@iespana.es>
wrote:

> Yo no llevo mucho tiempo, así que aquí no puedo darte mucha
> información. Sí te puedo decir que me hice cargo de un proyecto
> open-source basado en Java 1.4 y de momento lo he compilado con Java
> 1.5 sin problemas; ahora lo probaré con la 1.6. También sé que, cuando
> cambian algo, lo que suelen hacer es marcar la manera vieja de hacerlo
> como "deprecated" y la mantienen al menos una versión para dar tiempo
> a cambiarlo. Pero, como te digo, no tengo mucha experiencia, y podría
> ser que otras personas con más experiencia te cuenten casos en los que
> no haya sido así.

En cualquier caso, no creo que llegue a la locura de MS. Ya tengo una
edad en la que no quiero volver a redisenhar nunca mas un proyecto
grande.

> Ahora mismo, las opciones son dos en la práctica: Eclipse y NetBeans.
> También hay otros, como JDeveloper (de Oracle, gratuito, creo) e
> IntelliJ (de pago), pero son más bien nichos de mercado. JBuilder está
> muerto en cuanto a desarrollo, por lo que sé, y Sun está convirtiendo
> NetBeans en el IDE de referencia; hasta en los tutoriales genéricos de
> Java lo usan para explicar muchas cosas.

De los que he visto, el que mas me ha gustado ha sido NetBeans. Tenia
mis dudas, porque cuando estas comenzando dependes por completo de la
ayuda sensible al contexto, pero ya ese punto esta resuelto.

Me acabo de instalar el plugin de UML.

Y desde que pregunte ayer hasta ahora, he encontrado una cantidad de
soluciones que me hacen estar mucho mas satisfecho con el.

Creo que no voy a buscar mas, al menos hasta que no tenga un buen
motivo. Lo importante ahora es parender el lenguaje, y eso es lo unico
que deberia preocuparme.

¿Como agrego un archivo fuente preexistente a un proyecto en NetBeans?

> ¿Es realmente indispensable? En modo alguno. ¿Hay dificultades no
> evidentes? Si vienes del mundo MS, puedes encontrar algunas. En Java
> no existen los controles gráficos "data aware". Es decir, pones un
> ComboBox en un formulario y, a diferencia de lo que tenía VB la última
> vez que lo miré, no tienes un par de propiedades con las que decirle
> que recoja su contenido de una consulta SQL o tabla de una base de datos.

Nunca use controles enlazados a datos en VB (es la clase de cosas que
contribuyeron a la justificada mala fama del lenguaje: al final,
resultaba mucho mas complicado controlar en detalle la conducta de los
controles enlazados que aprender a manejar las teconologias de acceso
a datos de manera directa).

> Aparentemente, no hay discusión posible: si no usas un ORM, estás
> muerto. En cambio, yo de momento no quiero usarlo. :-) ¿Por qué?
> Porque, a mi juicio, el ORM oculta tanto de JDBC que siento que pierdo
> el control de si los objetos con los que trato en el programa afectan
> a los datos en la base de datos o no. Introduce, además, un montón de
> conceptos nuevos, y como soy un poco novato, ya me sobran conceptos
> que asimilar.

Al final, en el modelo de objetos, tiende a haber una relacion 1-1
entre cada tabla de la BD con una clase del modelo.

Hay clases que incluyen agregados (por ejemplo, un documento con
detalles). Pero en estos casos, cada tipo de detalle es una clase en
si. Es simple manejar la agregacion mediante una funcion que te
devuelva una coleccion, lista o como se llame en Java con los
detalles.
Aunque entiendo su sentido, no me parece que la utilidad del ORM sea
tanta como se le atribuye.

> Así que yo, particularmente, de momento no quiero usar un ORM. Si te
> haces muy deprisa a Java, y dado que tienes mucha más experiencia de
> trabajo con OOP, quizá te lo debas plantear.

No, no creo.

Me preocupaba que la complejidad de usar directamente JDBC desde las
aplicaciones fuera demasiada, pero al final es mas o menos la misma
que la de ADO en el mundo de MS.

> Depende de si cada ventana tiene procesos interactivos que requieren
> cierto tiempo. Por ejemplo, si en cada ventana se cargan
> constantemente imágenes actualizadas desde una web que se bajan
> comprimidas y hay que descomprimirlas con su coste de CPU antes de
> poder mostrarlas, probablemente quieras varios threads, porque si no,
> lo más fácil es que una de ellas funcione constantmente mientras la
> otra se queda bloqueada. Pero, seguramente, esos threads no se usarán
> realmente para pintar las ventanas y responder a pulsaciones en los
> botones que contengan, sino para recuperar los datos de Internet,
> descomprimirlos y asignarlos a los controles gráficos de las ventanas.

Imagino que mi solucion sera abrir cada frame "superior" de la
aplicacion en su propio thread (no tengo dependencias entre frames:
esa fue otra de las cosas que contribuyeron a desprestigiar a VB), y
permitir que cualquiera de ellos se bloquee mientras dura alguno de
los procesos largos que deberan ejecutar (es lo que debe pasar). Esos
debera permitir que el resto de los frames sigan respondiendo a
eventos correctamente.

Bueno, ahora a seguir experimentando.

Muchas gracias, y nos seguiremos viendo.


Salud!

leonardoazpurua@cantv.net escribió:
> On 8 abr, 12:55, Ricardo Palomares Martinez <rpm.PU...@iespana.es>
> wrote:
> 
> ¿Como agrego un archivo fuente preexistente a un proyecto en NetBeans?


Pues, si te digo la verdad, nunca he intentado editar un archivo
suelto desde NetBeans. NetBeans trabaja con proyectos completos; si
quieres añadir un conjunto de archivos que forman un proyecto (aunque
ese conjunto tenga un único archivo), tienes que crear un proyecto
nuevo: File -> New Project -> General -> Java Project with Existing
Sources o ... -> Java Project With Existing Ant Script.


>> Aparentemente, no hay discusión posible: si no usas un ORM, estás
>> muerto. En cambio, yo de momento no quiero usarlo. :-) ¿Por qué?
>> Porque, a mi juicio, el ORM oculta tanto de JDBC que siento que pierdo
>> el control de si los objetos con los que trato en el programa afectan
>> a los datos en la base de datos o no. Introduce, además, un montón de
>> conceptos nuevos, y como soy un poco novato, ya me sobran conceptos
>> que asimilar.
> 
> Al final, en el modelo de objetos, tiende a haber una relacion 1-1
> entre cada tabla de la BD con una clase del modelo.


Ojo, que yo me refiero a las instancias de las clases, no a las clases
en sí. Eso es lo que me asusta, no que una clase "Producto" tenga
correspondencia con una tabla DB "PRODUCTO", sino que tenga que llevar
cuidado en el código fuente para no recuperar un objeto "miProducto"
de la BD, cambiar algo en él y que ese cambio no se propague a la BD
sin que yo me dé cuenta. Con un objeto suelto es fácil controlarlo,
pero con muchos objetos de los cuales algunos los quiero propagar a la
BD y otros no me preocupa que ese control no sea sencillo.


> 
> Me preocupaba que la complejidad de usar directamente JDBC desde las
> aplicaciones fuera demasiada, pero al final es mas o menos la misma
> que la de ADO en el mundo de MS.


El mayor problema, aparentemente, viene de las divergencias entre los
distintos dialectos SQL de los fabricantes, y entiendo que eso también
pasará con ODBC, ADO y demás. Los ORM lo solucionan creando un
lenguaje de consultas "agnóstico" y lidiando ellos por debajo con cada
fabricante, pero para según qué cosas eso también lo hacen bibliotecas
más sencillas (p.e.: DdlUtils de Apache sirve para suministrarle un
XML con el esquema de una base de datos y que el propio programa cree
o ajuste la base de datos con la que realmente trabaja; para programas
pequeños que se van a pasar a muchos usuarios usando Java DB,
HSQLDB... todos ellos motores SQL pequeñitos basados en Java como si
fueran el motor de MS Access, usuarios a los que no quieres estar
dándole scripts SQL para que los ejecuten a mano, DDlUtils viene muy
bien).

De toda formas, a medio plazo los ORM pasarán a ser parte integrante
del lenguaje. De hecho, Java ya tenía algo para la versión empresarial
(Java EE) en forma de EJBs (Enterprise JavaBeans), y ahora lo ha
sustituido por JPA (Java Persistence Architecture), que se convierte
en la referencia para implementar frameworks ORM tanto en soluciones
SE (Standard Edition) como EE. Hibernate ya tiene, o está a punto de
tener, una versión que se ajusta a JPA.

Saludos.

-- 
If it's true that we are here to help others,
then what exactly are the OTHERS here for?

leonardoazpurua at cantv.net escribió:

Se me ha vuelto a olvidar una cosa en la respuesta anterior... :-)


> Imagino que mi solucion sera abrir cada frame "superior" de la
> aplicacion en su propio thread (no tengo dependencias entre frames:
> esa fue otra de las cosas que contribuyeron a desprestigiar a VB), y
> permitir que cualquiera de ellos se bloquee mientras dura alguno de
> los procesos largos que deberan ejecutar (es lo que debe pasar). Esos
> debera permitir que el resto de los frames sigan respondiendo a
> eventos correctamente.


Supongo que sí, aunque confieso que todavía estoy un poco verde en
este asunto. Además, uno de los cambios con Java 6 es que han variado
la manera de gestionar todo esto: lo antiguo sigue funcionando, pero
proporcionan clases que lo hacen más sencillo y permiten tener código
más limpio.

Lo que se me olvidaba en el mensaje anterior es esto: ¿has leído algo
sobre el tutorial de Java de Sun? Es realmente bueno (EMHO) y explica
bastantes conceptos de manera más o menos clara. Lo tienes aquí:

http://java.sun.com/docs/books/tutorial/index.html

Y lo puedes descargar al disco duro si lo necesitas. Tiene un extenso
tutorial de Swing y cubre el asunto de los Threads para el entorno
gráfico. Te puede ser útil.

Saludos.

-- 
If it's true that we are here to help others,
then what exactly are the OTHERS here for?

On 9 abr, 05:34, Ricardo Palomares Martinez <rpm.PU...@iespana.es>
wrote:
> Lo que se me olvidaba en el mensaje anterior es esto: ¿has leído algo
> sobre el tutorial de Java de Sun? Es realmente bueno (EMHO) y explica
> bastantes conceptos de manera más o menos clara. Lo tienes aquí:

Hola,

Si. El Tutorial es justamente lo que estoy usando para aprender (y me
parece el mejor recurso disponible para aprender Java).

Tengo algunos problemas "mapeando" los conceptos del tutorial a los
requerimientos de NetBeans, pero ahi vamos.

Gracias.