🚀 go-pugleaf

Rafael Garcia Leiva wrote:
> 
> [Posted and mailed]
> 
> In article <36E65683.CF3A1435@tissat.es>,
>         Alvaro Fuentes <afuentes@tissat.es> writes:
> >
> > Los �nicos aspectos en el que el lenguaje Java sale
> > "perdiendo" es la ausencia de herencia m�ltiple y el
> >  rendimiento en la ejecuci�n
> >
> 
>     En cuanto al tema de la herencia multiple, nunca he tenido demasiado
> claro por que no esta incluida en Java. 
> En el libro "The Java programming
> languaje" de James Gosling, hace referencia a los problemas derivados
> de la herencia en forma de diamante, pero otros autores dicen que esto
> no es tan grave. 

Creo que puede ser grave si tienes un modelo de linking din�mico en que
una clase se carga de un servidor y se tiene que resolver sobre la
marcha. Es mucho m�s f�cil resolver una clase si s�lo hay herencia
sencilla. De no ser as�, puede tratarse de traversar todo un �rbol para
resolver las invocaciones de los m�todos. Y hay justamente el problema
de diamante etcetera.

> Tampoco se si los interfaces dan la misma funcionalidad
> que la herencia multiple, como proponen en la FAQ de Java.

Personalmente, me doy cuenta cada vez m�s que lo interesante en muchos
casos no es herencia de implementaci�n sino herencia de interfaz. Es m�s
bien la herencia de interfaz la clave para hacer dise�os robustos.
Herencia de implementaci�n, de hecho, se puede abusar, a veces es mejor
usar un esquema de delegaci�n/composici�n. Depende del caso, por
supuesto. Mi impresi�n es que con la introducci�n de las inner classes,
combinada con las interfaces, funcionalmente, Java ofrece lo que otros
sistemas ofrecen con herencia m�ltiple de todas formas. Bueno, se hace
de modo distinto, pero el efecto es lo mismo. Mira, por ejemplo, usos de
interfaces e inner classes en el c�digo de Swing.

>     Sobre el rendimiento de ejecucion ya se ha hablado mucho, pero me
> gustaria apuntar dos cosas:
> 
>     - La primera es que la gente tiende a confundir el lenguaje java con
> las maquinas virtuales, y claro, si tienen una maquina virtual lenta, dan
> por supuesto que java es lento. En concreto la maquina de BlackDown es una
> de las mas utilizadas, y desgraciadamente, tambien una de las mas lentas.
> Ver http://www.javaworld.com/javaworld/jw-03-1999/jw-03-volanomark.html

Lo he visto. Es IBM que tiene el Java m�s veloz ahora. Se puede bajar
una JVM de IBM para NT o Windows 95 en el alphaworks. Tiene su propio
compilador JIT que supera el de Symantec, me parece. He estado jugando
con eso. Lo �nico es que usa mucha memoria.

El verdadero problema ahora mismo con Java quiz� sea que es un nuevo
modelo de ejecuci�n, en cierto sentido, en comparaci�n con los
ejecutables est�ticos que se crean en C++. Las plataformas sobre las
cuales Java corre no fueron dise�adas con Java en mente. La JVM es algo
injertado encima de Windows. El S.O. no es en ning�n sentido
"java-aware". Un resultado de eso es que una librer�a de clases en Java
se tiene que volver a cargar desde cero cada vez que se utiliza en una
aplicaci�n nueva, a diferencia de un .DLL nativo. Entonces, una
aplicaci�n Java tiende a tardar much�simo m�s tiempo en inicializarse
que una aplicaci�n nativa. Entonces, s� que hay problemas en la
implementaci�n de Java sobre los S.O. actuales que tienden a hacer que,
en la pr�ctica, corre m�s lento. Pero tienes raz�n. No son problemas con
Java en s�. Es algo que se tiene que matizar much�simo.

Mira, si accedes a Internet a traves de una l�nea telef�nica
convencional, tu experiencia de Internet es que es lento. �Por qu�?
Porque est�s utilizando una red de comunicaciones que no fue dise�ada
con Internet en mente. Entonces, tu experiencia es extrema lentitud.
Pero decir que Internet *es* lento como alg�n hecho inmutable es muy
dif�cil de sostener. Consigues una conexi�n T1 y tu experiencia es
distinta. Internet no es intr�nsecamente lento.

El argumento general que Java debe ser m�s lento que C++ es muy dif�cil
de sostener. Decir que los primeros prototipos de una tecnolog�a son
lentos es muy diferente de decir que la tecnolog�a es lenta.
 
>     - La segunda es que la gente no utiliza java, aduciendo la lentitud,
> incluso aunque esten hablando de programas interactivos. Que mas da que
> un programa tarde 0.0001 segundos de mas si despues el usuario tarda varios
> segundos en leer y responder?

Correcto. La gran mayor�a de c�digo que escribimos d�a a d�a no tiene
porque ser muy optimizado. Todo ese discurso seg�n el cual la
preocupaci�n principal de un programador es maximizar la velocidad de
ejecuci�n me da una sensaci�n realmente inc�moda.

Jonathan Revusky
-- 
Java and Delphi Consulting
Make your .class files double-clickable
with SmartJ
http://www.bigfoot.com/~crystalline.solutions