Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Ver: Modo: Orden:
Java decae en picado | 13 comentarios (13 temáticos, editoriales, 0 ocultos)
¿Se puede? (4.50 / 2) (#8)
por jorginius ("jorginius" en Google Mail) a las Sat Apr 26th, 2003 at 02:43:45 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

¿O es una pelea privada :-)?

... (como la tontería de poder elegir el tema Solaris corriendo en Windows).


Si dices que es un tontería, creo que deberías decir también por qué te lo parece; si dices que no te gusta, no tienes que justificarlo ya que "sobre gustos no hay nada escrito".

Tanto como una tontería, a lo mejor no... Pero le veo al menos un inconveniente:

Ahora que WinXP soporta temas por si mismo, puede que los temas de Java (o Swing) no sean consistentes con los suyos. Aunque seleccionemos en el código el tema de Windows "estándar" en Java, el usuario puede tener seleccionado otro tema distinto y la aplicación se verá de forma no consistente. Lo mismo se puede decir de las X y Gtk (por mucho que usemos esto): las aplicaciones en Java y Swing "no se acoplan" con el resto del escritorio.

Y si seguimos tirando del hilo... Swing soporta temas porque el mismo se ocupa el dibujado de casi todos los widgets (Salvo el pequeño conjunto que aporta AWT) y, claro está, puede dibujarlos como quiera. El enfoque es elegante e independiente de la plataforma, pero asesina el rendimiento... Y si a esto le sumamos que se usa doble buffer por sistema, sin control sobre esto por parte del programador, nos encontramos con que casi cualquier aplicación Java que use Swing es directamente inusable en una máquina de 32 MB de RAM o menos.

Swing tiene un comportamiento independiente de la plataforma y es el toolkit estándar dentro de Java. El problema que tiene, rendimiento a parte, es que ese comportamiento independiente de la plataforma no llega a encajar con ninguna plataforma en particular. Es decir, sí: en todas las plataformas se ven las aplicaciones igual, pero en ningua de ellas las aplicaciones Java se ven exactamente como las nativas.

Si no tienes otra cosa que Java (como puede ser el caso de un dispositivo empotrado) pues esto no te supone un problema, pero sí lo supondrá si ya tienes un escritorio con tus aplicaciones nativas.

Microsoft y sus WFC resolvían el problema ofreciendo un toolkit ya no multiplataforma pero que permitía los widgets nativos de Windows desde Java. La misma aproximación que siguen los bindings de GNOME para Java.

Uno puede ir incluso un poco más lejos: ya que el toolkit te ata a una plataforma, no tiene sentido renunciar a la compilación a código nativo. De nuevo, Microsoft ofrecía en su Visual J++ un compilador a nativo (y otros muchos cachivaches curiosos, como el generador de wrappers automático de Beans a ActiveX y de ActiveX a Beans y otras cosillas de J/Direct, pero esa es otra historia). En Linux podemos echar mano del GCJ y de los bindings CNI de GNOME (CNI y no JNI :-)).

Pero claro, con eso perdemos la independencia de la plataforma... La otra solución que tenemos es usar un mismo API, pero que por debajo use los widgets nativos de la plataforma sobre la que corra (lo que hace wxWindows en C++, vamos). Es decir, si alguna plataforma no soporta tal o cual widget lo emulamos, en caso contrario usamos el nativo. Perdemos la homogeniedad entre plataformas (la aplicación se comportará de una forma diferente según donde se ejecute) y a cambio obtenemos mejor rendimiento.

El toolkit para Java más popular que sigue este enfoque es SWT (el toolkit del proyecto eclipse) y, por poner otro ejemplo, citaré el que se usaba (¿se usa aún?) dentro del Netscape: el IFC (orientado a los applets, claro).

El problema que tiene SWT es que obliga al programador de Java a cambiar de chip. No sólo tiene que aprender otro toolkit sino que además tiene que liberar los recursos por si mismo (¡horror! :-)).

Quizás si no quieres renunciar a programar en Java pero sí a la portabilidad, una combinación buena para escribir aplicaciones de escritorio sea GCJ + SWT... Y además llegado el momento puedes recompilar tu aplicación y hacerla funcionar en las plataformas que soporte GCJ o hacer una versión compilada a código intermedio.

Sobre lo de los móviles y la licencia podría también comentar algo, pero entonces no acabaría jamás :-).

[ Padre ]


Others have rated this comment as follows:
bgood 5
fizban 4

Java decae en picado | 13 comentarios (13 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda