Discussion :

[Mickael_Istria]

Faut quand même:
-[...]
Tout ça n'est pas gratuit

Ceci couterait encore plus cher en changeant de langage entierement et en re-ecrivant tout plutot qu'en faisant juste des mises a jour et adaptations progressives du langage.

[Grogro]

Justement non, ils ont enlevé des choses (corba, applets, java web start, ...), ce qui fait que si tu les utilises, tu es obligé de changer ton code. Et vu le chemin qu'ils prennent, il ne serait pas surprenant que ce genre de surprises arrive sur d'autres LTS dans le futur, donc si, il y a des chances pour que les budgets doivent suivre, que ce soit pour payer les licences ou bien faire le portage.

Je ne suis pas spécialiste (je ne suis même plus dev), mais quel est l'intérêt pour Oracle de supprimer ces bibliothèques au risque de péter la rétro-compatibilité ? Trop de maintenance ?

[yildiz-online]

Ceci couterait encore plus cher en changeant de langage entierement et en re-ecrivant tout plutot qu'en faisant juste des mises a jour et adaptations progressives du langage.

Jamais dit le contraire, c'est en réponse à darklinux qui soutient qu'il ne faut pas de budget pour faire un upgrade java.

J'ai par contre omis de mentionner également l'éco système à mettre à jour (maven compiler / javadoc / source plugins par exemple)

Et pour avoir fait des migrations 8 -> 9 -> 10, je mettrais vraiment 'juste' entre guillemets, ce n'est pas une sinécure. (alors que 6 -> 7 -> 8 n'ont jamais posé de soucis)

[el_slapper]

Je ne suis pas spécialiste (je ne suis même plus dev), mais quel est l'intérêt pour Oracle de supprimer ces bibliothèques au risque de péter la rétro-compatibilité ? Trop de maintenance ?

Facturer du consulting, je suppose.

[Mickael_Istria]

Facturer du consulting, je suppose.

Non, c'est plutot lie au support et a l'investissement qu'ils sont prets a fournir: les developpeurs de Java sont deja pris pas d'autres briques plus critiques pour la continuite du succes de Java (en gros, les microservices). Oracle n'a pas envie de faire grossir l'equipe pour maintenir certaines parties qui ne sont plus rentables. Donc pour clarifier le jeu, ils sortent ces parties qui ne sont plus supportees par l'equipe coeur de Java comme ca c'est clair que la responsibilite est abandonnee par defaut.
Apres, en effet, il doit etre negociable de se faire monter sa propre JVM par Oracle avec des vieilles libs et peut-etre meme du support dessus. Mais comme ca n'arrange pas la plupart du monde, il faut surement nager dans les billets comme Picsou pour s'offrir tout ca.

[Grogro]

Apres, en effet, il doit etre negociable de se faire monter sa propre JVM par Oracle avec des vieilles libs et peut-etre meme du support dessus. Mais comme ca n'arrange pas la plupart du monde, il faut surement nager dans les billets comme Picsou pour s'offrir tout ca.

Ou importer tout simplement les composantes virées de la JVM standard comme des librairies legacy non maintenues, à la responsabilité du dev, Oracle ne pouvant en garantir la totale compatibilité ?

[darklinux]

Justement non, ils ont enlevé des choses (corba, applets, java web start, ...), ce qui fait que si tu les utilises, tu es obligé de changer ton code. Et vu le chemin qu'ils prennent, il ne serait pas surprenant que ce genre de surprises arrive sur d'autres LTS dans le futur, donc si, il y a des chances pour que les budgets doivent suivre, que ce soit pour payer les licences ou bien faire le portage.

Merci de citer mon propos : j ' ai dit aussi que dans le pire des cas , il fallait l ' adapté aux nouvelles normes , ce que fait n ' importe quelle développeur sans demande expresse

[darklinux]

Faut quand même:

-Installer sur les postes des devs
-Valider que ça compile (vu que les récentes JRE ont retiré des packages, JAXB par exemple)
-Installer et modifier la configuration des CIs
-Planifier l'installation pour gérer en temps de maintenance.
-Déployer la jre sur les machines
-Faire un minimum de tests de régression
-Faire des tests de perf
-Et accessoirement former les devs sur les nouvelles fonctionnalités.

Tout ça n'est pas gratuit

J ' aurais tendance à répondre : Débian ... encore une fois les tests de régressions / perfs , c 'est le travail de tous les jours ... Mais par contre le budget pour la formation , la oui est justifiable et nécessaire ... il faut enlevé ce pseudo pouvoir aux consultants

[Mickael Baron]

Bonjour,

Je reste sur Java sinon je devrais changer de rubrique ;-)

Personnellement, je trouve que c'est une bonne chose cette évolution. Java est longtemps resté sur des versions qui duraient. L'éco-système de Java est très riche, les outils sont très matures.

Je ne pense pas que changer de langages resolve le problème. Tôt ou tard les langages sont sensés évoluer (Python 2 et 3 par exemple). Pour le cas de Kotlin, attention, derrière il y a une société qui s'appelle Jetbrains.

Mickael

[gangsoleil]

Tôt ou tard les langages sont sensés évoluer (Python 2 et 3 par exemple).

J'ai une approche beaucoup plus bas-niveau que la plupart des développeurs, puisque je code principalement en C et en script shell, qui sont des langages extrèmement stables, et qui n'évoluent que très très peu -- trop peu au goût de certains.

Est-ce que les langages devraient évoluer ? Pour moi, c'est encore une autre qusetion. Ici, ma réelle crainte est que l'ensemble de l'écosystème Java ne soit pas prêt, et que donc nous (les développeurs) devions supporter du code qui soit compatible Java 11 (donc sans Corba par exemple) et java 8 (car la JVM du concurrent ne supporte pas encore Java 11). C'est là que ça devient pénible.

[darklinux]

La version actuelle est Java 10 . Effectivement , le manque de CORBA est problématique , mais la norme elle même évolue via EE

[Mickael Baron]

Justement non, ils ont enlevé des choses (corba, applets, java web start, ...), ce qui fait que si tu les utilises, tu es obligé de changer ton code. Et vu le chemin qu'ils prennent, il ne serait pas surprenant que ce genre de surprises arrive sur d'autres LTS dans le futur, donc si, il y a des chances pour que les budgets doivent suivre, que ce soit pour payer les licences ou bien faire le portage.

En tout cas pour les packages java.xml.ws et java.xml.bind que j'utilise pour mes supports de cours, aucune adaptation de code, il a fallu ajouter les dépendances dans le pom.xml. A noter que depuis Java 9 les modules java.se.ee n'étaient pas disponibles par défaut. Soit il fallait utiliser add-module java.se.ee ou ajouter les dépendances. Pour Java 11, il n'y aura pas le choix il faudra ajouter les dépendances.

• java.corba — CORBA
• java.transaction — The subset of the Java Transaction API defined by Java SE to support CORBA Object Transaction Services
• java.activation — JavaBeans Activation Framework
• java.xml.bind — Java Architecture for XML Binding (JAXB)
• java.xml.ws — Java API for XML Web Services (JAX-WS), Web Services Metadata for the Java Platform, and SOAP with Attachments for Java (SAAJ)
• java.xml.ws.annotation — The subset of the JSR-250 Common Annotations defined by Java SE to support web services

Voici les modules qui vont disparaître pour de bons

Pour que les modules soit accessibles, il suffira d'ajouter les dépendances Maven

java.activation

<dependency>
<groupId>com.sun.activation</groupId>
<artifactId>javax.activation</artifactId>
<version>1.2.0</version>
</dependency>

java.transaction

<dependency>
<groupId>javax.transaction</groupId>
<artifactId>javax.transaction-api</artifactId>
<version>1.2</version>
</dependency>

java.xml.bind

<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-core</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.3.0</version>
</dependency>

java.xml.ws

<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-ri</artifactId>
<version>2.3.0</version>
<type>pom</type>
</dependency>

A noter que pour les outils wsgen et wsimport inclut dans le bin du JDK, c'est encore un mystère pour moi.

java.xml.ws.annotation

<dependency>
<groupId>javax.annotation</groupId>
<artifactId>javax.annotation-api</artifactId>
<version>1.3.1</version>
</dependency>

Pour Corba et RMI il n'y aura pas de version standalone, cela sera inclut dans l'implémentation Glassfish.

Mickael

[Mickael_Istria]

Pour Corba et RMI il n'y aura pas de version standalone, cela sera inclut dans l'implémentation Glassfish.

Je prends le pari que s'il y a de la demande commerciale (en gros, des utilisateurs de Corba et RMI pret a mettre de l'argent pour financer ca), des implem standalones de la spec ou le support sur d'autres serveurs d'application peuvent apparaitre assez vite.
Mais c'est aux utilisateurs de financer/developper ca s'il le veulent, parce que technologiquement, ca fait quand meme un moment que ces technos sont depassees sur quasiment tous les criteres et que le mieux pour le domaine serait de leur dire un gros au revoir et merci. Il ne faut pas non plus compter trop sur le benevolat de certains editeurs pour s'appuyer sur ces technos.
Si vous le voulez, je peux vous donner des contacts dans une boite extremement competente en terme de middleware Java qui pourrait peut etre le faire contre un beau contrat de support

[Grogro]

Il existe vraiment encore des projets qui utilisent Corba et RMI ?

[Mickael Baron]

Il existe vraiment encore des projets qui utilisent Corba et RMI ?

Oui je pense, comme il existe encore des projets en Cobol

Mickael

[gangsoleil]

Il existe vraiment encore des projets qui utilisent Corba et RMI ?

On parle ici de projets de centaines de milliers de lignes de codes, qui sont déployés chez des centaines de clients, et dont le développement a débuté il y a à peine moins de 20 ans. Donc oui.

Et non, il n'est pas question de ré-écrire tout, sauf cas de force majeur, pour deux raisons : le coût, et les risques de régressions. Ils seront ré-écrits un jour, c'est certain, et c'est d'ailleurs pour ça que je me posais la question du changement de langage ou non.

[Mickael Baron]

Pour revenir au choix de changer de langage, je me pose souvent les questions suivantes pour comprendre

- Est-ce du au faite que Java est un vieux langage dont les développeurs débutants des débuts ont maintenant la quarantaine (j'en fais parti) et par conséquent il ne fait plus rêver ?
- Est-ce du au faite que comme il y a beaucoup de développeurs Java, les marges pour les sociétés de services sont réduites ?
- Est-ce du au faite que ça appartient à Oracle ?

Mickael

[Mickael_Istria]

- Est-ce du au faite que Java est un vieux langage dont les développeurs débutants des débuts ont maintenant la quarantaine (j'en fais parti) et par conséquent il ne fait plus rêver ?

Il y a une part de ca: les jeunes veulent prendre la place des vieux et pour ce faire, ils construisent un ecosysteme ou ils auront le controle (comme nous autres vieux l'avont sur Java en ce moment). Ce qui est dommage, c'est que les resultats sont similaires au final, donc on n'est pas vraiment dans l'innovation et -encore pire- avant d'en arriver au meme niveau, on est limite en regression. Ca a a mon avis ete le cas avec JS pendant un moment, avant que la gestion de dependances devienne plus propre, que les linters arrivent, avec que le JSon ait un schema et donc un outillage de qualite et compagnie...

Apres, il y a aussi du bien dans le changement. Par exemple, TypeScript est quand meme un beau langage, plus beau que Java (mais moins beau que d'autres langages qui existaient avant genre Ceylon ou OCaml...)

- Est-ce du au faite que comme il y a beaucoup de développeurs Java, les marges pour les sociétés de services sont réduites ?

J'ai deja entendu cet argument il y a quelques annees "un dev Java coute 80000 la ou un dev JS coute 45000". Si on ne voit pas plus loin, c'est peut-etre vrai. Mais le vrai truc c'est que le dev Java moyen a en general ~10 ans d'experience la ou le dev JS en avait 3 ou 4 (a l'epoque). Donc cet argument financier ne tient pas debout a mon avis. D'ailleurs, je pense qu'un dev JS avec ~10 ans d'experience coute maitenant plus cher qu'un dev Java avec ~10 ans d'experience, puisque ces derniers sont moins rares.

Est-ce du au faite que ça appartient à Oracle ?

Je pense pas que ca change grand chose.

[Rhona Maxwel]

Oracle s'est débarrassé de Java en le confiant à l'organisation open source Éclipse.
Les corporates utilisent Java dans leurs applications les plus stratégiques.
Java couvre tous les domaines user interface, mobile Android, web, mais aussi batch, web services, serveurs d'application, ...
Je vois mal le DSI d'une grande banque décider de laisser tomber Java.
Java est le COBOL (qui n'est pas mort, il y a encore de nombreuses chaînes qui continuent de tourner) du 21 ème siècle.

[Mickael_Istria]

Oracle s'est débarrassé de Java en le confiant à l'organisation open source Éclipse.

C'est pas vraiment ca. C'est Java *EE* (certaines specs de libraires, pas le langage) qui a ete contribue en open-sourche chez Eclipse. La spec du langage et la marque "Java" restent propriete d'Oracle, qui la gere avec le traditionnel JCP qui est un processus assez ouvert.
Bien que le code bouge chez Eclipse, Oracle est encore de loin le principal contributeur a la plupart de ces specification Java EE (bientot renomme Jakarta EE) et gere tres serieusement, et en investissant des efforts, la contribution vers l'open-source. Ca ne ressemble pas vraiment a une strategie pour "se debarasser", mais plutot a une prise de conscience que pour que la techno reste pertinente et rentable, il faut qu'elle soit plus ouverte.