Et maintenir son code toujours dans la nouvelle version de Java, cela n'est pas envisageable ? Cette solution me semble toujours moins coûteuse qu'une migration vers un autre langage, même sur le long terme.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Et maintenir son code toujours dans la nouvelle version de Java, cela n'est pas envisageable ? Cette solution me semble toujours moins coûteuse qu'une migration vers un autre langage, même sur le long terme.
Je ne connais pas assez python, mais s'il manque tout ce genre de choses, ce n'est pas une option.Envoyé par gallima
Lorsque la migration envisagée se compte en mois de développement à plusieurs, je trouve qu'il est intéressant de se poser la question de ré-écrire. Je travaille sur un projet qui a plus de 15 ans, il n'est pas déconnant du tout de se poser la question de la ré-écriture, car le gain en maintenance ne sera pas négligeable -- mais le coût de ré-écriture est bien sûr très élevé aussi.Ré-écrire l'existant c'est bien un truc de personnes qui ont du temps à perdre ou qui ne travail que sur des projets jetables.
Rejeter cette question, c'est justement ce que je reproche aux gens avec qui je travaille. On va continuer à utiliser Java 11 comme on utilisait Java 6, "car c'est comme ça dans le code et qu'on n'a pas le temps de changer". Est-ce que ça a l'air mieux ?
Non, mais les autres implémentation soit-disant compatibles posent des problèmes récurrents (je le sais, nous supportons le JDK d'IBM pour AIX, et nous devons faire des adaptations régulières).Ensuite il faut arrêter d'exagérer, Java à garder la compatibilité ascendante pendant plus de 20 ans.
Là on parle de modifications indispensables du langage qui n'imposent pas de modification du code mais uniquement de la chaîne de build.
On parle de modifications radicales qui ne vont pas se produire tous les 6 mois.
Dans le pire des cas Oracle n'a pas le monopole de l’implémentation.
Quant aux modifications non-radicales qui ne vont pas se produire souvent, je ne suis pas forcément d'accord, mais j'ai une vision pessimiste de la chose.
Concernant le typage, Python supporte de plus en plus un typage statique optionnel :
- Python 3.0 : on peut utiliser des annotations de type sur les paramètres de fonction.
- Python 3.5 : le module typing apparaît dans la bibliothèque standard. Il permet, entre autres, de faire du polymorphisme paramétré.
- Python 3.6 : on peut utiliser des annotations de type sur des variables locales.
- Python 3.7 : petite correction d'une limitation des annotations de type.
Pour vérifier les types lors de l'analyse statique du code, il faut utiliser un outil comme mypy.
Gangsoleil
Suite à ton poste sur tes besoins, je vois 2 options:
1) Tu peux conserver Java si tu decides de passer à OpenJDK. Si ton application utilise des composantes JEE, je ne vois aucun problème, JEE est passé dans le côté Open-Source. Inconvenient: quid du support? Mais cela représente la solution à moindre frais
2) Plus couteux, tu passes à .NET mais cela revient à planifier la migration et à tout revalider. Avantage: tu (re)pars sur des bases nouvelles mais je conviens que migrer n'est pas la solution d'aisance.
De mon point de vue, tu peux rester sur Java avec OpenJDK, ma question reste le support.
@++
GLDavid
Consultez la FAQ Perl ainsi que mes cours de Perl.
N'oubliez pas les balises code :tagcode: ni le tag :resolu:
Je ne répond à aucune question technique par MP.
Je suis dans la même interrogation... J'ai pas compris qu'est-ce qui va devenir payant ?
L’accès à l'API ? ça veut dire quoi ? je vais devoir payer pour obtenir ma JRE ?
L'accès au support ? C'est quoi le support dans le cas de Java ?
Les deux ?
Ce qui va devenir payant, ça va être le support et les mises à jour des qu'une nouvelle version sort.
Tu utilise java 10 alors que Java 11 est sortie.
Un bug est trouvé dans java 10, si tu veux le fix, il faut que tu ai payé le support.
Pour les API, c'est que certaine API n'existe plus entre 2 versions.
Donc tu as 2 solutions, passer en version supérieur et ré-ecrire ou garder ta version mais payer le support pour les fix sécurité.
OWL2+python
effectivement on trouve pas je connais même pas ce que c'est cette chose mais ça se trouve.
On dois pas travailler dans le même domaine parce que moi c'est l’opposé les gens sont réjouis de découvrir python.J'ai plus souvent vu des gens quitter python qu'y venir en remplacement de quelque chose.
autant javascript oui mais rust, j’apprends quelque chose ,et pour js cet article de 2014 est toujours accuratePuis s'il faut vraiment migrer des outsider comme Javascript et Rust sont bien plus à la mode que Python.
eum eum eum que dire rest // messaging // swagger, faut m'expliquer ce que ces trois outils ont comme principe commun Oo l'une est fait pour faire un api que tu call via HTTP , la deuxième est un middleware selon sa page wikipedia et le troisieme crée des interfaces rest (et ça fonctionne en python je tiens a le rappeler), tu m’étonne que ça se trouve pas en python une lib qui fasse les TROIS EN MÊME TEMPS par contre pour une lib qui fait proprement chacune de ces chose tu vas trouver. et puis je sais pas a quel moment quelqu'un c'est dis que c'étais intelligent de mélanger trois truc qui font des choses totalement différentes enfin bref je retourne a mon code pythonune autre lib qui supporte tout les formats de communication (wsdl, rest, wadl, swagger, messaging, etc... )
Ce n'est pas l'API, mais les correctifs sur JRE/JDK 8 qui deviennent payant. Ceci inclus les corrections de bug et les fix de sécurité.
Je suis dans la même interrogation... J'ai pas compris qu'est-ce qui va devenir payant ?
L’accès à l'API ? ça veut dire quoi ? je vais devoir payer pour obtenir ma JRE ?
L'accès au support ? C'est quoi le support dans le cas de Java ?
Les deux ?
Pour un projet d'école, tout le monde s'en fout, avec raison. Pour un projet pro, les clients doivent avoir une JRE à jour pour éviter tout problème. Donc soit tu payes le support, soit tu fais payer le support à ton client, soit tu passes à java 11.
Si je comprends bien, l'idée derrière ça c'est un peu de mettre une amende à ceux qui reste sur des vielles versions mais qui veulent quand même les correctifs.
Ainsi Oracle souhaite forcer l'utilisation de la dernière version et avoir moins besoin de maintenir les vieilles
Justement, evite de dire n'importe quoi si t'es pas au courant des parties legales...
Java reste ouvert et bien ouvert, les implems comme OpenJDK sont du vrai OSS sans contreparties. La licence c'est GPLv2+CE. Seuls le JDK d'Oracle et d'autres JDK specifiques sont commerciaux et sous contraintes d'utilisation; mais c'est bien explique et quoi qu'il en soit, il y a toujours moyen d'utiliser OpenJDK sans probleme. Donc, non Java c'est pas un cancer, et c'est en fait plus ouvert que ca ne l'a jamais ete.
Du coup, la discussion a tourne au grand n'importe quoi. Beaucoup semblent faire l'amalgamme entre Java et Oracle JDK. C'est completement erronne. Java c'est une spec qui est OSS regie par le JCP qui emet des JSR; et tout ca est ouvert et implique de multiples vendeurs. Apres, les implems de Java sont nombreuses (Oracle JDK, OpenJDK -1/2 Oracle + 1/2 IBM en gros-, Zulu...), et vous etes libres de choisir celle que vous voulez. OpenJDK est open-source et n'est en rien affecte par les decisions d'Oracle a propos d'OracleJDK.
Les majors LTS d'Oracle JDK. Mais comme d'autres boites (genre Red Hat) offrent aussi un support LTS sur OpenJDK, qui lui est open-source, ca va en fait amener des bugfixes dans les vieilles sources d'OpenJDK aussi
Tout a fait, et c'est pour ca que c'est de bonne guere que des boites essayent de monetiser ces demandes un peu chiantes des utilisateursPas de souci donc, ça ne paraît pas si bloquant que ça, faut pas se leurrer, ça embête tout le monde de maintenir des versions 'legacy'.
Kotlin tourne essentiellement par dessus Java; donc si il y a un bug de secu dans les couches basses de Java, il sera aussi surement dans les applis faites en Kotlin.Sinon il y a kotlin
Une tempête dans un verre d'eau au final
Entre ceci :
Et ceci :
Je crois que tout est dit.
Donc aucune raison de s'exciter, les alternative à l'implémentation d'Oracle sont là et le sont depuis bien longtemps et vont perdurer bien au delà d'Oracle.
Donc smile and enjoy OpenJDK
Juste pour savoir, vous avez quelle portion de vos clients qui gèrent eux-même leur JDK/JRE qui utilisent OpenJDK et pas celui d'Oracle ? Que ce soit dans mon ancienne entreprise ou bien dans mon entreprise actuelle, il n'y en a aucun. Les seuls à ne pas utiliser le JRE Oracle sont ceux qui ont une architecture matérielle incompatible (à savoir des processeurs IBM powerPC, et dans ce cas ils utilisent le JRE d'IBM, ce qui pose des problèmes).aucune raison de s'exciter, les alternative à l'implémentation d'Oracle sont là et le sont depuis bien longtemps et vont perdurer bien au delà d'Oracle.
Donc smile and enjoy OpenJDK
Donc je pense que non, le passage vers OpenJDK ne va pas se faire non plus dans la minute.
@gangsoleil
Si je comprend bien c'est ton entreprise qui fournit la JRE au sein du produit à tes clients. Tu es donc maître pour mettre la JRE que tu veux, non ?
Moi dans mon entreprise c'est le cas.
Alors ou je travaillais avant toutes nos applis (dont la plus grosse 2,3 millions de ligne de code) étaient développé avec les JDK Oracle par les dev et étaient déployés dans des serveurs WebSphere et tournaient sur le JDK d'IBM -> aucun soucis!
Le plus gros problème était les évolutions du JDK IBM qui ne suivaient pas forcément les release officielles, Si je ne m'abuse le JDK 6 d'IBM n'est jamais sortis.
Donc forcément tous nos clients utilisaient le JDK d'IBM...
En théorie une implémentation de JDK (validée par le Technology Compatibility Kit (TCK) ) se remplace par une autre. Et ça se vérifie plutôt pas mal (même qu'il peut y avoir parfois quelques petites subtilités/fourberies cachées...)
Pas forcément, c'est bien le soucis
Certains clients utilisent le JRE qu'on fournit, d'autres pas -- notamment ceux qui utilisent des serveurs d'application type WebLogic.
D'ailleurs, si j'ai bien suivi, WebLogic va rester en JRE 8, donc ça veut dire que notre code devra être Java11, tout en ayant un bytecode Java 8.... Encore de la joie en perspective.
Après, je ne dis pas que l'idée de ré-écrire est meilleure, simplement je pense qu'il faut l'envisager. Changer le JRE en est une autre que je n'avais pas envisagé, mais qui est à mon avis une solution temporaire, car il est probable (mais pas certain) que les changements apportés par Java11 soient demandés/nécessaires à partir d'un moment.
Le simple fait que l'annonce d'Oracle (dont la réputation n'est plus à faire) suscite autant de questionnement prouve que ce qui est payant ou non n'est pas clairement défini.
Personnellement, je retiens une seule chose: Peu importe ce qui est ou n'est pas payant aujourd'hui... Ce n'est qu'une affaire de temps. Tôt ou tard avec Oracle, tout deviendra payant!
Alors, il est, me semble-t-il, inutile de vouloir se faire une formation accélérée de "juriste émérite"... Autant utiliser son temps de développeur à trouver une alternative à Java pour le futur!
Je comprends pas du tout. Si ta cible est Java 8, tu codes en Java 8 et c'est tout. Les IDE et les outils de build te permettent de coder en Java 8 meme en utilisant un JRE/JDK 11. Donc sur le coup, ca ne change rien je pense.donc ça veut dire que notre code devra être Java11, tout en ayant un bytecode Java 8....
Demandes par qui? Et au final, en quoi ca serait un signe qu'il faut changer de langage? C'est la meme chose pour PHP, Python... Il y a des releases souvent, qui sont plus ou moins interessantes, et parfois, tu migres a la version plus recente et dans la grande majorite des cas, ca va a peu pres tout seul. Je vois pas ce que tu eviterais avec un autre langage dans ce cas.car il est probable (mais pas certain) que les changements apportés par Java11 soient demandés/nécessaires à partir d'un moment.
Non!! .NET Core n'est pas cross-platform. Arrêtez avec cet argument marketing !
Cross-platform Windows OK, mais Linux 64bit uniquement et Mac OS avec l'avant dernière version minimum.
Demandez à un dev Java si il considère ça comme cross-platform...
L'équipe d'Unity 3D pense la même chose c'est pour cela qu'il préfère rester sur Mono.
Et même l'équipe de Microsoft qui s'occupe du .NET Core considère que leur version Mac OS est réservée aux développeurs.
Et on va pas se mentir (entre dev C#
Même Electron avec Javascript supporte plus de plateforme que .NET Core
A croire que tu n'a pas suivi la sortie du .NET Core 2.1 et son fameux "Windows Compatibility Pack"
Revenez au bon vieux C, un monde dans lequel personne ne cherchera à vous en*@!###.
Ah non ! C'est vrai, vous ne pourriez plus.
Répondre avec citation
Partager