Barrapunto

Lo que cambia con este paso y otros anteriores es que Java deja de ser un lenguaje adecuado para hacer aplicaciones específicas para MacOSX. Poca gente usa por ejemplo en Linux o Solaris los bingings de GTK+ del proyecto Java-gnome. En el caso de Windows lo que ha hecho Sun es cuidar especialmente que las aplicaciones Swing den el cante lo menos posible en relación al aspecto de las nativas.

Se podrá seguir usando Java para hacer aplicaciones de escritorio multiplataforma que funcionen en MacOSX usando Swing o SWT, como en Windows, GNU/Linux o Solaris. Además seguramente siga soportándose JavaFX. Lo que posiblemente cambie es que Oracle no dedique demasiados recursos en que las aplicaciones de escritorio estén muy integradas con el resto de las de MacOSX, lo que es lógico.

Y seguirá siendo posible porque Oracle por una cuestión de imagen (mantener vivo el mensaje de que Java es multiplataforma) seguirá publicando versiones para MacOSX. Por más que para Java sea una plataforma poco relevante: como escritorio es muy minoritario, aún si tiene más usuarios que Linux, pero es que Linux es relevante como servidor y MacOSX no. Apple no tiene nada interesante en Java, a diferencia por ejemplo de Red Hat con JBoss e Hibernate. Y además mantener Linux para el escritorio no es una gran carga si ya se mantiene Solaris, mientras que MacOSX no sólo es distinto al resto de sistemas soportados sino el más "rarito".

Otra opción será escribir las aplicaciones siguiendo el modelo MVC y escribir la parte de la vista con código nativo para cada sistema operativo y el resto en Java.

Hombre, Oracle podrá portar Java a MacOSX como cualquier otro fabricante puede portar su software: de igual modo que hay Qt, wxwidgets tienen versión para MacOSX. Apple no ha dicho nada de prohibir usar los APIs de MacOSX a Oracle ni a nadie, que yo sepa.

Otra cosa es que cueste más o menos a Oracle portar Java (si no lo tienen ya: posiblemente la versión de Apple la hayan portado ellos y luego Apple la ha ido modificando para dar mejor integración). Pero no debería ser excesivo si no se preocupan del tema de la integración y que parezcan aplicaciones MacOSX. SWT ya existe para Java al margen de Apple, portar AWT si no lo tienen ya no les costará y Swing es código Java al 100%, no llamadas a código nativo. Podrán no tener eso sí el tema para que las aplicaciones Swing se parezcan a las de MacOSX.

El que dejen de mantener su máquina virtual no es un tema de que Apple se haya enemistado con Oracle, sino que habrán echado sus cuentas y visto que Java no les aporta mucho para promoverla como plataforma para sus aplicaciones y que ahorrar en costes y desarrolladores. Esto tampoco es nuevo porque ya hace años hicieron "deprecated" los bindings de Java para Cocoa.

Todo esto no tiene nada que ver con un cabreo entre Apple y Oracle. El caso es que entre Oracle y Apple no hay motivos para tener mucha rivalidad, pero tampoco para dedicar muchos esfuerzos a trabajar juntos con Java. Java se usa sobre todo para servidor y para aplicaciones de gestión internas de la empresa (precisamente los fortines de Oracle desde antes ya de comprar Sun) y en esos dos sectores MacOSX apenas se usa.

El caso es que ni Apple ni Oracle tienen motivos para considerar Java para MacOSX superestratégico, pero a ambos les viene bien que haya un Java que permita al menos ejecutar aplicaciones multiplataforma como en Linux y Windows (aunque no tengan la integración óptima), por lo que Oracle gastará dinero en tener un port y Apple le dará facilidades.