Discussion :

[adiGuba]

ça date de quelle version ?

Depuis l'intégration des Generics, c'est à dire Java 5

Cf ici (même si c'est pas super détaillé) : http://lroux.developpez.com/article/...ldcardGenerics

je parlais de C++...

Oups

au temps pour moi... mais je croyais justement que pour "rendre" compatible ce genre de code sur du 1.4.2 on utilisait des réécritures bizarres de bytecode, et des vérifications juste avant

Non un code avec des Generics est obligatoirement compilé en 1.5, et ne fonctionnera pas sur du 1.4. La compatibilité descendante n'est pas assuré !

C'est la compatibilité descendante qui l'est : un code 1.4 (ou inférieur) qui utilise des classes qui ont été Genericifié en 1.5 continueront à fonctionner sur une JVM 1.5. Mieux : les classes Generics peuvent être utilisé sans typeage. Le "row type" est alors utilisé (le type de base décrit dans la définition du type paramétré - Object par défaut).

Cela génère un certain nombre de warning mais ca compile. C'était super important pour éviter que les anciens programmes restent compilables, afin d'éviter d'avoir à adapter des tonnes de code lors de la migration...


Par exemple dans ma boite cela fait plusieurs année que l'on a migré sur Java 5, et si on utilise bien les Generics sur les nouveaux codes, nous sommes resté pendant longtemps avec des collections non-typés dans les anciens codes...


a++

[jabbounet]

Bon bah moi je vais revenir au sujet principale et voici mon avis:
Je préfére le java, car il est portable, contrairement au C++,beaucoup moins complexe que le C++, et puissant de part ses api et package(JDBC,JEE....).

C'est un choix, cela se respecte.

De plus certaine personne lui reproche d'être lent, mais j'ai lu dans un bouquin que cela dependait du code, et de la facon dont on code!

Oui la conception représente un part importante des performances d'une application quelque soit le langage.

maintenant je ne suis pas sur qu'empiler tout un tas de framework et les amalgamer pour obtenir une application plus ou moins cohérente, soit ce qu'il y'a de plus efficace pour atteindre de bonnes perf sur une appli.

Tu gagne en temps de développement c'est certains. Mais la contrepartie est que ces framework ne répondant pas complètement a tes besoins, tu devra mettre de la glue pour essayer de les faire fonctionner ensemble avec plus ou moins d'harmonie et tu risque au final de faire une application qui sera plus lourde que la même application conçu et développé de A à Z dans un but précis (cette remarque n'est pas dépendante du langage non plus).

la modularité et la réutilisation c'est bien a condition de ne pas le faire de n'importe quelle façon, le tout étant comme d'habitude de trouver le bon compromis entre temps de dev/perf/maintenabilité/.....

Ensuite le fait qu'il soit complétement Orienté Objet en fait un atout pour les entreprises, qui y voient une organisation plus facile. Pour moi le Java m'a appris a reflechir, car avant je codais et codé(en C), mais maintenant je prend le temps de me poser et modeliser mes applications... De cette facon j'evite les bugs, et je vais plus rapidement!

Je ne vois pas ce qui t'empêchait de faire des modélisation à l'époque ou tu codais en C, perso je ne développe jamais une nouvelle appli sans d'abord avoir écrit les specs et fait la conception.

La méthode objet n'est pas lié a un langage en soit, rien ne t'empêche faire ton modèle en UML et de tout coder en assembleur derrière (même si la ce sera hardcore).

[djisse]

Je ne vois pas ce qui t'empêchait de faire des modélisation à l'époque ou tu codais en C, perso je ne développe jamais une nouvelle appli sans d'abord avoir écrit les specs et fait la conception.

La méthode objet n'est pas lié a un langage en soit, rien ne t'empêche faire ton modèle en UML et de tout coder en assembleur derrière (même si la ce sera hardcore).

Je veux dire que ca m'oblige a creer des objet... et je sais pas pour vous, mais moi, avec des objets mon programme est mieux orgainés, mieux modifiable.... alors qu'en C, pour modifier ne serais-ce un endroit, je devais me casser la tête a relire quelues ligne pour savoir ou modifier et comment.... et pire encore si j'ajoutais modifs sur modifs.... enfin quoi, c'etait le bordel! Mais ca c'est ma facon de programmé en C, peut êtr que pour d'autre c'est plus facile... encore une fois ce n'est qu'un avis personnel!

[jabbounet]

tout dépend de la façon dont tu organise ton code.

le problème du C sur ce point c'est qu'il est beaucoup plus permissif que d'autres, donc si tu veux un code maintenable/portable/lisible... il te faut beaucoup plus de rigueur qu'avec d'autres langages .

[Luc Hermitte]

a- Bon bah moi je vais revenir au sujet principale et voici mon avis:
Je préfére le java,
b- car il est portable, contrairement au C++,
c- beaucoup moins complexe que le C++,
d- De plus certaine personne lui reproche d'être lent, mais j'ai lu dans un bouquin que cela dependait du code, et de la facon dont on code!
e- Ensuite le fait qu'il soit complétement Orienté Objet

a- Arg. 102 pages de débat. Déjà débattu dans tous les sens.

b- faux : il y a des contraintes de portabilité en Java comme en C++. Dans les deux il suffit de connaitre le sous-ensemble portable du langage sur les plateformes visées ; en revanche quand portable, la portabilité va au délà de la portabilité des sources.

c- cela dépend pourquoi faire beaucoup de choses sont facilités en java, d'autres le sont plus en C++ (cf boost.unit)

d- des faits ! Des observations à toi au minimum (cf les règles de ce forum Débat)

e- non seulement c'est faux (cf les types primitifs) ; de plus il n'a pas certains apsects OO supportés en C++, ou dans d'autres langages OO ; entre temps il s'est rajouté généricité qui sort du cadre OO, et il a failli avoir les closures ; mais en plus, cela n'a jamais été un gage de qualité que d'avoir des oeillières.

[Tommy31]

c- cela dépend pourquoi faire beaucoup de choses sont facilités en java, d'autres le sont plus en C++ (cf boost.unit)

cf. JScience (JSR-275).

e- non seulement c'est faux (cf les types primitifs) ;

L'autoboxing peut faire paraître l'inverse.

[djisse]

a- Arg. 102 pages de débat. Déjà débattu dans tous les sens.

b- faux : il y a des contraintes de portabilité en Java comme en C++. Dans les deux il suffit de connaitre le sous-ensemble portable du langage sur les plateformes visées ; en revanche quand portable, la portabilité va au délà de la portabilité des sources.

c- cela dépend pourquoi faire beaucoup de choses sont facilités en java, d'autres le sont plus en C++ (cf boost.unit)

d- des faits ! Des observations à toi au minimum (cf les règles de ce forum Débat)

e- non seulement c'est faux (cf les types primitifs) ; de plus il n'a pas certains apsects OO supportés en C++, ou dans d'autres langages OO ; entre temps il s'est rajouté généricité qui sort du cadre OO, et il a failli avoir les closures ; mais en plus, cela n'a jamais été un gage de qualité que d'avoir des oeillières.

a/J'ai dit JE préfére le java!Je n'ai jamais dit: Java c'est le meilleur!
b/Je suis d'accord sur ce pont... mais faut quand même dire que java est multi plateforme, et c'est plus facile de faire tourner du code java partout que le C++.non?
c/Je parle en générale. Le java est plus simple et plus facile a apprendre que le C++, et je pense pas être le seul à le penser . non?
d/alors là je vois pas ce que tu veut dire!
e/Bien que je ne sois pas un expert en java, je sais quand même que tout code java doit être mis dans une classe(sauf les imports).Classe=POO.Il y a peut être certains points en java qui ne font pas reference a la POO, mais en generale..... non?

[koala01]

a/J'ai dit JE préfére le java!Je n'ai jamais dit: Java c'est le meilleur!

C'est ton avis, et on le respecte
b/Je suis d'accord sur ce pont... mais faut quand même dire que java est multi plateforme, et c'est plus facile de faire tourner du code java partout que le C++.non?[/QUOTE]
Il y a beaucoup plus de choses portables en C++ que ce que tu ne semble imaginer:

De la STL à des bibliothèques IHM (et qui fournissent d'ailleurs souvent plus qu'une simple IHM), on rencontre de plus en plus de bibliothèques qui sont développées dans le but d'être portables

Après, si tu considère le fait de devoir recompiler ton exécutable en fonction de l'OS sur lequel il tourne comme une difficultépour être multi plateforme, il ne faut pas te leurrer: java l'est parce qu'il existe des binaires différents pour chaque Os de la JVM

c/Je parle en générale. Le java est plus simple et plus facile a apprendre que le C++, et je pense pas être le seul à le penser . non?

Ca se discute...

Je ne nie pas que C++ soit globalement plus complexe que java, mais c'est le prix d'une certaine liberté

e/Bien que je ne sois pas un expert en java, je sais quand même que tout code java doit être mis dans une classe(sauf les imports).Classe=POO.Il y a peut être certains points en java qui ne font pas reference a la POO, mais en generale..... non?

Tu sais, parfois, être en mesure de sortir de carcans trop serrés permet de se simplifier énormément la vie

Il est faux de croire que le paradigme OO soit la solution à tous nos problèmes, tout comme il est faux de le croire pour le paradigme procédural, générique, fonctionnel ou autre...

Le fait d'intégrer plusieurs paradigmes au sein d'un langage de manière à ce qu'il ne faille pas utiliser des ruses de sioux pour arriver à les faire cohabiter et à passer de l'un à l'autre permet une souplesse que tu ne trouvera jamais auprès de langage "uni paradigmes"...

En effet, cela te permet de prendre le meilleur de chaque paradigme

A l'extrême limite, ce qui manque au C++ serait peut etre le paradigme fonctionnel

Le tout sans compter sur le fait que la nouvelle norme (prévue pour bientôt) devrait apporter pas mal de nouveautés susceptibles de faciliter l'utilisation

[djisse]

De la STL à des bibliothèques IHM (et qui fournissent d'ailleurs souvent plus qu'une simple IHM), on rencontre de plus en plus de bibliothèques qui sont développées dans le but d'être portables

Je ne connaissait pas ces points là. Je pense maintenant que Java est C++ se valent. Car il y a certains points où java est mieux, que le C++ et reciproquement pour le C++.
Merci de ta reponse elle m'a eclairé certains points obscur.

[Tommy31]

De la STL à des bibliothèques IHM (et qui fournissent d'ailleurs souvent plus qu'une simple IHM), on rencontre de plus en plus de bibliothèques qui sont développées dans le but d'être portables

Donc la portabilité du C++ est dépendante des bibliothèques tierces dont la capacité de portage varie de l'une à l'autre. Ce n'est pas systématiquement le cas en java, où le jdk pourvoit à la plupart des besoins.

Le fait d'intégrer plusieurs paradigmes au sein d'un langage de manière à ce qu'il ne faille pas utiliser des ruses de sioux pour arriver à les faire cohabiter et à passer de l'un à l'autre permet une souplesse que tu ne trouvera jamais auprès de langage "uni paradigmes"...

Justement, qu'en est-il du pardigme aspect en C++ ?

[spidermario]

Donc la portabilité du C++ est dépendante des bibliothèques tierces dont la capacité de portage varie de l'une à l'autre. Ce n'est pas systématiquement le cas en java, où le jdk pourvoit à la plupart des besoins.

Dépendre de Qt ou du JDK ne change pas grand chose à mon avis...

Justement, qu'en est-il du pardigme aspect en C++ ?

Ça avance

[Tommy31]

Ça avance

Dernière news : 20th Dec 2007
Comparé à AspectJ (dernière news 17-Jun-09)

Pas cool

[GanYoshi]

La compatibilité descendante n'est pas assuré !

C'est la compatibilité descendante qui l'est :

C'était super important pour éviter que les anciens programmes restent compilables

La fatigue

[spidermario]

Dernière news : 20th Dec 2007
Comparé à AspectJ (dernière news 17-Jun-09)

Pas cool

Oups, j'avais pas vu :s
La version dans les dépôts d'Ubuntu est celle du 11/07/2008, c'est un tout petit peu mieux... mais c'était quand même il y a plus d'un an
Ceci dit, il y a peut-être des alternatives à Aspect-C++ pour la POA en C++ ?
Enfin bon, j'ai jamais compris l'intérêt de la POA.
Edit : après un petit tour sur Wikipedia, l'intérêt de la POA commence à me parvenir. Toutefois, ça a l'air d'être une horreur à mettre en oeuvre.

[adiGuba]

La fatigue

Oui

Je voulais bien sûr dire que c'est la compatibilité ascendente qui est assuré par Java : les anciens programmes peuvent continuer à fonctionner à l'identique sur une JVM plus récente, et dans une moindre mesure il peuvent continuer à être compilé sur un JDK plus récent.

a++

[jabbounet]

je dirais que la compatibilité ascendante n'est pas dépendante d'un langage en particulier. n'importe quel éditeur de soft sérieux essaie de la conserver au maximums dans ses produits, si il n'a pas ce type de politique il risque de perdre quelques clients.

[noctua]

salut,
je n'ai pas tout lu mais je voulais réagir sur la partie où certains disent que le c/c++ va tendre à disparaitre...
en fait, il ne peut pas disparaitre pour la simple raison que c'est les seules langages en dehors de l'assembleur que l'on utilisent pour programmer des composants électroniques...

En effet, on utilise principalement des processeurs tournant à une fréquence de quelques Mhz (de l'ordre de 2 à 20 MHz) avec de la mémoire type rom et ram de quelques KO...
Dans ce cas seul les assembleurs spécifiques à ces circuits (le code machine n'a rien à voir avec le langage des processeurs PC) et le C (peut être me le C++ pour certains)...

pour finir quelques exemples de matériels avec de tels processeurs:
-calculatrices scientifiques
- direction assistée et autres fonctions dans les voitures
-lecteur dvd
...

C'est donc pour cela que je me suis orienté plutot vers le C++ en étant électronicien il me sera bien plus utile que le java

[spidermario]

Tu cites l'exemple es lecteurs DVD, cependant c'est du Java qu'ils ont mis dans les lecteurs Blu-Ray

[jabbounet]

en fait, il ne peut pas disparaitre pour la simple raison que c'est les seules langages en dehors de l'assembleur que l'on utilisent pour programmer des composants électroniques..

vhdl pour programmer des fpga (si je me souviens bien)
Ada peu tourner directement sur un hard sans os (contrainte imposé lors de la conception du langage).

donc ce n'est pas le seul....

[souviron34]

n'importe quel éditeur de soft sérieux essaie de la conserver au maximums dans ses produits, si il n'a pas ce type de politique il risque de perdre quelques clients.

Et l'on voit tous les jours que, si je suis tes critères, de très grands éditeurs de softs ne sont pas sérieux

Justement parce qu'ils sont très gros..