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
Il peut tout faire dans l'univers de l'informatique
Il est facile à étudier
Il jouit d'une grosse adoption en entreprise
Il dispose d'une grosse comunauté
Le langage est gratuit
C'est le cobol du 21e siècle
La JVM lui confère le statut de plateforme d'exécution
Il n'envie rien à C et C++ pour ce qui est de la rapidité
Il évolue rapidement
Il dispose d'une API standard riche
Autres (à préciser)
Discussion :
Niveau consomation cpu et mémoire :
https://benchmarksgame-team.pages.de.../gpp-java.html
C++ > Java
https://benchmarksgame-team.pages.de...st/python.html
Java > Python
Il arrive que C++ mette un ordre de grandeur à java, mais le cas général c'est un facteur 3, ce qui est 'souvent' acceptable pour faire des comparaisons au cas par cas.
Par contre python se prend souvent un ordre de grandeur par java, à la louche le cas général est un facteur 50; là on change définitivement de type d'usage.
@wallas00 +1.
Juste la partie :
Pour le coup, si la programmation de microcontrôleur / IoT ce n'est pas bas niveau, qu'est ce qu'il vous faut ?1. Le ou les domaines dans lesquels vous souhaitez exercer
- programmation de microcontrôleurs ou d'objets connectés: OUI pourquoi pas? Personnellement, c'est dans le cadre de ce genre de projets que j'ai le plus apprécié le JAVA, et cela malgré le fait qu'il ne facilitait par forcément la programmation asynchrone.
- programmation bas niveau: NON.
@wallas00
Personnellement sur ce segments, j'utiliserais plutôt le C, C++, Pascal, voir du Rust si la cible est disponible.
---
La plateforme Flutter est très bien pour faire de l'UI multi-plateformes, mais tous ce qui sera basé sur Dart ne pourra pas approcher les perf du C, C++, Rust, Go, ..etc.Attention Flutter arrive en Cross-platform, et si Dart en natif peut approcher les performances du C, C++ cela va offrir un concurrent sérieux.
@archqt
Le langage et de beaucoup plus haut niveau que Java, donc ça vous donne une idée.
Par contre depuis que Google a inclut une FFI à la dartvm, effectivement, ça risque de faire mal à JNI/Python CFFI/Node N-API et autres qui sont qu'en même bien plus complexe (luajit ffi mène toujours la danse cependant).
Alors, "mon cerveau" fait la distinction entre les prérequis en terme de programmation pour l'IoT et tout ce qui est système/bas niveau.Envoyé par defZero
@wallas00 +1.
Juste la partie :
Pour le coup, si la programmation de microcontrôleur / IoT ce n'est pas bas niveau, qu'est ce qu'il vous faut ?
Personnellement sur ce segments, j'utiliserais plutôt le C, C++, Pascal, voir du Rust si la cible est disponible.
---
La plateforme Flutter est très bien pour faire de l'UI multi-plateformes, mais tous ce qui sera basé sur Dart ne pourra pas approcher les perf du C, C++, Rust, Go, ..etc.
Le langage et de beaucoup plus haut niveau que Java, donc ça vous donne une idée.
Par contre depuis que Google a inclut une FFI à la dartvm, effectivement, ça risque de faire mal à JNI/Python CFFI/Node N-API et autres qui sont qu'en même bien plus complexe (luajit ffi mène toujours la danse cependant).
Durant les projets IoT auxquels j'ai participé, nous ne programmions pas exactement le firmware du matériel, mais plutôt l'application qui gère ses interactions avec le système dans lequel il va s'intégrer. Cela est faisable avec du C/C++ | JAVA | Python | JS.
Cependant, je comprends que dans certains projets, les activités de programmation systèmes sont intriquées avec la création de l'application qui gère les user cases.
Pour les amoureux de la performance, je me permet de rappeler que les applications sous Electron ne bénéficient pas encore des optimisations qu'apporteront l'utilisation du wasm.
Walmart a passé tout son back sous NodeJS.
Profiter des API de GGS/Firestore avec JS/TS est simplement cheaté en terme de time to market.
Pareil avec .NET et AZURE.
Le SDK AWS JAVA doit probablement être très bien, mais celui pour python est juste trop confortable à utiliser(on va pas ce le cacher).
L'industrie poursuivra les migrations de ses applications Java 7 -> 8 -> 11 -> 13 (+ migration des serveurs applicatifs.); cependant je ne vois pas pourquoi les nouveaux projets partiront sur ces technos quand tu as les écosystème de Go, JS/TS, .NET.
J'ai regardé , mais je ne suis toujours pas convaincu que cela suffira.
L'écosystème JAVA est selon moi sur une courbe qui le fera prendre un statut similaire(cousin) à celui de l'écosystème PHP actuellement, c'est-à-dire: solide communauté, produit ayant fait ses preuves quoique les détracteurs disent, une grande partie des apps business tournent dessus, mais de plus en plus niché.
il semble qu'il y est encore du java
Go, une blague j'espère?
les entreprises partent en autre sur du java étant l'ampleur de son écosystème encore inégalé sur les autres plateforme, quantité de ressource disponible, formation et documentation aisément accessible
une présentation de Java EE 8... ça date...
le marché a bougé sur spring depuis un moment, il reste encore des banques et assurance qui aiment bien ce qui est lourd
l'écosystème est plus que différent entre ces deux système, pas vraiment le même type d'application qui sont développé
Java peut faire beaucoup dans tous les domaines
Il est clair que Java ressemble beaucoup à C, C++ et c#
Certes, sa position au sens des applications web diminue au profit de PHP. Côté interfaces graphiques (par exemple Swing) il est vrai que cela est intéressant mais un peu "lourd" à réaliser. Quoique des applications telles que ProrealTime (logiciel de bourse en Java) soient rapides et performants.
Il n'en demeure pas moins que Java utilisé côté serveur dispose de forts avantages étant donné la richesse des fonctions dont il dispose.
Cf le message de jpouly ci-dessus dans cette discussion.
Me concernant, le plus intéressant me semble être la possibilité de traiter les données et de faire des interfaces "légères" avec d'autres langages côté client.
Java peut faire des choses bien plus complexes que des procédures stockées etc. Les mêmes résultats de Java sont utilisables dans divers langages client, que ce soit Delphi, C++ ou Flex (dit maintenant Flashbuilder). Cela offre une très grande liberté pour ce qui est de changer le langage de l'interface "client léger" tout en gardant le même fonctionnement côté serveur avec la vitesse des liaisons permettant de ne pas avoir à mettre en place des systèmes de réplication dans des bases de données distribuées sur les clients.
Voilà donc la raison pour laquelle j'apprécie de plus en plus Java appris sur le tard, j'en conviens..
Vadim
Java, Cobol du XXIème siècle?
Pour avoir bossé en centre informatique d'une l'administration centrale française, je peux vous dire que le COBOL est très bien adapté à ce qu'on lui fait faire: de la gestion en batch sur gros volume. Pour les formulaires, il vaut mieux passer par des langages plus modernes, mais il le fait aussi. Pas de possibilité de gestion de réseau ou autre chose de ce genre. Programmation impérative seulement, mais il est le plus efficace dans son domaine (il est compilé comme le C/C++ et n'a pas de limite de taille pour les nombres).
Quand on est passé au java, ça nous a piqué les yeux. Le changement de tous les programmes se fit sur une décennie. Le gain fût en polyvalence et en maintenabilité: La définition d'une bibliothèque d'objets réutilisables permettait de gros gains en développement, une javadoc commune permettait de ne pas devoir lire des dizaines de gros fichiers COBOL commentés pour comprendre ce que fesaient les programmes. Quelque chose d'approchant existait déjà en COBOL, mais cela relevait du bidouillage et de la gestion de projet, pas de la structure et des outils du langage.
D'un autre côté, on a perdu en maîtrise parce qu'on a dû incorporer des logiciels tiers dont certains ont révélé avoir des bugs ou des faiblesses à l'usage, mais on est passé du minitel à internet. Et côté gestion de projet, c'est devenu l'enfer avec des fichiers de configuration à n'en plus finir, à modifier à chaque changement d'une bibliothèque tierce, et les outils comme Struts, ant ou maven sont devenus affaires de spécialistes.
Puis est venue la mode du PHP, et certains ont voulu développer l'emploi de ce langage. Pour des petits projets et de petites équipes, ça marche; mais les gros projets sont restés en java. Et cela va rester longtemps comme cela:
1) parce que les administrations ont un volume très importants de programmes à maintenir, leurs évolutions se faisant au rythme des évolutions législatives et réglementaires (lois, normes internationales, etc)
2) parce qu'il n'y a aucun langage qui permette de faire de tout plutôt bien comme le fait java et qui soit aussi largement utilisé, et parce que ça n'apporterait qu'un gain marginal compensé par le coût d'apprentissage ou de maintenance (nouveau langage et nouvel environnement = chaîne de développement et de maintenance différente)
3) parce qu'il est libre de droit, bien documenté, gratuit et largement répandu.
Malheureusement JAVA est loin d'être à la hauteur pour le développement d'interfaces graphiques. Par exemple, il est loin derrière Angular ou autres langages.
Du coup, on est obligé de connaitre plusieurs langages de programmation pour pouvoir réaliser une application complète.
A+
Si par IHM tu entends web app, au final en front tu feras toujours plus ou moins du HTML/CSS, peu importe le langage backMalheureusement JAVA est loin d'être à la hauteur pour le développement d'interfaces graphiques. Par exemple, il est loin derrière Angular ou autres langages.
Du coup, on est obligé de connaitre plusieurs langages de programmation pour pouvoir réaliser une application complète.
A+
Et c'est une bonne chose (backend, frontend, services, et...)
D'un point de vue intellectuel => Zéro pointé
je cite "Il n'envie rien à C et C++ pour ce qui est de la rapidité" mais bien sur...
Il y a tout dans le coffre de la R16 : des housses de cathédrale, des peignes à girafe, des machines à casser les œufs, et des perceuses à trous carré.
Mise à par les OS et autres pilotes matériels, quelle langage ne sait pas tout faire ?
Peut être SQL et XML. Sinon je ne vois pas.
Oui en théorie. Parce que pour une personne qui n'a jamais fait d'objet.
Pour le reste, c'est comme le c#, c'est un ersatz du C++.
Vrai. Avec le triptyque : Oracle / Java, SQL Server / VB.net & MySQL / PHP
Beaucoup d'entreprises sont passés à java dans les années 2000/2010.
Maintenant ce serait plutôt le .net, qui est jugé mature par les décideurs.
C'est assez vrai.
C'est peut être l'un de ses rare avantages. En attendant qu'Oracle n'y mette le holà
Parce qu'il faut qu'en même que Larry change la cuvette des chiottes de son bateau de course
Cobol, c'est le langage qui a le plus de lignes de codes encore actives au monde. ça vous crache des factures pour des millions de clients sans tousser.
C'est vieux (année 60), mais c'est simple, robuste et efficace. Je doute que Java soit dans ce cas.
Tout pareil que Miguel. Et le C est cool, car il utilise les instructions du processeur, un peu comme l'assembleur
Si d'autres langages utilisent le JVM pour s'exécuter, et bien tant mieux. Mais quand je vois du code Kotlin, je ne vois pas beaucoup de Java.
ah, le fameux temps de chauffe des applications web. tout un poème. Le temps de prendre un café
Je ne suis pas sure que pour un langage, les évolutions soient indispensables, quand on a atteint une certaine maturité.
Et je prend pour exemple le C# et le C++.
Et c'est un sacré bordel. On passe plus de temps à choisir les composants qu'a développer
Je n'ai jamais compris pourquoi tout le monde reprend ce prétendu lien entre C/C++ et C#... parce que ça commence par "C" ? Les accolades comme 90% des langages ?
Pour ceux qui ont fait du Delphi, C# en est philosophiquement plus proche que du C++... peut-être parce que Anders Hejlsberg a été débauché de chez Borland par Microsoft pour mettre au point C# ?
Parce que le C# permet de coder en C++ ... cela s'appelle du C++ managé ("managed" en anglais) parce que la mémoire passe par la CLI et tu n'as plus vraiment de notion de pointeur (avec une syntaxe ^)
Ensuite je ne sais pas quelle norme du C++ est prise en compte C++03 ? C++11 ? C++14 ? ou plus récente ... et tous les autres chausse-trapes autre que la gestion de la mémoire.
C'est comme l'Objective C (Objective C++) qui permet de mixer avec du code C (C++)
Avec ton Delphi ce n'est pas possible... tu es obligé de passer par du code compilé (fichier .dcu) pour faire le lien C/ C++ <-> Delphi
Ça a clairement des similitudes avec le C++ au niveau de la syntaxe de surface, mais le terme d'ersatz ne me parait absolument pas adapté. Java a fait des choix qui simplifient considérablement le langage.Oui en théorie. Parce que pour une personne qui n'a jamais fait d'objet
Pour le reste, c'est comme le c#, c'est un ersatz du C++.
Très mauvais exemples : le C# et le C++ sont des langages qui évoluent beaucoup, au moins autant que Java. Si tu veux des exemples de langages qui évoluent peu, tu peux citer le C ou le Cobol.
Au contraire, l'avantage d'une bibliothèque fournie, c'est qu'on passe globalement moins de temps a chercher ses composants. L'inconvénient c'est que les composants de la bibliothèque standard ne sont pas forcément les plus adaptés à toutes les situations.Et c'est un sacré bordel. On passe plus de temps à choisir les composants qu'a développer
Tu mélanges C# et .net. Le premier est un langage, donc par définition il ne permet pas de coder en C++. le .net est un framework basé sur un environnement d’exécution managé qui peux gérer plusieurs langages dont C++ et C#.
Ensuite je ne sais pas quelle norme du C++ est prise en compte C++03 ? C++11 ? C++14 ? ou plus récente ... et tous les autres chausse-trapes autre que la gestion de la mémoire.
C'était plutôt des contres-exemples.
Les dernières évolutions du c# ou du C++, de mon point de vue, dénature ces langages (ex : reference tyoe non nullable pour le C#, la gestion "automatique" de la mémoire en C++).
C'est le commentaire de celui qui ne connait pas les arcanes du C++
Mais en réalité quasiment tous les ajouts du C++ moderne sont là pour lever toutes les impossibilités de la méta-programmation (avec les templates) et de la simplifier.
Lorsque tu vois des exemples en C++14 avec des lignes de 15 kilomètres (des templates dans des templates) réduit à presque rien en C++17 cela interpelle.
Et toutes les autres ajouts sont :
- soit là pour désambiguïser la norme C++03 et cela en devient lourd - par exemple maintenant on doit savoir si notre variable est copiable ou pas, déplaçable ou pas, ...
- soit des échecs - la gestion de la fermeture dans les lambdas, la bibliothèque threads, list initialization, ...
Mais on attend toujours "les vrais trucs" : les modules, les concepts, un vrai remplaçant aux macros, la reflection, ...
Et je dois être stupide mais leur Unicode ne me semble pas terrible: encore de nouveaux types qui ne font rien et une palanqué de fonctions de conversions.
c'est curieux ...
j'ai l'impression qu'en remplaçant le mot JAVA par n'importe quel autre langage ( ou presque) le texte reste cohérent !
je me trompe ?
Flutter me semble avoir de bons atouts
Je pratique Java depuis plus de 15 ans
Je l'utilise encore pour le backend
Mais flutter avec dart me semble être une bonne solution pour l'avenir.
Je suis en train de créer plusieurs applications pour en tester les + et les moins après avoir testé Typescript et Angular.
Je suis d'une vielle génération de développeur (j'ai commencé à développer en hexadécimal et en basic)
L'assembleur a été un vrai soulagement
Mais toujours intéressé par ce qui peut apporter de nouvelles solutions c'est comme celà que je suis arrivé au java après avoir fait du pascal et du Delphi.
Et pour le c/c++ essayez donc de faire une caméra web + reconnaissance faciale + serveur web + access point wifi pour 8 € caméra incluse avec autre chose. Comme ici par exemple https://robotzero.one/esp32-camera-module/Je pratique Java depuis plus de 15 ans
Je l'utilise encore pour le backend
Mais flutter avec dart me semble être une bonne solution pour l'avenir.
Je suis en train de créer plusieurs applications pour en tester les + et les moins après avoir testé Typescript et Angular.
Je suis d'une vielle génération de développeur (j'ai commencé à développer en hexadécimal et en basic)
L'assembleur a été un vrai soulagement
Mais toujours intéressé par ce qui peut apporter de nouvelles solutions c'est comme celà que je suis arrivé au java après avoir fait du pascal et du Delphi.
Globalement d'accord avec l'article. Juste deux choses :
- API du JDK intuitive ? Heu, faut pas déconner là, un des défauts majeurs de Java est qu'il est très académique et assez bas niveau finalement. Quand on fait du java, on utilise généralement quelques tonnes de librairies/frameworks tiers pour en faciliter l'utilisation et permettre une bonne productivité des développements (apache commons and co). Perso, je suis un vieux de la vieille, je connais bien les API de base, et je ne fais que peu de développement, donc ça ne me gêne pas outre mesure, mais allez justifier aux jeunots qu'il faut instancier 3 classes, implémenter deux interfaces, et faire de la composition pour réaliser une simple opération qui se fait en un appel de méthode (statique tant qu'à faire) dans la plupart des langages.
- paradigme objet facile ? Heu... comment dire. Le paradigme de base est certes enfantin, mais une bonne appréhension de l'objet afin de produire des applications qui ne soient pas des usines à gaz sur-conçues, qui soient évolutives, performantes et maintenable, demande des années d'expérience. La POO requiert beaucoup d'expérience pour être mise en oeuvre efficacement dans des contextes réels (tiens au hasard, quand on utilise une base de données relationnelle, et arrêtez de penser que les ORM sont une solution magique...)
Je n'ai jamais vu l'indice TIOBE utilisé en entreprise
C'est n'importe quoi. Le seul endroit où l'on parle de cet indice, c'est sur developpez.com. Je n'ai personnellement jamais vu qu'il soit utilisé en entreprise (ou public).l'indice TIOBE est fréquemment utilisé comme référence
Répondre avec citation
Partager