🚀 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?