Conclusión: No pierdan el tiempo, ni dinero, ni esfuerzo desarrollando en Java. Ese lenguaje está maldito:
1. Los applets Java prometieron el oro... hoy están obsoletos y nadie los usa
2. Hizo de iOS un sistema operativo vulnerable
3. J2ME es historia
4. Los NC (Network Computer) con su base en Java fueron un absoluto fracaso
5. Los IDEs Java son lentos, hartos consumidores de memoria, eclipsan al PC
6. Trate de hacer una interfaz gráfica con AWT/Swing con sólo código y llore
7. Prometió seguridad y .... oh wait!
8. Y ahora esto... puaj!
#c-11" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2173574/order/11">#11 Delphi, C#, C++ de los que conozco, estoy estudiando JavaScript y le veo potencial
#13 En Delphi, las pantallas (ventanas junto con los otros controles) se guardan en un archivo aparte del código de la lógica del programa; el riesgo es muy bajo que desde la parte de la lógica afecte a la interfaz gráfica, salvo que borre directamente la única línea de código (encabezado de función) de algún control. En Java, era una mezcla absurda de código de interfaz gráfica con lógica de programa; y programar eventos en Java Swing/JFC es vomitivo.
#14 Eso de lo que hablas también se puede hacer en Java. No con Swing, pero es que Swing ya es algo "obsoleto" en el mundillo Java desde que hace algunos años apareció JavaFX. Con JavaFX se pueden diseñar las interfaces gráficas en un lenguaje llamado FXML, que no es más que un fichero XML en donde se describen los controles que quieres usar, mientras que todo el código va por otro lado.
#10 La verdad es que Java nunca fue muy usado para desarrollar aplicaciones de escritorio, como en todos los casos que comentas. Donde sí se usa bastante es en el lado del servidor, y ahí no se da ninguno de esos problemas, salvo lo de que los IDE son lentos, aunque es una opinión bastante discutible. Lo que sí no entiendo es eso de hacer interfaces gráficas "sólo con código". ¿Con qué más se hacen?
Y por eso, dependerá de si Google implementa la API del JRE o del OpenJDK ya que disponen de una licencia distinta. Existe la doble licencia y en este caso el doble licenciamiento viene por dos implementaciones y como aquí también cuenta el apartado legal dependerá de lo que Google declare implementar y del tipo de licencia que lleve la especificación de la API (que no implementación) que se distribuye con el OpenJDK.
Oracle tiene todo el derecho del mundo en reclamar copyright por la API de su versión privativa. Sin embargo OpenJDK es libre y por tanto dispone de una API e implementación distribuible libremente bajo licencia GPL.
Todo depende de lo que Google esté haciendo: implementar la API del Java de Oracle o la API del OpenJDK.
#19
Y como tal la API está sujeta a copyright. Sin embargo la API puede tener diferencias entre el OpenJDK y el JRE por lo que son dos obras distintas.
#20 La implementación de la API puede ser diferente, pero la especificación (y por lo tanto la funcionalidad) tiene que ser la misma. Si no, código java que funcionase en una podría no funcionar en la otra. Lo que dijiste de "implementar la API del Java de Oracle o la API del OpenJDK" no tiene ningú sentido, porque no se puede implementar algo que ya es en sí una implementación de una API. Lo que se implementa es la especificación.
#21
Efectivamente, código Java que funciona en una puede no funcionar en la otra, como código Java 7 no funciona con Java 6.
La especificación implementada depende de la implementación de la especificación y la especificación es variable según lo que se quiera implementar, por tanto puede haber dos especificaciones diferentes según sea OpenJDK o JRE.
#22 Las únicas diferencias entre OpenJDK y JRE desde hace bastante son simplemente algunos componentes gráficos (y sólo en apariecia, no en funcionalidad) que en la JRE no son libres (http://ubuntuforums.org/showthread.php?t=1145646). Y las diferencias que había antes eran bugs, porque teóricamente deberían haberse comportado igual, según la especificación. Teniendo en cuenta que Android usa sus propios componentes gráficos, no puede ser esa la parte que han copiado a la JDK (Bueno, y los plugins para navegadores, que Android tampoco utiliza).
Por cierto, OpenJDK es la implementación de referencia que la propia Oracle publica. Se supone que la JDK intenta ser lo más fiel posible a la OpenJDK. No se introducen diferencias a propósito (no tendría ningún sentido).
Comentarios
Gran victoria para Oracle en su batalla por cargarse Java.
¿Que hará Google si ve que Oracle le corta las alas con Java? Pues impulsar alternativas.
Ya se sabía que oracle+java=fin del lenguaje.
Siguiente paso: android sdk nativa en python, compilada para dalvik.
#1
Sería maravilloso
Ánimo Oracle, que tu puedes!
#1 Dalvik es el pasado, ART se está desarrollando para ser mucho más flexible y soportar más lenguajes que java.
#1
A ver si dejáis de decir memeces sin sentido.
Conclusión: No pierdan el tiempo, ni dinero, ni esfuerzo desarrollando en Java. Ese lenguaje está maldito:
1. Los applets Java prometieron el oro... hoy están obsoletos y nadie los usa
2. Hizo de iOS un sistema operativo vulnerable
3. J2ME es historia
4. Los NC (Network Computer) con su base en Java fueron un absoluto fracaso
5. Los IDEs Java son lentos, hartos consumidores de memoria, eclipsan al PC
6. Trate de hacer una interfaz gráfica con AWT/Swing con sólo código y llore
7. Prometió seguridad y .... oh wait!
8. Y ahora esto... puaj!
#10 no digo que te falte razón, pero según tu, cual es el lenguaje/entorno de programación ideal que pueda hacer lo mismo que permite hacer java?
#c-11" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2173574/order/11">#11 Delphi, C#, C++ de los que conozco, estoy estudiando JavaScript y le veo potencial
#13 En Delphi, las pantallas (ventanas junto con los otros controles) se guardan en un archivo aparte del código de la lógica del programa; el riesgo es muy bajo que desde la parte de la lógica afecte a la interfaz gráfica, salvo que borre directamente la única línea de código (encabezado de función) de algún control. En Java, era una mezcla absurda de código de interfaz gráfica con lógica de programa; y programar eventos en Java Swing/JFC es vomitivo.
#14 Eso de lo que hablas también se puede hacer en Java. No con Swing, pero es que Swing ya es algo "obsoleto" en el mundillo Java desde que hace algunos años apareció JavaFX. Con JavaFX se pueden diseñar las interfaces gráficas en un lenguaje llamado FXML, que no es más que un fichero XML en donde se describen los controles que quieres usar, mientras que todo el código va por otro lado.
#10 La verdad es que Java nunca fue muy usado para desarrollar aplicaciones de escritorio, como en todos los casos que comentas. Donde sí se usa bastante es en el lado del servidor, y ahí no se da ninguno de esos problemas, salvo lo de que los IDE son lentos, aunque es una opinión bastante discutible. Lo que sí no entiendo es eso de hacer interfaces gráficas "sólo con código". ¿Con qué más se hacen?
Oracle es imbécil, si algo estaba salvando el java delante de python era precisamente Android.
Los de Oracle viendo que no pudieron cargarse OpenOffice, ahora van a por Java
Tjo,tjo, OPENJDK.
Y por eso, dependerá de si Google implementa la API del JRE o del OpenJDK ya que disponen de una licencia distinta. Existe la doble licencia y en este caso el doble licenciamiento viene por dos implementaciones y como aquí también cuenta el apartado legal dependerá de lo que Google declare implementar y del tipo de licencia que lleve la especificación de la API (que no implementación) que se distribuye con el OpenJDK.
Oracle tiene todo el derecho del mundo en reclamar copyright por la API de su versión privativa. Sin embargo OpenJDK es libre y por tanto dispone de una API e implementación distribuible libremente bajo licencia GPL.
Todo depende de lo que Google esté haciendo: implementar la API del Java de Oracle o la API del OpenJDK.
#12 Creo que las APIs son todas las mismas. Vamos a aver, los programas con OpenJDK y Java JRE® funcionan de igual manera.
Y tanto como GCJ como OpenJDK usan igualmente la API para crear el JAR.
#12 ¿Sabes lo que es una API? Lo que dices no tiene sentido. Una API es una especificación, que puede implementarse de distintas maneras.
#19
Y como tal la API está sujeta a copyright. Sin embargo la API puede tener diferencias entre el OpenJDK y el JRE por lo que son dos obras distintas.
#20 La implementación de la API puede ser diferente, pero la especificación (y por lo tanto la funcionalidad) tiene que ser la misma. Si no, código java que funcionase en una podría no funcionar en la otra. Lo que dijiste de "implementar la API del Java de Oracle o la API del OpenJDK" no tiene ningú sentido, porque no se puede implementar algo que ya es en sí una implementación de una API. Lo que se implementa es la especificación.
#21
Efectivamente, código Java que funciona en una puede no funcionar en la otra, como código Java 7 no funciona con Java 6.
La especificación implementada depende de la implementación de la especificación y la especificación es variable según lo que se quiera implementar, por tanto puede haber dos especificaciones diferentes según sea OpenJDK o JRE.
#22 Las únicas diferencias entre OpenJDK y JRE desde hace bastante son simplemente algunos componentes gráficos (y sólo en apariecia, no en funcionalidad) que en la JRE no son libres (http://ubuntuforums.org/showthread.php?t=1145646). Y las diferencias que había antes eran bugs, porque teóricamente deberían haberse comportado igual, según la especificación. Teniendo en cuenta que Android usa sus propios componentes gráficos, no puede ser esa la parte que han copiado a la JDK (Bueno, y los plugins para navegadores, que Android tampoco utiliza).
Por cierto, OpenJDK es la implementación de referencia que la propia Oracle publica. Se supone que la JDK intenta ser lo más fiel posible a la OpenJDK. No se introducen diferencias a propósito (no tendría ningún sentido).
Si hubieran escogido la máquina virtual de Mono no les hubiera pasado esto y el Android iría mucho más rápido y libre.
#15 ¿Y por qué iría más rápido?
Esto se pone divertido