Les développeurs Java se sont élevés contre le projet d'Oracle de limiter l'accès à certaines API de Java Standard Edition 9, et plus particulièrement celle de sun.Misc.unsafe. Bien que non officiellement supportée, cette dernière procure des bénéfices comme l'accès à la mémoire native surpassant ainsi les limites de Java, a indiqué le CEO d'Hazelcast Greg Luck, qui est impliqué dans la Java Community Process visant à amender Java. Sa société embarque cette API dans sa plateforme de données en mémoire permettant le développement et la gestion de grands caches de données. « Fondamentalement, ce qui se passe c'est que des centaines d'entreprises reposent maintenant sur cette API privée », a fait savoir Greg Luck.

Oracle a proposé de verrouiller l'accès à cette API pour rendre Java plus modulaire. Les détracteurs de l'API estiment qu'elle n'aurait jamais dû être utilisée car elle ne repose pas sur la partie standardisée de Java, a expliqué Greg Luck. Une proposition d'un groupe de travail est en cours pour standardiser les composants sécurisés de l'API, alors que ceux qui ne sont pas sûrs seraient retirés. Dans son combat, Hazelcast n'est pas seul et d'autres entreprises comme Azul Systems l'ont rejoint. Mais Oracle ne veut rien savoir selon Greg Luck. « Si on enlève cela, on tuerait un grand nombre de logiciels d'infrastructure qui reposent actuellement dessus », a prévenu Greg Luck. La société DripStat, spécialisée dans le suivi de la performance Java va même jusqu'à évoquer un « désastre » qui pourrait « complètement détruire l'écosystème autour de Java » au cas où l'API sun.misc.Unsafe soit bloquée dans Java 9.

Un acte délibéré d'Oracle ?

Une option permettant d'éviter ce problème pourrait être de continuer à utiliser Java 8 et ne pas appliquer la mise à jour vers Java 9 dont la sortie est prévue en 2016. La firme de Larry Ellison n'a pour l'instant fait aucun commentaire sur cette affaire. Mais on pourrait bien se demander si le retrait de l'API sun.misc.Unsafe dans Java 9 ne serait pas un acte délibéré d'Oracle pour privilégier ses propres logiciels d'infrastructure - ou ceux poussés par tout ou partie de son écosystème partenaires - au détriment de ceux qui s'appuient sur elle.