Discussion :

[ptah35]

A mon avis quand un compilateur java produira du code x86-arm-etc- ce langage deviendra acceptable plutôt que du pseudo code qui demande une double interprétation lors de son execution.

Personne ne vous interdit de le faire, si vous voulez traduire (compiler) du Java dans un autre langage (C, MSIL, jeux d'instruction x86, etc.) c'est tout à fait possible. Le bytecode de Java n'est rien d'autre que le jeux d'instructions de la machine virtuelle.

La plus part des compilateurs pour le langage Eiffel par exemple, utilisent le C comme langage intermédiaire, puis un compilateur C pour la compilation dans un langage machine.

La question à se poser est : pourquoi voudrait-on le faire? Les performances des JVM sont aujourd'hui tout à fait adéquates et il faudrait compiler le Framework autant de fois qu'il y a d'architectures matérielles (avant de tester ce même Framework sur chaque architecture alors qu'avec une machine virtuelle, si la machine virtuelle fonctionne alors le Framework fonctionne). Pour écrire des programmes "natifs", de C à Haskell en passant par C++ et Eiffel, il y a déjà suffisamment de langages.

[Colmea]

Ca reste un des languages les plus enseigné dès la première année, donc on a encore au moins 5 ans avant un possible déclin

Sinon HS, mais
Pill_S > On peut créer des classes abstraites et implmenter des interfaces en PHP, où est le problème ?
(c'est une vraie question, pas une remarque )

[e-ric]

Ca reste un des languages les plus enseigné dès la première année, donc on a encore au moins 5 ans avant un possible déclin

Sinon HS, mais
Pill_S > On peut créer des classes abstraites et implmenter des interfaces en PHP, où est le problème ?
(c'est une vraie question, pas une remarque )

Java est largement enseigné par facilité et parce que pour l'instant c'est pas cher. D'un autre côté, pour les industriels, ça fera baisser le prix des développeurs du fait du nombre disponibles et de l'effet de concurrence. On aura le même problème sur .Net.
Ce que je reproche dans l'enseignement actuel, c'est une forme de mono-culture que je trouve contre-productive. Avant, on touchait à un panel assez large de langages : Pascal, C, C++, Assembleur, SQL, Prolog, Lisp, Ada (on ne parlait pas beaucoup d'Internet, Java n'était pas né). Même si on avait peu de chances de travailler sur tous ces langages.
J'ai déjà rencontré un développeur Java, prétendu compétent et cher, qui pensait que les expressions régulières étaient propres à Java, c'est pathétique et une bonne occasion de rigolade... Il ne connaissait au final rien d'autre que Java. (je ne généralise pas mais j'en ai vu de drôles par moment)

[Francisco22]

Je suis avec... java est en constante développement, depuis qu'il a vu le jours, il ne cesse d'évoluer

[devEric69]

Je pense que Java n'est pas mort dès qu'il faut envisager une solution multi-plateformes. Par contre, dans le monde du web, il est certain que des solutions plus légères et graphiquement plus poussées l'ont remplacé. Cependant, il est possible qu'avec l'arrivée des objets communicants, il ait une place de choix à reprendre.

>Et encore le PL/SQL d'Oracle c'est pas ce qu'il y a de plus performant...

C'est surtout pas ce qu'il y a de plus facile à déboguer. Là, au lieu d'écrire une grande procédure stockée en SQL, tu peux privilégier la sémantique en utilisant une procédure stockée en Java donc utiliser des objets, réutilisable et déboguable sous Windows ou sous Linux, selon l'endroit où Oracle est été installé.

[Gugelhupf]

Merci @persi pour l'exemple que tu donnes, et merci à toi aussi @tomlev pour ces précisions

En effectuant quelques recherches, je suis même parvenu à trouver ce lien msdn qui liste les différents providers ADO.NET disponibles.

[bnogent]

fort d'une experience de plus de 15 ans en java et 11 ans en c#, et des dizaines voire des centaines de differents projects je peux temoigner de mon experience dans ces 2 languages.

Dabord, les projets c# sur lesquels j'ai travaille etaient toujours plus bordeliques au sens qualite du code et organisation du code.

C'est con mais moi meme, mes projets java ont toujours etes mieux structurer en java. Le fait d'avoir une classe par fichier ca peux paraitre con mais ca structure les dev pour un grand projet.

c'etait juste un petit commentaire rapide...

[Gugelhupf]

C'est con mais moi meme, mes projets java ont toujours etes mieux structurer en java. Le fait d'avoir une classe par fichier ca peux paraitre con mais ca structure les dev pour un grand projet.

Etant moi-même développeur C++ (possibilité de créer plusieurs classes par fichier), je pense à la même chose, je trouve que c'est plus sympa de limiter la création d'une classe par fichier.
Encore si ça ne concernait que mes projets, ça va je ne peux m'en prendre qu'à moi-même, mais comment prévoir la réaction des autres développeurs qui mettent tout dans un sac ?

[tomlev]

Dabord, les projets c# sur lesquels j'ai travaille etaient toujours plus bordeliques au sens qualite du code et organisation du code.

Le langage n'a rien à voir là-dedans ; tous les design patterns que tu appliques en Java sont tout aussi applicables en C#, vu que les 2 langages ont à peu près la même approche de la POO. Après c'est juste une question de rigueur...

C'est con mais moi meme, mes projets java ont toujours etes mieux structurer en java. Le fait d'avoir une classe par fichier ca peux paraitre con mais ca structure les dev pour un grand projet.

Même si C# ne l'impose pas, la plupart du temps on a effectivement une classe par fichier. Si tu en mets plusieurs dans le même fichier, c'est ton choix... Donc ça ne me parait pas très solide comme argument.

[persi]

Etant moi-même développeur C++ (possibilité de créer plusieurs classes par fichier), je pense à la même chose, je trouve que c'est plus sympa de limiter la création d'une classe par fichier.
Encore si ça ne concernait que mes projets, ça va je ne peux m'en prendre qu'à moi-même, mais comment prévoir la réaction des autres développeurs qui mettent tout dans un sac ?

Oui ca je peux comprendre, moi aussi ca me gêne parfois, ou aussi quand apres un changement de répertoire les namespaces ne sont plus cohérents avec mon arborescence par ex.

[gerard093]

Java est un langage plutôt complet. Il devrait donc se maintenir dans les environnements mini et micro, comme pour les mobiles. La syntaxe lourde n'est plus un problème depuis que les EDI proposent les compléments de code.

Et puis, parlant ancêtres, sur les produits IBM, les applications cobol/cics ça existe encore. Et on trouve même du java cics...

Le seul risque réel serait une brutale incompatibilité avec les futurs systèmes d'exploitation de Microsoft C'est vrai que Microsoft a des pratiques monopolistiques. C'est un gros joueur, qui aime piloter en solo ... Et java pourrait peut être devenir vulnérable, face au C# et .net

[niarkyzator]

J'ai quand même l'impression que tout ceux qui disent que java est mourant n'ont jamais développé en java...

C'est comme le débat JSON va remplacer le XML qui ressort tout les 6 mois et qui dit que XML est mort, ça me fait toujours bien rigoler.

Suffit de regarder la communauté eclipse ou spring, ou ce qu'on peut faire avec jboss, camel, service mix : ça m'a l'air plutôt en bonne santé.

[deuz59]

J'ai surtout l'impression qu'on cherche à combler les faiblesses des développeurs via les langages.

Ces faiblesses augmentant sans cesse, il faut perpétuellement trouver de nouveaux langages et renier les anciens pour leur rejeter la faute de notre incompétence.

Le bon côté des choses, c'est qu'on s'assure ainsi l'avenir de la profession :-D

[ptah35]

J'ai surtout l'impression qu'on cherche à combler les faiblesses des développeurs via les langages.

Oui, c'est effectivement le cas, mais je préfère parler de limites que de faiblesses. Il n'est pas possible pour un humain de gérer la complexité au delà d'un certain niveau. John Backus a développé FORTRAN parce qu'il trouvait pénible d'avoir à écrire et réécrire des centaines de lignes d'assembleur pour coder des équations.

La puissance des ordinateurs de bureau étant virtuellement illimitée, toujours plus de développeurs (et pas seulement quelques "génies") doivent faire face à des problèmes toujours plus complexes. Il faut donc des langages permettant d'y faire face sans tout révolutionner. Presque personne ne s'est tourné vers les langages fonctionnels, mais beaucoup d'éléments de ces langages apparaissent aujourd'hui dans Java, C# ... et en C++.

[deuz59]

Oui, c'est effectivement le cas, mais je préfère parler de limites que de faiblesses. Il n'est pas possible pour un humain de gérer la complexité au delà d'un certain niveau. John Backus a développé FORTRAN parce qu'il trouvait pénible d'avoir à écrire et réécrire des centaines de lignes d'assembleur pour coder des équations.

C'est vrai également, mais pour moi il y a les 2 phénomènes.
- besoin d'abstraction : apparition de nouveau paradygme de programmation (assembleur => modulaire => objet...), la contre partie c'est qu'on ne maitrise plus ce qui a été rendu abstrait pour nous permettre de faire plus complexe
- problème de maitrise des langages : on reporte la faute sur l'outil, on cherche une alternative à tord. Le résultat sera qu'on fera pas mieux au final :p

[ptah35]

la contre partie c'est qu'on ne maitrise plus ce qui a été rendu abstrait pour nous permettre de faire plus complexe

C'est une réalité... mais est-ce grave?

Combien d'électroniciens seraient capables d'utiliser les équations de Maxwell pour calculer un circuit? Probablement aucun... les lois de Kirchhoff en sont le plus souvent une abstraction adéquate. Combien de programmeur sont capable de concevoir une carte-mère (ou même une carte à micro-processeur)? Bien peu, les systèmes d'exploitations nous offrent une abstraction du matériel qui se trouve a des années-lumière de la réalité, mais qui pourtant est tout à fait adéquat.

Si beaucoup de gens éprouvent des difficultés avec une abstraction, on peut bien sûr tenter de les amener à s'améliorer, mais on peut aussi se demander si l'abstraction ne pourrait pas être améliorée. Je pense qu'il est bon de travailler sur plusieurs fronts.

[deuz59]

C'est une réalité... mais est-ce grave?

Disons qu'on fait avec, c'est une contre-partie naturelle sans quoi on ne serait pas capable d'aller plus loin et de faire plus complexe.

Ce n'est pas grave jusqu'au jour où y'a un soucis dans la partie abstraite, souvent des problématiques de performances par exemple...de plus en plus difficile de trouver les compétences, quelqu'un qui saura te dire ce que ton JAVA il fait mal par exemple, et comment lui faire faire de façon plus adaptée