Libertonia || Comments || Java decae en picado


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

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 ]

Al final tanto... (none / 0) (#9)
por jorginius ("jorginius" en Google Mail) a las Sat Apr 26th, 2003 at 02:50:26 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Para decir tan poco :-).

Resumiendo: los guis de Java estándar tienen el problema de que no se ven igual que las aplicaciones nativas. Hay biblotecas no estándar que lo arreglan, pero si las usas, tu aplicación no se comportará igual en cada plataforma que la corras.

Además es doloroso tener que usar una biblioteca no estándar adicional cuando por debajo tienes un enorme framework instalado "por narices" que no vas a usar.

[ Padre ]

Oñio (none / 0) (#10)
por man ls a las Sat Apr 26th, 2003 at 12:14:45 PM CET
(Información Usuario)

Qué buena explicación, ni yo mismo la habría dicho mejor (es más, lo habría dicho mucho peor, porque la mitá de las cosas ni las sabía). Así da gusto, se nota que por aquí hay gente que controla.

No es una pelea privada, es más, ni siquiera es una pelea porque no sé quién es preage (aparte de que escribió un libro muy fuerste hace 50 años).

Por favor, si tienes un rato, extiéndete sobre la licencia. Voy a hacer una entrada en el diario sobre eso, para darte una excusa; o si no, haz una tú que lo verá más gente. Me parece un tema muy interesante (y además on-topic...)

[ Padre ]

Lo siento, pero soy un cobardica (none / 0) (#11)
por jorginius ("jorginius" en Google Mail) a las Sat Apr 26th, 2003 at 01:10:20 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

... Y por experiencia propia en otros lugares te digo que como escribas sobre eso en plan critico, la peña te van a pasar a cuchillo.

Como dijo un libertonio ilustre: este sitio es bastante "flame-proof", pero yo no tentaría la suerte :-). Para lo que quieras en plan técnico y que esté en mi mano, sí puedes contar conmigo (pero con calma , ¿eh?, que mi bandeja de pendientes es mostruosa. A ver si acabo con lo del microrobot :-)).

[ Padre ]

no lo veo así (none / 0) (#12)
por preage a las Sun Apr 27th, 2003 at 03:56:17 AM CET
(Información Usuario) http://geocities.com/dariapra

... como escribas sobre eso en plan critico, la peña te van a pasar a cuchillo.

Yo no lo veo así, aunque, claro está, sólo puedo hablar en mi nombre y no en el de toda la gente que se ha dado de alta en Libertonia.

En mi opinión, son cosas bien distintas que alguien saque, por ejemplo, a relucir los defectos de Java (por ejemplo, estoy bastante de acuerdo con las críticas hechas a Swing) de forma razonada y otra bien distinta es escribir cosas como "Java cae en picado" o hablar de licencias "casposas". Si se quiere, por ejemplo, criticar la licencia que Sun utiliza con Java, bienvenidas sean las críticas si vienen acompañadas de argumentos y no de lo que yo entiendo que ha sido un ataque.

Simplemente no espero de Libertonia cosas como "licencia casposa" y similares.

[ Padre ]

Java decae en picado | 13 comentarios (13 temáticos, editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

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