No habrá Java en Windows 8 corriendo sobre ARM
Abraham
Este año estrenaremos una versión mayor de Windows, Windows 8. Y por primera vez habrá una versión de este sistema operativo que correrá sobre procesadores ARM, además de la versión que correrá sobre x86/x64. El propósito de Windows 8 sobre ARM es crear un rival para el iPad, tomando ventaja de la mayor duración de la batería que tendrán los equipos gracias a este procesador, y así como de la posibilidad de "empezar desde cero", ya que no habrá en absoluto compatibilidad con versiones anteriores de Windows en la versión de Windows 8 que corre sobre ARM; en la que corre sobre la plataforma x86/x64 Microsoft si mantendrá compatibilidad hacia atrás.
Windows 8 sobre ARM funcionará básicamente como un iPad, inclusive que tendrá una Store y todas las aplicaciones tendrán que instalarse desde ésta. Y lo que estas aplicaciones pueden hacer va a estar limitado; y una de las consecuencias de estas limitaciones es la imposibilidad de construir un compilador JIT (Just in Time), lo cual quiere decir que en la práctica no habrá Java, PyPy, el motor de JavaScrip V8... o cualquier otra máquina virtual que emplee tecnología JIT no podrá portarse a Windows 8 sobre ARM.
Teóricamente, Oracle podría construir una máquina virtual Java solo para esta plataforma que no tenga un JIT. Pero el rendimiento de dicha máquina virtual sería penoso y probablemente no tenga ni sentido realizar este esfuerzo.
Las máquinas virtuales no van a ser las únicas víctimas de Windows 8 sobre ARM; lo mismo va a pasar con los navegadores web alternativos a Internet Explorer, cosa que ya ha provocado quejas por parte de Firefox y Chrome.
Si esta plataforma realmente tiene éxito, significará que crecerá el número de dispositivos en los cuales Java en el escritorio no es una opción, no por las limitaciones de potencia o de tamaño del dispositivo, sino por que por intereses del fabricante no se permite incluir Java en ese dispositivo (lo que está sucediendo ahora mismo con el iPad). Sobra decir que esto no va a ser positivo para el futuro de Java FX.
¿Consideras que es un problema para el futuro de Java en el escritorio el hecho de que, con toda probabilidad, no habrá una máquina virtual para Windows 8 sobre ARM o cres que no es importante?
Pantalla de inicio de Windows 8
Reader Comments (31)
Si Microsoft se empeña en seguir los pasos de Apple, cerrando sus sistemas con siete llaves, con la confianza de que hará un negocio similar, tal vez se tropiece con su propio pie, y vuelva a obtener otro de sus "gloriosos" fracasos.
Microsoft carece de la imagen de Apple, para que una estrategia así le proporcione dinero.
Por no reeditar el mensaje anterior...
¿En esta "leonera" quiere meterse Microsoft con un sistema cerrado a cal y canto? :D
http://www.theverge.com/2012/3/14/2869858/apple-54-7-percent-tablet-market-q4-11-kindle-fire-idc
Con la progresión a la expectativa de Android, no creo que Java, ni JavaFX, estén para echarse a temblar; más bien todo lo contrario.
Lo interesante de Microsoft es que es el unico que tiene todo que perder, tal vez pueda ganar mucho, pero si de esta no salen vivos, windows podria dejar de ser un estandar de facto.
Esto estaba dentro de lo posible, y habíamos unos cuantos que ya lo estábamos advirtiendo.
Pero para el análisis, separemos un poco las cosas.
JVM sin JIT.
De una serie de pruebas realizadas por Maemo, Canonical y Openmoko empleando Jalimo (el cuan no posee JIT) con las librerías del OpenJDK, se da a entender de que esta aproximación dicta mucho de ser viable.
Por lo que, y coincido con Abraham, no es una buena idea.
ARM,
Hace un tiempo cuando lo de "Vías de acceso a la movilidad", ARM era la única opción posible para pensar en el poder del escritorio en la palma de la mano.
Pero en todo este tiempo, estos procesadores, se han hecho más potentes, más complejos, más costosos, y su chipset es un desquicio.
Mientras tanto el x86 redujo su huella de calor, su consumo de energía, integro la GPU y la CPU en el mismo integrado, y se volvió competitivo en costo y prestación con el ARM.
Esto es así a punto tal que ya existen teléfonos (Intel Atom) y tablet (Intel y AMD APU A2) con arquitectura x86, compitiendo contra ARM en igualdad de condiciones.
Por lo que cuidado, no todo lo que brilla es oro.
En cuanto a la decisión de Microsoft,
Por diferentes notas y comentarios, me da la impresión de que el tema pasa por forzar la adopción de su propio motor de ecmascript y de renderizado de HTML como lo han hecho Google y Apple en sus respectivas plataformas.
Solo me queda una pregunta,
¿Dónde estaba Oracle que no vio semejante elefante rosa parado en el medio de la calle principal?.
¡AAAAA si, ya me acuerdo, se estaba peleando con Google.!
:(
Un saludo,
Respecto a Android, creo que es un poco un tema "delicado". Es decir, ¿Android soporta Java?
Es decir, un programa Android se puede hacer en lenguaje Java, pero también en C o incluso en C#, pero un programa compilado a bytecode java, o uno JME no corre en Android, es más, ¿JavaFX funciona en Android? Porque vi el video que se puso sobre el supuesto JavaFX en IOS y Android pero, hoy día, no veo en ningún sitio cómo hacerlo.
Lo he visto en windows y anunciado en Mac y Linux..., pero, ¿en dispositivos móviles?
Quizás lo veamos funcionar en otros no "esperados", como Bada, donde ahora mismo funciona JME, pero ni lo tengo claro ahí...
Me parece que lo único que podemos esperar es que pronto haya una distribución linux que vaya bien en los móviles y que de verdad nos deje ejecutar aquello que deseemos.., por soñar...
Saludos
Sobre JavaFX embebido:
"As announced at JavaOne 2011, the new embedded platforms coming from Oracle (CDC) will be using JavaFX as the UI technology. That is slated for final release in 2013 along with Java 8 and JavaFX 3. However, there is a lot of work that has to be done this year to make this a reality, including adding touch event support to the platform. Having working embedded prototypes for this year is high on the list of goals for JavaFX!"
http://fxexperience.com/2012/01/2012-javafx-resolutions/
"In order to run JavaFX 2.0 on iPad, the JavaFX team, used a special Java ME virtual machine CDC (Connected Device Configuration) internally."
http://java.dzone.com/articles/javaone-2011-javafx-20
Eduardo, las tabletas están lejos de ser un área donde yo tenga mucha experiencia. Pero he escuchado revisiones de tabletas basadas en Windows 8 y actualmente las basadas en ARM tienen una vida más larga para la batería y se calientan menos. Y ARM sigue siendo líder indiscutible en movilidad. Intel mismo está tratando de crear nuevos diseños de chips para meterse en ese mercado, pero hasta donde yo sé ARM sigue siendo el líder.
Es decir, JavaFX llegará a los dispositivos móviles.., si llega, cuando pueda ser totalmente ignorado por todos, que estaremos picando HTML5 o quizás, hasta 6...
Abraham,
ARM es y seguirá siendo el procesador predominante en plataformas móviles, por lo menos durante los próximos 2 o 3 años. Y Android su OS estrella.
Esto es en cuanto a cantidad de dispositivos y en ambos casos los teléfonos tienen mucho que ver.
Pero atentos con esto.
Este es el smartphone de Intel
Intel Atom Z2460
El equipo que quiero evaluar (y al que todavía no le he echado mano) es este.
En Argentina, su costo es +o- el mismo que el de una Galaxy de las mismas características (tamaño de pantalla y memoria).
Aunque lo primero que le haría es sacarle el Windows7 e instalar Unity
Como escribí antes.
Cuidado, no todo lo que brilla es oro.
O dicho de otra forma, hay que estar atento a las alternativas.
Según fuentes anónimas consultadas por Cnet, las primeras tabletas operadas con Windows 8 serán lanzadas en noviembre y tendrán hardware de Intel. La publicación indica que también habrá versiones de Windows 8 para ARM, y aparatos de AMD.
Recién acabo de ver.
:o)
Definitivamente si afectara a Java. De hecho el único S.O. movil donde Java aun puede correr es Android y justo hace nada se ha presentado una máquina virtual .NET para Android que corre más rápida que la de Java para este S.O.
http://www.zdnet.co.uk/blogs/communication-breakdown-10000030/mono-team-ports-android-to-c-10026061/
Si a esto unimos que hoy dia:
+ Es posible programar con .Net para IPhone/IPad, Android, WP7 y Windows8
+ Que .Net hoy dia es un lenguaje mas avanzado y potente que Java,
+ Que Microsoft ofrece versiones de Visual Studio gratuitas que hasta incluyen control de versiones (han entendido que su negocio es la nube no sólo los entornos de desarrollo).
Pensar en Java hoy dia es como pensar en la banca española ¿que hago sigo invirtiendo en el mis recursos porque ya los tengo ahí o mejor cambio de sitio mis inversiones antes de que sea demasiado tarde?
Quizas el error original fue que Oracle comprara Sun ...
"Quizas el error original fue que Oracle comprara Sun ..."
Fue SUN quién "mató" a JavaME, y quien "inventó" el engendro infumable de JavaFX 1.x
Si queda alguna posibilidad de que Java en móviles sea una realidad, se deberá a los esfuerzos recientes, y crecientes, alrededor de JavaFX 2.x
Que .NET es mejor que Java es solo una opinión, sobre la que se podría discutir hasta que a los móviles les salga pelo en las orejas :D
Ok, Sun no acertó con JavaFx1.0 pero Oracle ¿no esta teniedno una capacidad de reacción bastante lenta?
Que .NET es mejor que Java si que es una opinión si, pero basada en datos:
+ Actualmente salvo por los enums, Java es un subconjunto de .NET
+ Sólo por la ausencia de expresiones lambda en Java la diferencia d productividad respecto a .Net es abismal.
+ Java hasta donde se no soporta LINQ y menos LINQ dinámico, lo cuál pone a .NET a años luz de Java
+ Además de que Android adolece de problemas en la experiencia de usuario x estar basado n linux q sólo son solucionables con más hardware. Encima Java no provee de helpers en el lenguaje como Async de .NET que hace de la programación de interfaces asíncronos un placer.
+ Java al contrario que .NET no ha evolucionado y ha tomado características de lenguajes dinámicos sin por ello afectar al rendimiento de las apps (como si ocurre con lenguajes dinámicos). Java por el contrario hasta donde se sigue siendo un lenguaje ceremonioso con poca evolución.
Si me equivoco en algo por favor corregidme, ... yo antes era un tipo normal pero no se que ha pasado que me me he vuelto fan de .Net :D
Sobre la "lentitud" de Oracle solo diré que el roadmap de JavaFX lleva varios meses de adelanto. El desarrollo de JavaFX es muy complejo, como sabe cualquiera que lo siga de cerca.
* Java es anterior a .NET y no es un subconjunto de nada, a menos que se considere cualquier "novedad" como una "necesidad imperativa" que define la "modernidad". Hay algo de esnobismo en esa manera de pensar.
* El que haya o no lambdas no tiene nada que ver con la productividad. La productividad es una función directa del conocimiento íntimo del lenguaje, más el uso de herramientas adecuadas. No estoy de acuerdo con esa idea extraña de la productividad, que la reduce "al número de líneas necesarias".
Si yo escribo esto en el IDE:
action= new ActionListener();
con dos clicks de ratón, sobre esa misma línea, obtengo automáticamente esto:
ActionListener action = new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
throw new UnsupportedOperationException("Not supported yet.");
}
};
Lo mismo se podrá hacer con los lambdas, en cuanto estén disponibles en la próxima versión 1.8
Aparte de que la productividad debe tener en cuenta "detalles" como la mantenibilidad, escalabilidad, y la fácil comprensión del código. Lo que suelen ignorar sistemáticamente los obsesionados con "las líneas escritas".
* La evolución de un lenguaje debe hacerse en función de las necesidades que se detectan como prioritarias, y no en modas.
* Estoy trabajando en estos momentos en el empaquetado de celdas de una JTable, de tal manera que las dimensiones de cada columna se adapten a las de la celda de mayor anchura.
Cada columna se procesa en una CPU diferente, y dentro de cada columna, las filas se dividen en bloques, en función de las CPU detectadas, y se procesan igualmente en CPUs diferentes.
Todo ello se calcula de manera paralela y asíncrona, con respecto a la JTable, y fuera del EDT. Una vez que las dimensiones de cada columna se conocen, se actualiza la JTable dentro del EDT.
En total, todo ese procesamiento paralelo se realiza con unas 120 líneas, incluidas líneas en blanco. Un 30% del total del código se escribe automáticamente, mediante funciones de autocompletar del IDE.
¿Te parece un buen ejercicio de asincronismo en un interface gráfico como Swing?
Sobre JavaFX.
En varias ocasiones y por diferentes medios algunos de nosotros hemos tratado de generar un debate en el que se pueda analizar pieza por pieza la viabilidad y conveniencia de lo que se está haciendo con JavaFX.
Y también si es necesario y porqué romper con Swing / Awt.
De todo ese esfuerzo, en lo personal extraigo dos conclusiones.
1. Que a la hora de plantear un debate echo a conciencia, con profundidad y de manera analítica. A JavaFX, le sobran fiscales, pero le faltan abogados defensores.
2. Que aun cuando su resultado final sea un producto aceptable, ya fracasó, por quiebre de expectativas.
Como dije, estas son conclusiones personales, y de verdad me gustaría que alguien demuestre lo contrario.
Totalmente de acuerdo en que ya es necesario un debate en profundidad sobre JavaFX 2.x, sin emociones, y con la máxima racionalidad.
Por muy novato que sea, JavaFX 2.x es una realidad, con lo que tendremos dos UI en Java, ambos integrados en el JDK, a partir del año que viene.
No sé dónde ni cómo se podría organizar semejante debate (no en este hilo de noticia).
Las expectativas no están en quiebra, ni mucho menos. Puede llegar tarde, o no. En todo caso, su éxito dependerá de su calidad, y del apoyo que tenga, porque resuelva problemas de una manera eficaz, y eficiente.
El lenguaje Java es un éxito indudable, y llegó bastante más tarde que otros.
@choces
¿Recuerdas al Iomega Zip?
Para la época, se trataba de un producto muy bueno, tanto, que la "expectativa generada" estaba en que reemplazaría al disquete en poco tiempo.
Esta expectativa nunca llego a cumplirse, por lo que desde el punto de vista del marketing comercial el producto puede considerarse un fracaso por "quiebre de expectativas"
Es a esto, y no a las encuestas, o que seamos siempre las mismas cuatro personas, a lo que me refería.
En cuanto al debate,
¿Te apuntas en la defensa?
Porque como dije fiscales, habemos unos cuantos.
Microsoft son unos hps, esta gente es la que tiene tan atrasada la informatica en tantos paises, que veremos en un futuro por observar la ventana del innombrable tendremos que pagar
Al diablo con todos estos hps de Microsoft
que viva el software libre
•La libertad de usar el programa, con cualquier propósito (libertad 0).
•La libertad de estudiar cómo funciona el programa, y adaptarlo a tus necesidades (libertad 1). El acceso al código fuente es una condición previa para esto.
•La libertad de distribuir copias, con lo que puedes ayudar a tu vecino (libertad 2)
•La libertad de mejorar el programa y hacer públicas las mejoras a los demás, de modo que toda la comunidad se beneficie. (libertad 3). El acceso al código fuente es un requisito previo para esto.
@efrigerio
Recuerdo perfectamente la Iomega Zip porque tuve una :D
Lamentablemente, quien reemplazó a la disquetera fue la unidad de CDROM. Digo lamentablemente, porque fue el CDROM quien de hecho acabó con Zip, quien a pesar de sus indudables ventajas respecto de la disquetera, fue incapaz de competir con los CD.
En ajedrez me defiendo tan bien como ataco, por lo que no me molestaría nada ser el defensor de oficio de JavaFX :D
Antes de nada, aclaro que no uso JavaFX en mis desarrollos, y no pienso usarlo en breve. Pero si por el bien del defendido debo incorporarlo ya a la infantería de mis almenas, tampoco hay problema ;)
@choces
Tiene derecho a un abogado, si no puede pagarlo la corte le asignara un ¿choces?
:D
Perdón, Perdón, Perdón, Perdón, Pero me lo has dejado servido en bandeja y no pude evitarlo.
:D
Hablando en serio,
Cuando lo del Podcast 128 "El futuro de las aplicaciones RIA" a raíz de lo de Flash para dispositivos móviles y lo de la donación de Flex. Se busco gente comprometida con estas tecnologías que pudiera ofrecer (y a falta de una mejor imagen) una "defensa digna" de las mismas.
Y creo que el resultado fue algo bastante bueno.
Me encantaría poder hacer algo en ese sentido pero clavando el cuchillo hasta el hueso (desde el análisis). Y ahí es donde algunos de nosotros no somos creíbles como abogados de parte.
:)
Sobre el zip.
Yo todavía lo conservo como pisapapeles (un IDE interno) :).
Si Iomega hubiese permitido que otras empresas además de la suya, fabricasen los driver's, en condiciones de licenciamiento similares a las disqueteras de 3,5 las unidades ópticas no hubiesen tenido sentido en la informática.
En lugar de eso genero una expectativa excesiva , una demanda insatisfecha, y como resultado, esa demanda la cubrieron primero los discos extraíbles y después los CD-ROM cuando se volvieron económicos.
Ese es el "quiebre de expectativas"
¡En el hueso de quién querrás tu clavar un cuchillo! :D
Te noto algo "exaltado". ¿No te apellidarás Bates (Norman) por casualidad?.
Hablando de servir en bandeja... ;P
Tampoco creo que la situación de Zip entonces tenga mucho que ver con lo que nos enfrentamos; pero no está mal recordar la historia, para no repetirla.
@choces En efecto no estoy al tanto de JavaFX. De hecho abandoné Java tras tirar a la basura un año de proyecto en una aplicación de negocio para JavaME que iba a funcionar sobre PDAs Linus. No pudimos con la poca cobertura de las máquinas virtuales de la API JavaME. Acabamos artos de excepciones Not Supported Exception. Lejos de salirnos gratis, nos salió muy caro.
En unos meses lo migramos todo a WindowsCE y te puedo asegurar que nos salió muchisimo más barato.
*Yo no he dicho q .NET sea anterior a Java ... esos galones son para Java. Pero a nivel práctico a dia de hoy no aportan nada. Tampoco es esnobismo, simplemente es que .NET ofrece lo mismo que Java y mucho más (enumeré las diferencias que a mi más me han marcado). Si son sólo snobismo enotnces pq Java POR FIN después de tanto tiempo a incluir expresiones lambda, ¿por marketing o algo así?.
*¿Has trabajado alguna vez con lambdas y LINQ? tal como hablas parece claro que no. No es cuestión de la cantidad de líneas que tengas que escribir, para eso ya existen como bien dices los snippets de código. Aunque los lambdas son más flexibles q unos simples snippets en realidad su ventaja está en de la claridad y la legilibilidad y esto tiene un efecto directo en la productividad y mantenibilidad que como tu bien dices son lo importante.
*La productividad y mantenibilidad no son una moda. Te aseguro que cuando domines los lambdas y LINQ ... (si tiene a bien Oracle algún dia añadir alguna tecnología similar a LINQ a Java) te daras cuenta como de equivocado estabas y que alto impacto pueden llegar en la arquitectura de tu app si los utilizas inteligentemente.
* El ejemplo que me cuentas de asincronismo tan sólo me dice que con Java se pueden hacer las mismas cosas que con .Net (faltaba que no fuera así) pero me gustaría poder dar un vistazo a ese código y mostrarte eso mismo en .Net con las extensiones del lenguaje añadidas para manejo de aprocesos asincronos.
Respecto a lo del código libre que dijo otro compañero estoy 100% de acuerdo. Sólo que Java como lenguaje es tan libre como lo pueda ser .Net, para muestra Mono que es una implementación de .Net de código libre que cada vez ocupa una posición más central en el mundo .Net y de hecho extiende su uso a plataformas no windows.
Un saludo!
Zip Iomega, genero expectativas más allá de sus posibilidades, por ende una demanda insatisfecha y la búsqueda de soluciones alternativas.
¿Vas a decirme que eso no te suena a JavaFX. ?
Por cierto, me cae mejor Bill Cutting (The Butcher).
: )
Muchas veces lo estuve dudando, pero creo que definitivamente yo defiendo a javafx, principalmente por que me parece que la evolución es necesaria y la plataforma java en lugar de debilitarse se pone cada vez mas emocionante, a diferencia de .net que solo tiene el monopolio de microsoft como animador, aunque me digan que el proyecto mono es genial, solo se limitan a copiar/implementar lo que microsoft compone.
En cambio como ejemplo en java solo tenemos que pensar en las comunidades de groovy, scala y clojure (incluiría a ceylon) con frameworks, portales, empresas, negocios, etc. etc. Ahora solo resta imaginar la de cosas interesantes que javafx como parte de este entorno puede y ofrecerá, pues es simplemente MUY interesante y muy polivalente.
Incluso quiero equivocarme en pensar en lo siguiente, me imagino que debido al web, tablets. celulares y al crecimiento de la plataforma MAC(ese objective-c esta imparable), javafx podría llegar a ser de las pocas tecnologías multiplataformas de escritorio que sigan vivas y en constante desarrollo, con todo respeto y vuelvo a decir, toco madera y me equivoque, pero como linuxero he apreciado una disminución en la actividad de gtk, wxwidgets y QT, si ya teníamos una frameworktitis web que se robaba a la gente, ahora con otras plataformas el escritorio como que se abandona.
Incluso como nota final del debilitamiento del desktop, creo recordar que mono no implemento WPF por que no hubo suficiente interes/gente/dinero, en cambio nosotros tenemos a Oracle interesado en realizar/apoyar algo del mismo tamaño. No digo que se requiera una gran empresa detrás de un proyecto así, pero vaya que ayuda y mucho.
@Sergio
Conozco los lambdas desde Lisp, SmallTalk y Object Pascal. Si creías que eran algo nuevo para mi, puedes cambiar de idea.
Las clases anónimas de Java son una forma de lambda, por si no te habías dado cuenta. Las diferencias con las de otros lenguajes son de sintaxis, no de concepto.
Y la razón por la que ahora se modifica la sintaxis en Java, tiene más que ver con avances en la descripción de tareas paralelas, que con cuestiones estéticas.
En tu primer mensaje asegurabas que Java carece de soporte para procesos asíncronos:
" Encima Java no provee de helpers en el lenguaje como Async de .NET que hace de la programación de interfaces asíncronos un placer."
¿Te has retractado ya? ;)
No tengo inconveniente en mostrarte el código en cuestión.
http://www.javaforge.com/scm/file/3171//JPTools/JPTools-Components/src/org/jptools/components/components/tables/JPTable.java/open&date=Wed+May+16+18%3A06%3A40+UTC+2012
Lo puedes consultar ahí mismo, a partir de la línea 511
Para que no haya dudas, todo se resuelve con el API del JDK, sin librerías externas.
@efrigerio
No creo que JavaFX esté generando expectativas "más allá de sus posibilidades". Más bien al contrario, hay un cierto escepticismo (lógico tras el fracaso de su versión 1.x), alimentado por la sensación de que "llega tarde".
Por otro lado, existe Swing, con una base instalada de código enorme, y mucho tiempo y esfuerzo dedicado a dominar "esa bestia salvaje" ;)
JavaFX no lo tiene nada fácil en cuanto a expectativas.
Sin embargo, sus posibilidades, al usar características del hardware inasequibles mediante código Java "estándar", son espectaculares. JavaFX ha roto la barrera tradicional en Java respecto a las innovaciones del hardware, sobre todo en los subsistemas gráficos. Glass y Prism son dos auténticas revelaciones.
Lo que le sucede es que el tiempo perdido con JavaFX 1.x le pasa factura. Y la percepción, creo que errónea, de que JavaFX está "pensado" exclusivamente para dispositivos móviles, alimenta eso que denominas "demanda insatisfecha".
Pero ya sabemos por dónde se mueve el negocio alrededor de los móviles, y no creo que JavaFX fuese a cambiar esa tendencia, aunque estuviese disponible ya mismo, con todo su potencial a toda vela.
Para un desarrollador empresarial o industrial, JavaFX es una alternativa a Swing o SWT. Es ahí por donde se mueven sus expectativas, sus demandas insatisfechas, o la búsqueda de alternativas.
Lo que creo es que, a menos que JavaFX se posicione de una manera clara, potente, y con gran calidad, como alternativa creíble y demostrable a Swing y SWT, no solo fracasará JavaFX, sino todo el desarrollo gráfico en Java.
Porque lo que hay no está a la altura de los tiempos, y no parece que haya manera de arreglarlo.
@ivmx
"pero como linuxero he apreciado una disminución en la actividad de gtk, wxwidgets y QT, si ya teníamos una frameworktitis web que se robaba a la gente, ahora con otras plataformas el escritorio como que se abandona."
@choces
"Lo que creo es que, a menos que JavaFX se posicione de una manera clara, potente, y con gran calidad, como alternativa creíble y demostrable a Swing y SWT, no solo fracasará JavaFX, sino todo el desarrollo gráfico en Java."
Bravo, los dos acaban de enterrar sus cuchillos en lugares correctos.
Les propongo lo siguiente,
Si se anotan, podemos reeditar el debate de hace un par de años con lo de "Oracle debe recuperar las piezas aprovechables del monstruo de JavaFX."
Y haber que sale de eso.
La idea sería poder evaluar la viabilidad y conveniencia de lo que se está haciendo con JavaFX y también si es necesario y porqué, romper con Swing / Awt.
Quién sabe, puede que hasta me convenzan de dejar a swing de lado y concentrarme en JavaFX
:)
Siempre que pueda disponer de un cuchillo largo y afilado... por mí, perfecto ;P
¿No irás a creer que los defensores no sabemos usar cuchillos? :D
Cuchillos? si con una hoja de papel basta para cortarse :S.
Yo me puse como defensor así que, sigo sosteniéndolo.
@choces
Me he equivocado pues, si que conoces los lambda pero no los valoras tanto como yo. Seguramente pq no has tenido oportunida de combinarlos con LINQ.
Si, las clases anónimas de Java se que son una forma de lambda, pero no aportan la agilidad que si dan los lambda de .NET EN COMBINACIÓN CON LINQ.
La combinación de lambdas con LINQ como dije anteriormente usados con inteligencia pueden llegar a a afectar a la ARQUITECTURA de tu aplicación simplifficandola enormemente,..... y hasta ahí puedo leer.
jajaja, no me he retractado, no
A ver que a las malas tanto Java como .Net ofrecen funcionalidad para gestión de hilos a "pelo".En mi primer mensaje decia que "Java no provee de helpers en el lenguaje como Async de .NET" y lo sostengo Java provee otros pero no uno que permitan la gestión de procesos asíncronos con la sencillez que permite Async de .NET,donde el compilador permite al desarrollador programar asincrono casi como si estuviera progrando métodos síncronos.
Y si me expliqué mal, por favor que no sea esa la discursión, eso para clase de lengua, mea culpa si no me exprese con claridad.
Visto tu código del thread en Java. A primera vista no he visto nada que se le parezca a la tenología a la que me refiero.
Voy muy pillado de tiempo pero en tener un momento pongo un ejemplo que muestre la potencia de .NET para hacer muy sencillo el manejo/sincronización entre procesos asíncronos.
Que conste que he tenido mi epoca Java y hace relativamente poco (2 años) programaba en C++ y me peleaba con scripts corriendo en Linux. Pero he tenido que ceder al peso de la realidad C# hoy (no ayer) esta por encima. De hecho respecto a Microsoft igual que mucha gente los he criticado en el pasado pero a dia de hoy segurament fruto de la sna compeencia he tenido que reconocer que han mejorado muchísimo y no me parece bien que s caiga en la critica basada en clichés del pasado más que en su realidad actual.
Un saludo
Ni SwingWorker ni ForkJoinTask son "gestión de hilos a pelo".
Lo que has visto en mi código es la aplicación del nuevo Fork/Join de JavaSE 1.7, que es una extensión de lo que ya conocíamos de concurrencia en Java.
No me quiero entretener más tiempo en debatir sobre .NET y Java. Si con .NET te va mejor, a ello.