3 prédictions pour Java en 2013

1. L’explosion de la demande en expertise Java

Les besoins en développement Java n’ont jamais été aussi importants, et la demande va être démultipliée par plusieurs tendances de fond :

- L’arrivée d’HTML5 et d’une multitude de frameworks JavaScript/CSS est en train de considérablement moderniser le Web. Cela pousse les entreprises à revoir entièrement l’ergonomie et le design de leurs applications.

- L’explosion des smartphones et des tablettes sur Android. Android a maintenant dépassé iOS en nombre d’utilisateurs, mais surtout en termes de croissance. Les nouveaux appareils proposés par Amazon et Google sont à des prix très abordables. A tel point que le marché des “liseuses” et autres “e-book readers” est d’ailleurs en train de disparaître.

- L’hébergement d’applications Java, jusqu’ici complexe et coûteux, est en train de devenir aussi simple et bon marché que de l’hébergement PHP. A nouveau, des acteurs comme Google ou Amazon y sont pour beaucoup, ainsi qu’une multitude d’acteurs spécialisés, dont Ippon Technologies avec sa filiale Atomes.

Ces 3 tendances nécessitent toutes des compétences pointues, et réussir un projet Java “moderne” est paradoxalement devenu à la fois très facile (grâce à la multitude des frameworks et outils) et très complexe (car il faut maîtriser toutes ces technologies). L’expertise Java, c’est-à-dire la compétence et l’expérience permettant de réaliser ce type de projet va donc être particulièrement demandée cette année.

 

2. La guerre des géants du logiciel va s’amplifier

En 2012 déjà, les géants du logiciels comme Microsoft, Oracle, IBM, Google, Amazon, Apple ou VMWare ont arrêté de prendre des gants et se sont affrontés sur les terrains économiques mais aussi légaux (guerre des brevets, en particulier).

 

Cette guerre n’est pas du tout à l’avantage de leurs utilisateurs français :

- L’ensemble de ces entreprises est américaine : nous ne sommes qu’un marché qu’ils vont se partager, et les entreprises et administrations françaises vont continuer de payer très chers des logiciels et une technologie que nous ne possédons pas.

- L’évolution de Java, un moment boostée avec l’arrivée de Java EE (suite à la concurrence de Spring), va continuer de stagner. Le JCP est redevenu englué dans des guerres de tranchées qui empêchent, à nouveau, toute innovation.

 

Les sommes en jeu sont ici considérables, et certains de ces acteurs vont mieux tirer leur épingle du jeu que les autres : pour moi les mieux placés en 2013 sont Google, Oracle et Amazon. Et quoi qu’il en soit les vainqueurs seront américains !

 

3. La fin de la mode des langages “alternatifs” sur la JVM

Pour finir je vous propose une prédiction plus audacieuse et risquée : la fin de la mode des langages alternatifs comme Groovy, Scala, Jython, Clojure, Kotlin ou Ceylon. Plus précisément, je pense que seul Groovy va subsister car il est le plus populaire, l’un des plus anciens, et qu’il est soutenu par l’excellente stack Grails.

 

Tout d’abord, cette prédiction est liée ma première prédiction : il y a aujourd’hui tellement de nouveautés à apprendre (HTML5, mobilité, devops), que je rencontre peu de développeurs qui ont le temps d’apprendre en plus un langage supplémentaire. Et s’ils ont ce temps, il vont plutôt s’orienter vers un langage et une stack en dehors de la JVM, comme Ruby on Rails.

 

Cette prédiction s’appuie également sur les points suivants :

- La demande en compétences dans ces langages a commencé à stagner en 2012 : http://www.indeed.com/jobtrends?q=groovy%2C+jython%2C+scala%2C+clojure&l=

- Les très rares projets Play! que j’ai pu voir chez des clients étaient tous codés en Java

- Les langages “populaires” comme Groovy ou Scala n’ont pas de bonnes statistiques Github (nombre de “stars” ou de “forks”)

- Les projets moins populaires comme Kotlin ou Ceylon, annoncés à grand renfort de pub en 2011, ne sont toujours pas en version stable en 2013

 

Sur ce, je vous souhaite une bonne année 2013 et vous donne rendez-vous dans un an pour faire un bilan de l’année !

TwitterFacebookGoogle+LinkedIn
  • arn

    Assez d’accord sur l’ensemble de cet article :)
    Le JDK 1.8 (closures,…) va sans doute également contribuer à diminuer l’intérêt pour les langages alternatifs sur la JVM même si certains dirons toujours que c’est très loin de combler le “gap”.
    Et il y a déjà un langage alternatif à java inévitable (hélas), c’est Javascript.
    Une question que je me pose pour 2013: est-ce que ça sera enfin possible de développer en java (ou d’autres langages de la JVM) sous iOS via le portage de la JVM pour processeur ARM (qui existe déjà)?

    • bjb

      Concernant iOS, le problème n’est pas d’être “possible” mais que Apple “accepte” de mettre à disposition (dans son marché) une JVM d’ou qu’elle vienne. Cela signifierait pour eux lacher un peu la bride sur le contrôle des applications (sans même parler de l’arrivée potentielle du modèle des Applets et de Webstart qui feraient exploser leur modèle financier). Je doute qu’Apple fasse cela de bon grès. Par contre je pense qu’il est juridiquement et techniquement possible de leur imposer une JVM, par exemple en utilisant un refus de vente au titre du L420-2 pour quelqu’un qui essayerait de faire inscrire une JVM dans l’Apple Store (vu que cette inscription est une prestation payante). En théorie, ce serait à Oracle de faire le taf, mais je doute qu’ils jouent à ce jeu… reste des JUG par exemple ;-) Cela ferait un beau coup médiatique en tout les cas pour celui qui le lance !

      • arn

        Apple accepte déjà. Quelqu’un d’Oracle avait confirmé qu’Apple est d’accord pour qu’une app embarque une mini-JVM pour être livré (comme pour flash, mono,…) via l’Apple Store. C’est déjà possible sur l’Appe Store MacOS.

        En fait même pour l’Apple Store iOS, Oracle a déjà une solution commerciale pour développer HTLM5 + JVM ARM.

        Il faudrait juste une solution un peu plus ouverte.

  • Eric

    Je suis d’accord avec le premier et le second point de cet article…

    Concernant le troisième point, j’espère que nous ne verrons pas la fin des langages alternatifs car ils donnent des axes de réflexions concrets utiles pour les innovations du langage Java. Ils permettent justement de faire remuer les process du JCP pouvant être quelque peu lourds.

  • bjb

    Julien, permet moi d’en rajouter une 4e :

    2013 va être l’année de la sécurité Java, car les failles vont continuer à déferler et faire les gros titres. Deux incertitudes : l’attitude d’Oracle et cette le la communauté face à cette menace de leurs “business” respectifs ;-)

    • arn

      “déferler”??
      Les problèmes récents étaient sur la sandbox des applets je crois, pas coté serveur.

      “It’s really unfortunate for a couple of reasons, one it’s more of a PR problem than it is an actual problem, that is really depressing because Java is very secure especially on the server side. What problem we are seeing is with using Java in a browser as an applet, and when is the last time that you actually run an applet? These things don’t need to be enabled anymore, and the problem is specifically that browsers try to rely on the Java Sandbox for security and reality is the Sandbox doesn’t work very well, it never work”
      (http://www.infoq.com/interviews/lee-java-di)

      • bjb

        Depuis quand la sandbox applet est techniquement différente de celle de RMI (JRMP) et donc même JMX ;-)
        Sinon IIOP, c’est souvent plutôt l’absence de toute sécurité activée qui pose problème :(

        La propagation est plus aisé dans le cas du java plugin car la probabilité de présence d’un navigateur avec java plugin est bien supérieure à celle de tomber sur un serveur utilisant ses technologies d’appels distant et dont le port serait ouvert. Qui plus est, la technologie applet présupose un transfert de code entre les deux machines, ce qui n’est qu’optionnel et pas toujours actif dans le sens inverse pour le coté serveur. Mais “plus rare” ne veux pas dire impossible :)

        Je peux me tromper, mais avec le bruit que ses failles ont faites et le levier qu’elles ont offert à leurs “inventeurs”, je continue à penser que cela va susciter d’autres “vocations” parmi les hackers.

        Il reste capital de n’avoir que des VM dont le minima de version colle au seuil de sécurité indiqué et y comprit coté serveur.

        A+

        JB

        • arn

          Qui active encore la sandbox JRE coté serveur (security manager)?
          (je me demande s’il y a d’autres langages/env qui ont une sandbox coté serveur, “intra” process,..)

          Ca pose pas mal de contraintes et ça impacte les perfs.

          Autant isoler le process du serveur d’application grâce à l’OS (chroot,…).

  • http://addinquy.tumblr.com/ Christophe Addinquy

    En terme de frameworks, je “prédit” une montée des frameworks Javascript et une baisse de l’importance des frameworks Java. En fait de prédiction, d’ailleurs…
    Pour la prédiction #3 je l’espère fausse : l’évolution du langage Java est au stade de la paralysie. En fait Java est maintenant un langage “legacy”. Les langages alternatifs comme Scala, Clojure et Ceylon donnent un bon coup d’air frais et un coup de reboost, en ce qui me concerne !

    • arn

      Je pense pas que le JDK 1.8 soit de la paralysie, c’est juste de la lenteur, et le prix la très bonne compatibilité ascendante.

      Groovy, Scala, pourquoi pas, mais les autres n’auront sans doute jamais la “masse critique” nécessaire.

      Pourquoi investir aujourd’hui sur une codebase en Ceylon sur une app en production à maintenir dans les N prochaines années?
      C’est déjà risqué de faire du Scala de ce point vue là.

      Quand à Javascript, c’est un language pénible à cause du manque de typage statique, mais son point fort est qu’il est deployé partout donc inévitable, mais c’est n’est pas lié à la qualité du language.

  • Patricio

    étrange de ne pas mentionner RedHat dans les acteurs importants…
    On parle de Java et pas du serveur d’app numéro 1 du marché… étrange.

    • http://twitter.com/juliendubois Julien Dubois

      Ce n’est pas étrange : la capitalisation de Redhat c’est 10 MM. C’est pas mal. Mais comparé à Apple (472MM), Google (237MM), IBM (217 MM), Microsoft (226 MM), Oracle (165 MM), Amazon (123 MM) ou VMWare (41 MM, auxquels il faudrait ajouter les 51 MM de EMC, sa maison mère)… Redhat reste un nain à côté de ses boîtes, là je n’ai compté que les “gros”.

      Quant à JBoss serveur d’app numéro 1 : cet article n’est pas une comparaison sur les serveur d’appli, et si c’était le cas je ne mettrai clairement pas JBoss en numéro 1. Ni en termes de chiffre d’affaires (ce serait Websphere), ni en termes de nombre d’utilisateurs (ce serait Tomcat).

      • patricio

        Cet article est un article sur l’économie donc?

        Et java se résume aux serveurs d’app?

        Ok je me suis trompé dans ce cas, mea culpa.

        Depuis ses aoveux sur la qualité de son app serveur, on ne peut pas dire qu’IBM se défonce sur le middleware comparé à JBoss qui ne cesse de contribuer aux specs et à fournir des frameworks innovants. Mais bref, je preche pour ma paroisse, désolé.

        • http://twitter.com/juliendubois Julien Dubois

          L’économie reste un aspect important, quand on parle des “tendances 2013″.

          Pour les serveurs d’app c’est toi qui a lancé le sujet.

          Sinon je vais éviter de répondre sur la guerre JBoss/IBM, vu que je vais me fâcher avec les deux en parlant de Spring :-)
          Plus sérieusement, Redhat reste l’un des principaux contributeurs sur de nombreuses technologies majeures (Linux, Java EE, OpenStack), que ce soit en termes d’économie (c’est le plus gros “pure player”) qu’en termes de lignes de code. Par contre je trouve sa stratégie parfois un peu brouillonne (plein de projets lancés dans tous les sens).

          • patricio

            Il n’y a pas vraiment de guerre sur le front de l’innovation JEE, enfin je ne pense pas manquer d’objectivité sur ce point.
            Et concernant Spring, encore un bel exemple du petit (j’evite nain car je trouve cela pejoratif :) ) qui a tout chamboulé, pour qu’au final, les choses soient mieux.
            Je pense qu’on partage une vision assez commune sur plusieurs sujets abordés ici, c’est juste l’angle qui diffère ;)

      • patricio

        par ailleurs inclure JBoss dans un comparatif de CA sur un modele open source est quelque peu maladroit.

        Anyway, mon point était simplement de souligner openshift, openstack, l’approche big data avec Hibernate OGM et le partenariat mongoDB, ce qu’apporte Arquilian dans le TDD, …

        Il n’y a pas que les “gros” qui font bouger les choses.

  • http://twitter.com/michaelisvy michaelisvy

    Ca serait tellement plus simple s’il y avait un seul langage alternatif. Ca permettrait de consolider une population de développeurs ‘alternatifs’ et côté Oracle on s’affolerait un peu en voyant arriver une vraie concurrence.

    Ceci dit, je ne vois pas trop le business model derrière Dart/Kotlin/Ceylon. Pour Typesafe, ça pourrait peut-être marcher sauf s’ils se font racheter par une grosse boîte qui ralentit les ardeurs (et ça semble bien faire partie de leurs projets).

    Donc ma prédiction, si je peux me permettre, serait que 2 de ces 4 langages au moins seront au point mort d’ici 2 ans (plus du tout ou peu d’investissements de la part de la société créatrice, et des évolutions principalement communautaires).

    Bon, étant employé SpringSource/VMware, je ne dis rien sur Groovy/Grails, sinon ça risque de ne pas être objectif :).

  • http://twitter.com/MGazanayi Marouane Gazanayi
  • bruno

    Bonna analyse mais je crois plutôt que 2013 sera l’année des langages alternatifs et peut-être celui de Scala :)

    Merci Gatling d’ouvrir le bal du massacre !!!

  • http://twitter.com/lambdadevfr lambdadev

    “La fin de la mode des langages alternatifs”. C’est intéressant. Pourquoi pas après tout? “La mode change car elle est née du désir de changement” Je crois donc qu’on ne prend aucun risque à prédire la fin d’une mode :)

    Maintenant, quelle importance a la mode, dans la culture du développeur, quelle trace laisse-t-elle dans l’esprit et les réflexes des praticiens?

    Fut un temps, nous avions la mode du SOA. Il en est resté un goût certain pour les API, la formalisation des dialogues entre serveurs et services. On a oublié tout le bastringue Soap, les outils inutiles et chers etc.

    Puis il y a eu la mode de l’agile. Il en reste des équipes qui cherchent à dialoguer avec le client (quand elles le peuvent), un focus sur la qualité. De cette mode est née la mode actuelle du craftmanship, autrement de l’”artisanat” (certains mots en français permettent de faire ressortir certains aspects des concepts, qu’on ne verrait pas, exprimés dans une autre langue), la mode n’étant pas morte on ne sait pas encore ce qu’elle va laisser.

    Maintenant la mode des langages alternatifs. Certes… Mais derrière cette mode il y a mille besoins.
    * Data mining, machine learning, big data, parallélisation…
    * Plus de souplesse, de vitesse de développement, des releases plus fréquentes, un modèle métier moins tyrannique. Un langage plus proche de la prod.
    * Un modèle de développement moins lourd et maladroit que le modèle par couches adopté grâce à jee puis Spring, après tout si on regarde une application simple, de gestion, comme une manière d’appliquer des actions à des collections de données, on se dit que la programmation fonctionnelle n’est pas loin.

    La mode disparaîtra mais les besoins resteront. Et ce sont beaucoup de besoins où Java aura plus de mal à s’exprimer naturellement.

    Gabriel Kastenbaum

    Track leader sur les langages alternatifs à DevoxxFR

  • Bassem

    très bon article Julien

  • arn

    Je peux vivre sans IIOP :)
    On peut implémenter des WS sécurisés sans SecurityManager actif dans la JVM serveur quand même.