Discussion :

[denisBertin]

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.

[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 )

[persi]

Bonjour,

Si je prends le même exemple pour C#, à moins d'installer un ORM comme NHibernate, je dois adapter le nom des classes en fonction du SGBDR, n'y a-t-il aucune interface générique de connexion à une base de données dans le framework .NET ?
Si je comprends bien ODBC n'est de base que disponible sous Windows, comment m'y prendre avec Mono sous Linux tout en essayant de rester portable ?
Si je dois installer ODBC pour me connecter en C#, n'y a-t-il pas moyen de de directement l'inclure dans mon projet (comme l'inclusion des JDBC.jar en Java), au lieu de passer par une installation d'exécutable sous chaque machine ?


Cordialement,

C'est vrai que la plupart des samples sur le net proposent une implémentation concrète. en réalité il faudrait faire comme ça.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
ConnectionStringSettings connectionString = ConfigurationManager.ConnectionStrings[connectionName];
DbProviderFactory factory = DbProviderFactories.GetFactory(connectionString.ProviderName);
DbConnection connection = factory.CreateConnection()

[e-ric]

Mais allons y, trouvez-moi un meilleur IDE gratuit (de n'importe quel langage).

Je connais pas VS ni Eclipse mais j'ai toujours apprécié l'IDE de Delphi (non gratuit), je le trouve confortable et suffisamment pratique.
L'IDE de Lazarus s'en inspire mais a des fonctions différentes, il n'est pas mal non plus mais avec l'habitude sur Delphi, c'est parfois pénible (c'est dur les habitudes).
Enfin, j'avais regardé Eclipse à une époque mais j'ai vite tout refermé, cela m'avait paru très bizarre à l'époque.

[Bestel74]

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.

C'est justement un avantage
C'est ce qui permet de faire du code qui puisse tourner sur toutes les JVM

Bon après si t'as pas de JVM, ben c'est sur que ton byte-code tu peux...

[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)

[e-ric]

C'est justement un avantage
C'est ce qui permet de faire du code qui puisse tourner sur toutes les JVM

Bon après si t'as pas de JVM, ben c'est sur que ton byte-code tu peux...

Un avantage sauf pour la performance, il y a encore des applications qui doivent tourner vite. Je me souviens d'un entretien dans un grand compte bancaire où l'on m'a dit que les développements étaient pour la plupart faits en Java, mais dès qu'il était question de performances, on passait à Delphi.

[tomlev]

Si je prends le même exemple pour C#, à moins d'installer un ORM comme NHibernate, je dois adapter le nom des classes en fonction du SGBDR, n'y a-t-il aucune interface générique de connexion à une base de données dans le framework .NET ?

Bien sûr que si, il y a une couche d'abstraction qui permet d'écrire du code générique : http://johannblais.developpez.com/tu...acces-donnees/
(après bien sûr il faut tenir compte des différences entre les dialectes SQL, d'où l'intérêt d'utiliser plutôt un ORM)

Si je comprends bien ODBC n'est de base que disponible sous Windows, comment m'y prendre avec Mono sous Linux tout en essayant de rester portable ?
Si je dois installer ODBC pour me connecter en C#, n'y a-t-il pas moyen de de directement l'inclure dans mon projet (comme l'inclusion des JDBC.jar en Java), au lieu de passer par une installation d'exécutable sous chaque machine ?

Je pense que tu fais une confusion : l'équivalent Microsoft de JDBC n'est pas ODBC, c'est ADO.NET...

ODBC est une techno antérieure à .NET, qui permettait déjà de faire abstraction du SGBD utilisé. Au début de .NET, beaucoup de SGBD ne fournissaient que des pilotes ODBC, donc .NET incluait un adaptateur entre ODBC et ADO.NET. Mais aujourd'hui la plupart des SGBD ont un provider ADO.NET, le recours à ODBC (qui était effectivement spécifique à Windows) n'est généralement plus nécessaire.

[esperanto]

La situation de Java aujourd'hui est complexe et incertaine.

Si on se place d'un point de vue extra-informatique, Java est fortement menacé dans les années à venir (notez que je n'ai pas dit à long terme: la situation pourrait se retourner ensuite) à cause de la politique ambiguë d'Oracle :
pour le décideur en entreprise, le procès Google peut l'amener à se poser des questions - même si les raisons de ce procès sont très spécifiques à ce qu'a fait Google, même s'il a peu de chances d'être attaqué, le fait est qu'il préfèrera déconseiller Java à ses programmeurs que de prendre le risque de violer un contrat qu'il n'a pas le temps de lire en détail;
pour les développeurs, il y a la question de la liberté : Sun avait fait un pas en libérant le JDK, mais pas encore la spécification ni le protocole de test qui va avec; Java n'était donc pas libre mais il aurait pu le devenir à moyen terme, mais Oracle en a décidé autrement. Un JDK libre est suffisant pour permettre de se créer un environnement entièrement libre (Debian peut l'intégrer par exemple) mais une spécification non-libre fait que la situation pourrait un jour se retourner (même si la GPL ne permet pas de rendre OpenJDK propriétaire plus tard, il suffirait à Oracle de repartir d'une version plus ancienne non-libre et de rajouter dans la spec un truc dont tout le monde veut mais suffisamment complexe pour que les développeurs d'OpenJDK mettent un bout de temps à suivre)

Maintenant, d'un point de vue purement informatique, avant de savoir si Java est menacé il faudrait savoir de quoi on parle : c'est quoi Java?
Même si ça a été vendu comme un tout, Java, en tant que spécification, ce sont 3 choses distinctes:
1) une syntaxe et le compilateur qui va avec;
2) une API (des classes déjà écrites mais aussi leur spécification)
3) une machine virtuelle

J'ai l'impression que l'article et beaucoup de réponses se focalisent en fait sur le point 1. En gros, si vous n'aimez pas écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
new XXXListener() { 
public void action(...) {}
}

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

List<String> L = new ArrayList<String> ()

, ben rien ne vous empêche d'utiliser Groovy ou Jython, le code généré utilisera toujours les classes de 2) et la machine virtuelle de 3) tout en vous permettant d'écrire du code plus court. Il existe même des langages de script avec la syntaxe de Java en plus dépouillé. ça ne remet pas en cause l'existence de la plateforme Java dans son ensemble.

Reste le problème de la liberté d'utiliser Java.
Le nom Java est associé à quelque chose de non libre puisque certains éléments comme le protocole de test sont et resteront non libres. Et paradoxalement, c'est Microsoft avec le premier procès Java qui a montré ce qu'il en coûte d'utiliser le nom Java à tort et à travers.
Sun n'a jamais été contre des ré-implémentations de sa spécification, quelles qu'en soient les licences. De toute façon, même sans parler de logiciel libre, une ré-implémentation est indispensable pour respecter le caractère multiplateforme de Java (Sun ne fournissant pas le JDK pour les environnements les plus exotiques). On a rapidement vu des implémentations libres de 1 (guavac) et 3 (kafee, sablevm, ...) par contre pour 2, le Gnu Classpath a et aura toujours des années de retard sur l'évolution de la spec. Puis on a vu qu'en plus d'être implémentables séparément, les trois éléments peuvent être substitués : les langages de script remplacent 1 sans remettre en cause 2 ou 3; dans Android, les classes de 2 sont en partie remplacées; et bien sûr, 3 peut être remplacé par une autre vm (celle d'Android n'est pas une JVM) voire par de la compilation native (gcj).
Mais maintenant, Oracle voit tout ça d'un mauvais oeil et tente de détruire (soit par procès soit, comme pour Apache Harmony, en refusant la certification) toute implémentation alternative, même d'un des 3 éléments. Reste à savoir si en faisant ça, Oracle ne va pas faire peur à tous les non-informaticiens qui décident de son sort en entreprise.

Alors que faire? Ici je vais citer un message provenant de la discussion "Oracle critique le logiciel libre", également d'aujourd'hui:

Je suis d'ailleurs étonné pour Java qu'il n'y ai pas une initiative équivalente

Si par initiative équivalente on entend forker ou réimplémenter le JDK, voir ce que je disais plus haut, c'est déjà fait depuis longtemps même si c'est parfois partiel. Mais toujours en respectant la spec fournie par SunOracle.

En revanche si par initiative équivalente on entend : créer une nouvelle spécification libre pour une plateforme (comprenant 2-VM et 3-API mais laissant plus de liberté pour le langage, afin de se placer au même niveau que .NET qui n'est pas strictement lié à C#) alors là il y a sans doute quelque chose à creuser. Il y a déjà un début de tentative avec Parrot (machine virtuelle de Perl 6, potentiellement capable d'interpréter Ruby ou Python) mais elle est liée aux langages à typage dynamique, donc elle ne sera jamais aussi performante qu'une JVM même si on compile du Java dessus.
C'est drôle, dans le monde du libre on trouve des dizaines (centaines?) de langages de script, d'abord écrits en C (et interprétés, donc avec une forme de VM) mais alors qu'on y critique beaucoup Java et C#, on les y a réimplémentés en une dizaine d'exemplaires mais jamais on a songé à créer une troisième VM similaire (avec typage fort, API multiplateforme complète, etc.) dont les spécifications seraient libres. ça peut paraître inutile car les spécifications des deux VM sont ouvertes, mais le jour où Oracle rajoutera un élément crucial mais interdit d'implémenter dans le libre, toutes les entreprises se jetteront dessus mais les auteurs de logiciels libres en Java (ben oui on le critique mais on l'utilise...) l'auront dans le baba. En attendant, le nombre de projets libres en Java ne cesse de croître...

[Francisco22]

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

[Mat.M]

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.

c'est exact mais Java n'a pas été pensé pour cela.
Java a été pensé pour être multiplateformes et éviter les problèmes relatifs au C++, les pointeurs , la gestion de la mémoire..

[persi]

Maintenant, d'un point de vue purement informatique, avant de savoir si Java est menacé il faudrait savoir de quoi on parle : c'est quoi Java?
Même si ça a été vendu comme un tout, Java, en tant que spécification, ce sont 3 choses distinctes:
1) une syntaxe et le compilateur qui va avec;
2) une API (des classes déjà écrites mais aussi leur spécification)
3) une machine virtuelle

On parle du point 1 parce que le sujet est "Java est-il un langage de programmation mourant".

[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.

[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.

[BenoitM]

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.

Perso dans le projet où je suis on doit généré des GUID pour que nos classes soient portable en VB6.
J'ai un générateur qui part contre toutes mes classes et génére un GUID et je met tout ca dans un seul fichier.
Le jours où je n'aurai plus besoin du VB6 je n'aurai qu'un fichier a supprimer.