Java pende de Android

Un tema recurrente en las entradas de blog es "Java is dead" o Java es el nuevo COBOL.  Aquí va mi opinión sobre el tema.

Primero no veo por donde podría morir pronto Java.  Son demasiadas las aplicaciones y las empresas que dependen de Java para que eso ocurra.  Quizás, en 10 años más se dejara de usar Java para desarrollar nuevas aplicaciones y, en 20, se dejara de mantener aplicaciones viejas.

"Java es el nuevo COBOL" tiene un poco más de peso.  La evolución del lenguaje se puso lentísima, hay un especie de statu-quo entre JEE y la suite Spring y no aparecen frameworks Java nuevos.  Si comparo con lo que pasa en la comunidad Scala, Java es  aburrido.  No obstante, el lenguaje se sigue usando para crear aplicaciones entretenidas y me refiero a su uso en el mundo móvil, el cual mantiene vivo el lenguaje.

Para argumentar voy a usar el indice TIOBE.  En este indice, las curvas de C# y Visual Basic, lenguajes competidores a Java en Windows, están francamente a la baja en los últimos años.  Al mismo tiempo, Objective-C, el viejo lenguaje que Apple refloto para iOS, iPhone e iPad, salio de la oscuridad y compite con los lenguajes más populares.  Esta claro que Java se sostiene gracias a Android, sino estaría dando la misma curva descendiente que C# y Visual Basic.

Y Oracle esta demandando a Google por el uso de Java en Android!  En este juicio, Oracle perdió la primera ronda pero va por la apelación.  Los argumentos que usan, como la legitimidad de usar Copyrights para las definiciones de las API's estándares, podrían obligar a Google pagar varios billones de dolares de compensación:  hay que recordar que Oracle pidió 6 billones de dolares para evitar entrar a juicio.

Google no puede quedarse los brazos cruzados:

• Lanzo dos lenguajes, Go para system programming y Dart para interfaz al usuario.  Dart entro en el proceso de estandarización con ECMA, el mismo grupo de Javascript y C#
• Creo las chrome-apps que son una forma de desarrollar aplicaciones desktop con Javascript/Dart, CSS y HTML.  Estaría pronto listo una forma de empaquetar chrome-apps para Android e iOS.
• Tiene AngularJS y Angular Dart, frameworks MVC para aplicaciones single-page en browser,
• Puso Chrome como el browser por defecto en Android 4.4
• Sigue empujando ChromeOS como sistema operativo para notebook, y desktop, a pesar que Android es un SO muy capaz para PC.  Tienen un porcentaje de mercado lo suficientemente interesante para crear interes en sus chrome-apps y todas las nuevas API's.
• Junto el grupo de desarrollo Android con el de ChromeOS y varias figuras históricas detrás del robotcito, como Andy Rubin, se fueron a otros proyectos en Google.

A mi, no me falta mas signos: están contados los días de Java como lenguaje preferido para aplicaciones Android.  Si con un lenguaje decente (no estoy hablando de Javascript) puedo desarrollar aplicaciones en Android, iOS, Desktop y Web, no tengo donde perderme.

En resumen, si Oracle se sale con la suya en el juicio:

• Dart va a reemplazar Java para desarrollo en Android,
• Java estará estancado en el servidor de aplicación como COBOL lo es en mainframe CICS.

Por mi parte, es bastante poco lo que desarrollo ahora con Java.  Y si el desarrollo sobre browser conquista el mundo móvil, tengo la alternativa de usar Scala-js.

Update: 28/01/2014: las chrome-apps se pueden ejecutar en desktops, iOS y Android

Android al ataque de los PC

Con 80% de las ventas de smartphone y 63% de las ventas de tablet, Android se consolida como el Windows de los equipos móviles.  Es un tema casi cerrado.

En el mundo de los PC, la interfaz Metro de Windows 8 acerca la UI Desktop PC tradicional al mundo Móvil Touch y entra en colisión con los OS nativos de este mundo.  Llega una nueva evolución de PC's que, además del teclado y ratón, usan monitores touch y donde Windows, Android, Linux Desktops, MacOS e iOS se pueden enfrentar.

El éxito de Android en este mercado, se ve bastante dìficil

• las aplicaciones Android están diseñadas para el touch y son optimizadas para pantallas relativamente chicas.  Es suficiente probar un emulador de Android en Windows con un PC con teclado, ratón y un monitor de 21 pulgadas, para darse cuenta que a muchas aplicaciones les sobra espacio y que el ratón es un muy pobre reemplazo del touch.

• Google no demuestra ningún interés para soportar Android  en equipos tipo PC.  De hecho, para laptop PC, su solución es ChromeOS, como en el Chromebook Pixel, y es basada en el uso de su browser Chrome como interfaz primaria.  Tampoco se sabe de avances concretos para fusionar Android y ChromeOS.

• No se a que punto Google está interesado en Android mismo en el largo plazo:
• Samsung es el gran ganador en el mercado de los smartphone basados en Android, tanto que se transforma en un gran competidor para Google, o, por lo menos, en un problema.
• Amazon y fabricantes de China se basan en Android pero no en las aplicaciones de Google como Play, Maps, Search quitándole toda posibilidad de monetizar Android.  El mayor riesgo con Samsung es que podría hacer exactamente lo mismo en algunos mercados importantes como China e India.
• el uso de Java como lenguaje de programación trae problemas legales con Oracle. El lenguaje alternativo de Google para el desarrollo de UI es Dart y, por el momento, este lenguaje tiene como objetivo el browser.  Su otro lenguaje, Go, esta orientado al "system programming" como reemplazo a C.  Se ve lejano entonces como Google podría no depender de Java en Android.
• los mensajes de marketing de Google enfatizan los productos "Chrome", "Play" y "Nexus" sobre "Android".  Durante su última conferencia I/O, Google no anuncio nada de Android y se enfocó en los servicios Google Play.  Cuando finalmente anunciaron Android 4.3, fue en la misma presentación donde lanzaron Chromecast y el nuevo Nexus 7.  Claramente la énfasis comunicacional no es "Android".

No obstante, fuera de Google, hay varios actores de la industria que sí se interesan en usar Android o, por lo menos, quieren soportar las aplicaciones Android en equipos tipo PC.


Fabricantes de PC

Los fabricantes de PC están confrontados a un problema serio:

• su mercado primario está en pleno declive.  Tienen que entrar en el mercado de las UI basadas en touch, incluyendo smartphone y tablet, pero sin abandonar a sus PC's  Para eso, ya inventaron varias categorías intermedias:
• híbridos laptop/tablet o equipos donde el monitor se separa del teclado o donde el teclado se guarda por debajo del monitor, 
• all-in-on con pantalla detachable ofreciendo un tablet enorme,
• all-in-one con pantalla reclinable hasta quedar horizontal, llamados tabletop.

• Windows 8 era el SO natural para todos estos nuevos equipos pero no ha tenido el éxito esperado.  El modo "desktop clásico" sigue siendo el más usado y los usuarios pidieron y obtuvieron la vuelta del menú inicio en 8.1.  Aun como sucesor natural de Windows 7 para PC tradicional, Windows 8 se vende lentamente comparando con Windows Vista.   Windows RT, la versión Metro "pura", es un fracaso de proporciones épicas y los desarrolladores no se entusiasman con las API's WinRT, necesarias para generar aplicaciones con la Metro UI.

Entonces, varios proveedores buscan en Android una solución para sus soluciones compatible con touch:

• Algunos pre instalan Bluestacks para aprovechar la gran cantidad de aplicaciones Android,
• o tienen un ambiente dual Windows-Android.  
• Finalmente, otros usan solamente Android como SO como en el HP Slate 21 y Acer/Gateway N1-2400.

Fabricantes de "smartphone convergentes"

Son smartphone que conectados a un monitor, teclado y ratón, sirven como desktop. Los 2 màs conocidos son:

• El Motorola Atrix que funciona con Android en modo smartphone y con Firefox en modo desktop.
• El proyecto Ubuntu Edge propone usar Android en modo smartphone y Ubuntu en modo desktop.  Como comparte el mismo kernel de Linux, puede correr las aplicaciones Android en forma nativa.

Tengo que reconocer que no entiendo porque Google, ahora dueño de Motorola, no saca un "Atrix Pixel" basado en una fusión ChomeOS/Android.  

Fabricantes de Android Mini-PC

Son sticks que se conectan a monitores y son fácilmente transportables. Creo que su uso como Desktop PC es limitado mientras no usen monitores con interfaz touch.

Es probable que sus primos tecnológicos, como las consola de juego Android (tipo Ouya) y los Android TV Box.(media center.basados en XBMC) tendrán éxito antes.  Si es asi, podria haber un efecto contagioso para los Mini-PC.  Y, de nuevo, Google no va en esta dirección, ya que luego del fracaso del Nexus-Q, lanzaron Chromecast, un stick basado en Chrome.


Conclusión

Veo montones de fabricantes interesados en adoptar Android para PC.  Al mismo tiempo, veo a Google muy poco interesado en este mercado.

Si tengo que apostar por el éxito de uno de los productos, voto por el HP Slate 21 y el Gateway N1-2400.

Plataformas para Scala

Algunos comentarios a raíz de esta conversación en Linkedin

Si no me equivoco, hasta ahora se puede desplegar Scala sobre:

• la JVM y todos los Sistemas Operativos (OS)  soportados por ella.  Según comentarios en la conversación de Linkedin, Oracle soportará iOS pronto con Java8,
• dalvikVM la VM en Android,
• la CLR de .Net, principalmente para Windows.
• LLVM
• Javascript

Las 3 primeras opciones son las más estables y soportadas.  Veo pocas razones de usar .Net excepto si se quiere usar una (muy rara) API que no exista en Java.

Me gustaría mucho que el soporte de LLVM sea más maduro. Si el boom de Internet of Things (IoT) se confirma, vamos a tener que programar para dispositivos como Arduino, los cuales no tienen suficientes recursos para correr una JVM.  Sin contar que Google Chrome soporta LLVM también.

Yo no compro el argumento, clásico a esta altura, que para aplicaciones con interfaces al usuario (UI), un lenguaje dinámico es más adecuado.  Incluso con jQuery, programar Javascript es un dolor de cabeza. así que bienvenido a scalaJS.  Claro que 16MB para un "hola mundo" es un requerimiento un poco exagerado.

Taxonomía de equipos y dispositivos

Super entretenido el mercado de los dispositivos inteligentes. Ahora que los fabricantes de PC tienen que recuperar el terreno perdido a los smartphones y tablets, hay innovación por todas partes.  Sin contar que los grandes del mundo móvil como Apple, Samsung, Google están buscando la nueva revolución.  Las innovaciones que he visto hasta ahora:

• híbridos laptop PC / tablet.  Antes de Windows 8, ya habían teclados para tablets que los transformaban en algo similar a netbooks.  Ahora con Windows 8, se popularizo aun mas el concepto.
• híbridos Desptop PC / tablet como este Asus. Eso es bastante más radical pero tiene sentido para un equipo que no se mueve mas que dentro de una casa o de una oficina.
• phablets o smartphone con pantallas tan grandes que sirven como tablets.
• smartphone que se enchufan a tablets como el asus padfone
• SmartTV o Android TV stick que transforman un monitor HDMI "tonto" en SmartTV
• Sistemas Operativos para PC como el ChromeOS que permiten tiempos reducidos de encendido, alta duración de batería, bajo esfuerzo de administración o sea un SO con algunas características de tablets.
• Y finalmente llegan los lentes, relojes y otros dispositivos que se llevan puestos.

Con todo eso, ya empieza a ser difícil clasificar los dispositivos  ¿Si agrego un teclado y un ratón a una tablet, no seria entonces un PC?  ¿Si una tablet tiene una duración de batería de 5 horas, como el Microsoft Surface Pro, es realmente una tablet si tengo que andar con el cargador por todas partes?

Aquí va mi intento por clasificar este caos.


Clasificación por Sistema Operativo

He visto que para definir la post-PC era, algunos usan el sistema operativo (SO) como gran diferenciador.  El SO es importante porque condiciona a las aplicaciones que usamos a diario y había, hasta ahora, una fuerte correlación entre el SO y el tipo de dispositivo

• En caso de Apple la distinción esta clara.  iOS es su SO para sus dispositivos Touch con recursos limitados, los iPhone e iPad .  MacOS (ahora OS X) es el SO para sus equipos tipo PC.  

• En caso de Microsoft no es tan claro.  Windows fue creado para dispositivos hambrientos de electricidad con teclado y ratón, o sea para PC.  Microsoft tuvo que cambiar fuertemente la interfaz en Windows 8 para adaptarlo al Touch.  Si se quiere preservar la batería, hay que usar el Surface RT y olvidarse de las aplicaciones anteriores a Windows 8.  Para usar el Surface Pro hay que tener cerca el cable de poder y tener teclado/ratón para aplicaciones pre-8.  Y no he mencionado aun todos los sabores de Windows Phone.  Sin lugar a duda, Windows es un SO para PC que migra difícilmente al Touch.

• Google tiene Android para equipos Touch y ChromeOS para laptop PC.  Super claro, hasta mirar lo que hacen algunos fabricantes con Android.  Los Android Mini PC son como gabinetes de un Desktop PC.  Intel predica una nueva generación de laptop o híbridos laptop/tablet de bajo costo basados en Android.  Finalmente, Android se usa para SmartTV y Google confirmo que Glass usa Android.  ¿Alguien dijo que Android era fragmentado? Ahora si, lo es de verdad.

• Ubuntu trata de crear una versión de su Desktop, Unity, para tablet.  No he escuchado intentos de llevar los otros desktop Linux como KDE o gnome al mundo móvil.  Finalmente, existe Firefox OS para smarphone, poco puedo decir al respecto.

En resumen, el SO ya no es concluyente para definir el tipo de dispositivo   

Clasificación por servicios

Poco a poco, los dispositivos son capaz de prestar todos los servicios como escuchar másica, ver vídeos. tomar fotos, realizar llamadas, navegar en la web, leer libros, jugar, etc, .La experiencia de uso varia según el tipo de dispositivo pero es el mismo servicio.   He visto turistas usar tablets de 10 pulgadas para tomar fotos: se ven algo ridículo, pero funciona.  He visto profesionales usar una tablet de 7 pulgadas como teléfono: incluso con audífonos bluetooth es incomodo, pero funciona.

Entonces, los servicios tampoco son diferenciadores.  Claro que dejo fuera de este análisis los dispositivos especializados como cámaras fotográficas de alto rendimiento

Clasificación por hardware

Es evidente que el peso, la duración de la batería, el tamaño, el tipo de input devices (touch o teclado), el ruido/calor emitido, el tipo de monitor, son características importantes.   Pero me parece que son una consecuencia más que un diferenciador.

Por ejemplo, si quiero bucear la web acostado en la cama es mas cómodo un equipo liviano, que no emite calor y ruido y que es fácil de mover (o sea sin cables).  Las tablet son una solución, como también un smartphone capaz de proyectar su salida a la TV frente a la cama.


Clasificación por forma de uso

Es la clasificación que prefiero.

Un smartphone es algo que se puede sostener y usar con una sola mano.  Es fácil llevarlo en todas partes porque cabe en un bolsillo y es liviano. 

Una tablet es algo que se puede sostener en una sola mano, pero requiere de las dos para operarla.  Es fácil moverla dentro de un espacio cerrado (casa, oficina).  Es factible pero incomodo llevarla al aire libre.

Para usar el PC, hay que dejarlo sobre una superficie plana y su uso requiere de las dos manos.  Los Desktop PC no se mueven.  Es factible pero incomodo mover un laptop PC dentro de un espacio cerrado (cables, calor) y es aun más incomodo sacarlo al aire libre.

La TV no se mueve.  La diferencia con el desktop PC es la distancia hacia el monitor, lo que obliga a usar un control remoto o reconocimiento de movimientos corporales.

Finalmente los dispositivos como lentes, brazaletes, relojes son tan móviles que siempre podremos llevarlos con nosotros. 

Los Android Mini PC y Android TV stick...

...son otra categoría de dispositivos que, al parecer, le esta yendo bien.  No tengo cifras de ventas pero es suficiente ver la cantidad de productos que salen a la venta, como en esta pagina que informa de las ultimas novedades y donde hay algo nuevo cada 5 días.

Esta evaluación permite hacerse una idea de lo que son estos productos.  En resumen, son dispositivos que caben en un bolsillo, reciben su energía vía USB y se conectan a un televisor o monitor vía HDMI.  "TV stick" se refiere a un uso tipo Media Center para jugar, ver vídeos, escuchar música. Algunos vienen con un control remoto físico y otros con una app para smartphone.  "Mini PC" se refiere a un uso tipo PC desktop y se necesita ratón y teclado inalambricos.  Casi todos vienen con Android pre-instalado pero existen distribución de Linux como picuntu para los que todavía creen en el éxito de los Desktop Linux.  Finalmente, los benchmark indican que son equivalentes a las tablets top del mercado.

Mi laptop actual es como un desktop que se mueve entre el escritorio de la casa y el de la oficina.  Si dejo estacionado un monitor, teclado, ratón y los distintos cables en cada destino, tengo un PC mucho más fácil de transportar.  Además, debido al precio (entre 60 US$ y 110 US$) puedo renovarlo cada año para quedar al top de la tecnología.  Considerando que no es necesario renovar el monitor tan frecuentemente, obtengo un costo total de uso (TCO en las siglas ingles) mucho más bajo que un laptop.

Parece atractivo, resta saber si puedo hacer desarrollo en la nube, con el IDE corriendo en el Mini PC y el compilador en un servidor remoto.  Tema para investigar empezando por ver el estado del arte de los IDE sobre Android

Los enredos de Google

Contrariamente a mi pronostico, le esta yendo bien al Google Chromebook.  Samsung y Acer ya lo fabrican. y HP, Lenovo se suben al carro pronto.  Acer declara tener ventas no despreciables y hay periodistas que hablan muy bien del producto.

Como estoy buscando no llenarme de dispositivos, el Chromebook es una opción como PC+tablet.  Yo no soy gamer y solamente necesito, además del browser, un ambiente de desarrollo (IDE) y un terminal remoto. Un IDE web como Clond9 esta cerca de mis necesidades, le falta soportar a Scala y Akka.  Si este articulo esta en lo cierto, las aplicaciones Android podrían funcionar en Chrome, lo que aumentaría la posibilidad de tener un IDE basado en Android (al estilo de AIDE) que pueda usar.  Entonces, si eso ocurre me comprare un Chromebook.

Suponiendo de nuevo que el articulo es cierto, que Android y Chrome se fusionan y crean la "plataforma Google" de smartphone a PC pasando por tablets e híbridos y derivando a Google Glass .  ¿No sería entonces atractivo, ademas de ser usuario de la plataforma, usarla también como target de mis aplicaciones? La respuesta es obviamente si.

Y es allí que se enreda bastante porque las opciones de desarrollo propuestas por Google son variadas:

• web pura (HTML, CSS, javascript), obviamente
• Dart, "el mejor javascript" de Google que compila a javascript o a DartVM
• native client, usando cualquier lenguaje que compila a LLVM, incluyendo C, C++.
• Java, Dalvik y el Android SDK.
• y queda el lenguaje Go: ni idea donde cabe en esta supuesta plataforma.

Creo que Google va a tener que simplificar este cuento.  De la misma forma que están ordenando los productos para sus usuarios, caducando los que no tienen éxito e integrando los que quedan, tienen que facilitar la vida a la comunidad de programadores que le dan valor a su plataforma.

Ahora, como lo van a hacer es especulación pura.  Creo que van a usar los siguientes principios:

• van a dar menor énfasis a la web.  Google, ya ha declarado que su negocio principal es el "móvil".
• se van a alejar de los temas legales, lo cual implica mayor control sobre los lenguajes y API's.
• al mismo tiempo, van a querer molestar lo menos posible a los programadores que invirtieron tiempo en aprender su tecnología (como lo que ha hecho Microsoft tantas veces cambiando las reglas del juego).
• finalmente, no tienen que perder su imagen de abierto y buena onda en la comunidad nerd.

O sea, están fritos, no veo como nos van a migrar a Dart y Go sin generar algún nivel de malestar.  ¿Si Android es el nuevo Windows, como Google evitara ser el nuevo Microsoft?

Lo que amo de Scala: su cercanía a Java

Estoy en el proceso de registrar lo indispensable de Scala para el día que mire seriamente a otros lenguajes  "Mirar seriamente" es hacer un poco más que leer un tutorial y programar un "hello world", o sea demanda algo de esfuerzo.  No tengo el tiempo de revisar todos los lenguajes que se inventan así que debo filtrar los potenciales candidatos.  Por el momento, son Kotlin, Ceylon e Xtend porque todos comparten la cercanía con Java.

Esta cercanía con Java es importante por varias razones.

Por la JVM, los servidores de aplicación y en general los middleware basados en la JVM

No todos tenemos la suerte de trabajar para una startup que puede escoger completamente su arquitectura y, por ende, debemos negociar con el cliente la tecnología que se usará.  Casi todos los clientes tienen una plataforma definida y resulta más o menos difícil alterarla según lo que esta definición cubre.

Casi siempre, la definición de plataforma incluye la arquitectura física (servidores, redes, sistemas operativos, estaciones clientes) y la arquitectura de ejecución, o sea los middleware como los servidores de aplicación, servidores de mensajería y las bases de datos.  Es muy frecuente poder usar un middleware basado en la JVM

Otras veces la definición de plataforma incluye la arquitectura de desarrollo o sea, los lenguajes, las API, los frameworks, patrones y hasta el IDE de desarrollo.  En este caso, si el cliente pide Java+Spring-*, hay que tratar de convencerlo.  En la practica, es más fácil negociar cambiar la arquitectura de desarrollo que las arquitecturas físicas y de ejecución.

En resumen, la JVM y sus middleware (Tomcat, Websphere, Weblogic) son importantes por un tema de oportunidad laboral   

He leído que otros destacan la robustez, el performance, la seguridad y en general, la madurez de la JVM.  Estoy de acuerdo con estos argumentos y son las razones por las cuales, hay middleware basados en la JVM en todas partes.

Por las toneladas de API's y framework para Java

La popularidad de Java permite que haya soluciones para todo y a menudo de bajo costo.  No recuerdo cuando fue la ultima vez que me preocupe de encontrar un driver JDBC compatible con la versión de mi base de datos: no quiero pasar por lo mismo si me salgo de la JVM.

Poco a poco, hay API y framework que son optimizados para Scala, pero siempre habrá necesidades de usar esta vieja API Java que saca de apuro.

Por la sintaxis

Java hereda muchas ideas archi probadas en distintos lenguajes y que son familiares para muchos programadores.  Scala sigue usando:

• la sintaxis básica de C usando bracket y donde una llamada a una función "f" se escribe como en las matemáticas básicas: "y = f (x)"
• strong typing.  Me gusta que el compilador y el IDE trabajen por mi y no al revés
• orientación al objeto.  Definitivamente no es la solución para todo, pero es necesario tenerla.
• programación genérica. Hace el código más legible.
• estilo imperativo.  No siempre se puede programar al estilo funcional en forma elegante.  El estilo imperativo saca de apuros, lo tengo comprobado.

Por los entornos de programación

Es tiempo ganado si no tengo que cambiar mi IDE (Netbeans, Eclipse), mi build automation (ant, maven), etc.

Lista de lenguajes que descarte

Todos los criterios anteriores me hicieron descartar:

• los derivados de Lisp como Scheme, Clojure.  No hay ninguna razón para mantener una sintaxis que va contra años de enseñanza de las matemáticas.  Yo creo que usar estos lenguajes para tutoriales de programación funcional crea una barrera completamente absurda.
• Ruby, Python: son dinámicos, su entorno "natural" no es la JVM.
• Haskell, Erlang: no corren sobre la JVM y su sintaxis me recuerda demasiado a Lisp.
• fantom: no tiene programación genérica.

Lo que me agrada de Scala: de NPE a Option

Sigo poblando mi lista de lo que me gusta del lenguaje Scala.  La motivación es poder comparar con otros lenguajes parecidos que están llegando para la JVM como Ceylon/Kotlin/Xtend y tener claro lo que tienen que ofrecer estos lenguajes para que valga la pena mirarlos con un poco más de detalle.  En este contexto, cabe mencionar esta encuesta de Infoq donde hay una lista de lenguajes potenciales y donde Scala y Clojure están bien posicionados.

Los títulos anteriores de mis entradas sobre el mismo tema empezaban con "Lo que amo de Scala".  Ahora voy a hablar de algo que solamente me agrada.

Donde Scala se contagia de Java

NullPointerException o NPE existen porque cualquier objeto en la JVM puede tener el valor null.  No hay forma en Java garantizar que un objeto es distinto de null excepto validandolo antes de referenciarlo.  Si se valida en forma paranoica todos los parámetros de entrada  y retornos de los métodos, se agrega mucho código bastante inútil.  La otra solución es no validar nada y capturar la NPE lo más inteligentemente posible. Si se opta por no validar, en algún momento aparecerá el NPE en algún log y ojala antes de entrar en producción.

Scala corre sobre la JVM e necesita interoperar con código Java.  Sigue existiendo el valor null y la posibilidad de NPE incluso en código 100% Scala.


Valores opcionales

Java no permite hacer la distinción entre un objeto que es nulo por error o intencionalmente sin valor.  Un objeto puede estar sin valor:

• porque es naturalmente opcional, como el calculo de un valor máximo sobre una colección vacía o el retorno de una consulta por una primary key que no existe.
• porque no conocemos aun su valor:
• hay que rescatarlo con algún proceso largo, 
• es un valor externo que debemos rescatar de parámetros de ambiente, archivos de configuración o preguntar al usuario.

En Java se puede manejar estas situaciones con objetos nulos o lanzando excepciones.  En SQL se puede definir un campo como "NULL" o "NOT NULL".  Scala soluciona este caso con el tipo Option y los subtipos None y Some.

Ejemplo de un atributo que es opcional y cuyo valor se conoce al runtime.


Un caso frecuente en mis aplicaciones es durante la inicialización de actores con el framework Akka.  Generalmente, los actores se crean en unos pocos thread y si su inicialización es larga (por ejemplo, porque tienen que rescatar algo de una base de datos) el arranque de la aplicación akka es lenta.  Entonces, el arranque del actor se hace en 2 pasos: la creación del actor mismo y luego su inicialización procesando un mensaje de "arranque".  Entre estos 2 pasos hay atributos del actor que no están conocidos aun.


Algunos comentarios finales

Entonces, porque solamente me agradan los Option y no los adoro:

• Habría sido espectacular eliminar el valor nulo y la NPE por completo.  Pero prefiero mil veces mantener la interoperabilidad con Java, la cual si adoro.
• Ceylon y Kotlin tienen una sintaxis especial para manejar los nulos la cual permite código más corto y más legible.  Scala no usa sintaxis especial, sino la capacidad de su type system.  El mismo type system permite implementar tipos equivalentes como los Box/Full/Empty/Failure del framework Liftweb .

En resumen, Scala mejora Java sin erradicar por completo el problema.