Barrapunto

Artículos como ése he visto docenas, sobre todo cuando estaba involucrado profesionalmente con el lenguaje de marras. En la práctica, todo se quedaba en teoría :-) La compilación en run-time era muy propensa a fallos y terminabas obligado a quitarla para que funcionasen los programas (receta común tanto para Apache como para JRun, el que se usaba con Windows).

Y me creo que hayan mejorado. Pero ¿y qué?. Para hacer aplicaciones de servidor de web no está mal. Pero con un poco de programación de sistema como apoyo se mete lo mismo con otros lenguajes más sencillos. Para GUI desde luego que hay cosas mucho mejores.

El lenguaje en sí tampoco me gusta. Pero ésa es otra historia.

La otra chamacanada es sostener que la optimizacion dinamica puede mejorar el rendimiento de los programas, algo totalmente falso y que ademas tampoco tiene ninguna base. La mera tarea de analizar los bytecodes ya supondria una ralentizacion enorme, jamas seria una mejora respecto de la compilacion estatica. De hecho el JIT de java hace lo contrario, recompila estaticamente para la arquitectura, esta afirmacion es algo erronea pero en esencia es eso.

Hay optimizaciones que no se pueden hacer estáticamente. Los métodos vituales de c++ no se pueden optimizar poniendo el código in-line de manera de ahorrarse el llamado a un método. Por otro lado el análisis de bytecodes sí ralentiza, pero en aplicaciones que ejecutan por más de un cierto tiempo, se supone que la ganancia supera el costo. Con respecto a los JIT, es muy fácil ver si un mismo programa corriendo con JIT es más lento que con HotSpot, mi experiencia es que HotSpot es más rápido, pero sospecho que es por las otras mejoras y no necesariamente por la compilación adaptativa. Recordar que hotspot con el parámetro --client no hace casi nada de optimización.

Espero que no tengas que ganarte el tuyo como adivino :-D

Los metodos virtuales solo son virtuales en el texto fuente amigo mio. Si no lo dejan de ser jamas los utilizaras en un programa, porque son eso, virtuales. Es decir, solo indican que pueden ser definidos en clases que hereden de la que posee dichos metodos. Es decir en el momento de la compilacion sea del tipo que sea esta, deben de ser no virtuales.

Los métodos virtuales tienen la característica de hacer imposible determinar en tiempo de compilación qué subclase concreta va a ser la que realmente ejecute el método. El sistema de tipos de C++ no puede determinar de qué clase concreta es el objeto de la variable sobre la cual se llama tal método virtual. En c++ sólo se puede poner en línea (es decir, reemplazar la llamada a un subprograma por el código de la misma) el código de los miembros que no son virtuales. Si no fuera así, los genios de C++ no tendrían una tabla en memoria en tiempo de ejecución para cada método virtual de manera de resolver al momento de la llamada, qué método invocar.

Si tu tienes un algoritmo que "adivina" que código debes invocar a partir de una llamada virtual, paténtalo, y serás millonario.

Respecto a la optimizacion dinamica uedes analizar los bytecodes para su ejecucion inmediata, pero no reutilizarlos en posteriores ejecuciones porque los datos que manejen pueden variar y eso exige de nuevo una comprobacion que anula todo posible beneficio.

Hay muchas cosas que hacen que un programa en java sea más lento a priori. Por ejemplo, de entrada, hay un más de un hilo corriendo (main, GC, etc), cosa que no es así en el programa de c++ típico. Gente que ha investigado el tema de las optimizaciones de código (sin ir más lejos los que hicieron la JVM HotSpot) dicen que analizar el código mientras se ejecuta lleva a realizar mejores optimizaciones que las que puede hacer un compilador típico. A mi me parece razonable perder velocidad al cargar el programa para tener mejor performance a la larga. Decir tan alegremente que "anula todo beneficio" es como mínimo poco sustentable. La experiencia concreta con hotspot respalda las suposiciones de esa gente.

Pos ala a pepito por der de izquierdas no le vamos a hacer ni puto caso cuando hable de economia. Que mas o menos es lo que has dicho. Porque claro no es objetivo, no le parece bueno el capitalismo

Anda ¿ estás haciendo un análisis sicológico del comportamiento habitual en BP ? es decir o conmigo o contra mi

El tratamiento de eventos está muy bien planteado, y tiene potencia suficiente como para encodar audio/video en tiempo real y cosas similares.

Quizás con otros lenguajes se alcance algo más de velocidad, pero estoy harto de oír a gente hablar como si Java corriera sólo un 10% de lo que corren otros lenguajes, o de oir a quienes dicen que es lento simplemente porque el navegador tiene que cargar la MV cuando se encuentra un applet. Pediría que sólo se opinara desde la experiencia, no desde la ignorancia!

Las que recuerdo de memoria. Después te doy más.

• http://www.jboss.org/
• http://www.netbeans.org/
• http://jakarta.apache.org/

Pues así, a bote pronto, me vienen a la cabeza el Limewire (cliente opennap), y el Jedit (editor de textos muy versátil y que no está nada mal). A parte de estos dos, no me acuerdo de ningún otro.

Programas a parte, yo soy de la opinión que Java no es un lenguaje pensado para esas cosas. Java es un lenguaje orientado a la web, y en ese ámbito no tiene rival, pero fuera de ahí su utilidad es escasa. El lenguaje en sí es bastante cómodo de usar (viene a ser lo mismo que el C++ pero quitándole todo lo que le sobra, como punteros, headers, etc...), pero yo me quedo con C/C++. De toda la vida. Hay quién dice que C++ es un monstruo inmanejable y difícil de tratar, o que C es arcaico y pasado de moda. Pues que piensen lo que quieran, pero creo que son dos lenguajes con muchísimo futuro. Y que no me vengan con que Java es más rápido, porque me entra el ataque de risa y no paro. ¿Cómo va a ser más rápido un programa que se ejecuta directamente sobre el hardware del ordenador que uno que necesita de otro programa auxiliar para ejecutarse? Amos hombre...

Te doy la razon en qe aplicaciones hechas en Java haylas, pero lo dificil es encontrarlas

Será dificil para tí.

Pos eso

He trabajado en temas de tratamiento de imagen, visión artifical, (con algoritmos computacionalmente complejos) simulaciones de MonteCarlo, encodado y renderización de audio, streaming, y muchas cosas con restricciones temporales muy exigentes. Actualmente trabajo en un proyecto de streaming de audio en formato ogg (audio de tipo mpeg4) en Java, y si uso ese lenguaje es porque estoy satisfecho de los resultados que obtengo. Java me ha dado muy buen resultado, y no sólo para realizar prototipos, sino también aplicaciones finales. No tengo experiencia en otro tipo de desarrollos como servlets o JSP (para esas cosas uso PHP).

No tergiverses mis palabras. Nunca he dicho que interpretar bytecodes sea más rápido que ejecutar código nativo, pero sí sostengo que si en Java no obtengo las prestaciones que necesito, tengo muy claro que pasando a C voy a conseguir a lo sumo mejorar un 10 o 20% la velocidad, nunca un 500% o 1000% como parecen insinuar algunos.

Y como decía antes: Hablo desde la experiencia. Ahora cuéntanos... ¿Cuál es tu experiencia? No seas egoista, comparte tus conocimientos con los demás!