2.Portabilité : S'exécute presque n’ importe où (Windows, Linux, Unix, Mac OS, téléphones mobiles, robots,...). Le slogan de JAVA est “Write Once run Everywhere”
3.Flexibilité : Avec Java, on peut créer des applications desktop, web, mobile, interagir avec différents SGBD, créer des programmes fonctionnant en réseaux (client / Serveurs),…
4.Extensibilité : Il existe des nombreuses bibliothèques et Frameworks tierces chacun spécialisé dans un domaine spécifique. Il est donc rare de manquer la bibliothèque appropriée pour les besoins courants.
5.Orientée Objet : L'approche objet permet de bien concevoir les applications orientées métiers conformément à la modélisation établie dans le chapitre III.
6.Disponibilité des outils : Java est un langage libre ce qui fait que de nombreux éditeurs créent des outils de développement souvent libre. Ainsi des nombreux IDE, serveurs web et serveurs d'application sont disponible gratuitement sur le marché.
7.Gestion efficace de la mémoire : Java intègre un mécanisme d'allocation et désallocation automatique de la mémoire (Garbage collector) permettant au développeur de se concentrer sur la logique de l'application. La fuite de la mémoire est le principal bug des logiciels écrits en C/C++ [18].
8.Disponibilité de plusieurs implémentations : Java est basé sur des spécifications JSR. Ainsi lorsqu'une fonctionnalité est manquante, elle est soumise à la communauté via le JSR, les décideurs de JAVA créent alors une spécification qui est rendu publique. Ce qui permet à n'importe quel éditeur de développer une implémentation de la spécification.
9.Bien maintenu : L'évolution du langage est assurée par Oracle et ses collaborateurs qui effectuent des mises à jour régulières et des corrections de bugs. Il n'y a pas de risque que le langage disparaisse du jour au lendemain.
10.Une grande communauté : L'indice TIOBE montre que JAVA est le second langage le plus utilisé au monde. Ceci indique la maturité du langage ce qui signifie qu’il y a beaucoup de ressources (Articles, tutoriels, livres, cours, forums) à la disposition du programmeur.
Bon ... Je ne suis développeurs Java que très rarement ... Encore moins pour le Web ...
Cependant, je peux dire que lesIDE pour Java sont lourds. Très lourds, lents et pas souvent claires.
Le fait qu'ils existent plusieurs implémentations ne constitue pas vraiment un avantage pour moi ... Ces differentes implémentations entraînent des incompatibilités. Une implémentation unique, libre, aurait été très bien ...
Le fait que dernière Java, il y ai une entreprise ne me fait pas vraiment plaisir. J'aurais préféré une association ou un simple comité/groupe d'utilisateurs.
La flexibilité de Java ne me semble pas non plus exceptionnelle comparé aux autres langages.
Le prix n'est pas tant un argument puisque la plus part des langage sont gratuit.
Le GC, c'est une question de choix.
J'ai toujours trouvé l'OO de Java contradictoire. Omniprésente mais en même temms, les types mrimitifs ne le sont même pas :/ Après ça reste un bon argument pour ce langage ...
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles- ♡ Copying is an act of love.
Le fait qu'ils existent plusieurs implémentations ne constitue pas vraiment un avantage pour moi ... Ces differentes implémentations entraînent des incompatibilités. Une implémentation unique, libre, aurait été très bien ...
Pas d'accord, c'est un peu comme dire "Ah non ça sert à rien Clang, Visual C++, Solaris Studio C++, Intel ICC parce que GCC ça suffit amplement". Généralement quand un code Java compile avec un compilateur X mais pas avec javac, c'est qu'il n'est pas conforme, les incompatibilités en Java on n'en voit pas des masses (n'hésite pas à me dire si tu en trouves, sauf ceux qui sont reportés comme des bugs). Il existe une implémentation libre et officielle, ça s'appelle OpenJDK : http://openjdk.java.net/
Oula, je suis un programmeur Java qu’exceptionnellement. Pour moi différentes implémentation => Incompatibilités. Je serais incapable de t'en cité ne serait-ce qu'une.
Sinon, je suis un peu d'accord. Python par exemple possède une implémentation de base et ensuite on en retrouve d'autres. C'est encore plus visible avec le langage Haskell avec GHC.
Pour moi, le C et le C++ auraient été meilleurs s'il y avait eu une implémentation chacun et libres toutes les deux (une implémentation de la norme en somme).
- Edité par @che 13 juillet 2015 à 15:35:05
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles- ♡ Copying is an act of love.
Pour moi, le C et le C++ auraient été meilleurs s'il y avait eu une implémentation chacun et libres toutes les deux (une implémentation de la norme en somme).
Rien ne peut le laisser supposer. Le libre n'est pas nécessairement gage de qualité, sans parler des implémentations uniques. Je suis bien content que Clang soit tous les jours plus proche de botter le cul de GCC qui par conception est atrocement complexe à faire évoluer, se traîne le boule et fournit toujours ses messages d'erreurs imbuvables.
Comme le sujet a été alimenté en argument, je ne vais pas le fermer
@che a écrit:
Oula, je suis un programmeur Java qu’exceptionnellement. Pour moi différentes implémentation => Incompatibilités. Je serais incapable de t'en cité ne serait-ce qu'une.
- Edité par @che le 13 juillet 2015 à 15:35:05
Du coup, je ne comprends pas comment tu peux donner un avis sur quelque chose que tu ne connais pas. C'est vraiment dommage car ça peut induire les autres en erreurs
@max-om-93: Bon premièrement, j'ai bien précisé avant mon message que je ne maîtrisait pas Java. Ensuite, s'il y a plusieurs implémentations alors c'est qu'il y a quelque chose de différents donc des incompatibilités. De plus, plusieurs implémentations ne sont jamais au même niveau d'implémentation du standard.
Bref, en cherchant rapidement, désormais Java utilise un référence Libre ( Ça c'est un point positif !). C'est à dire que la référence est OpenJDK.
1 seule implémentation c'est mieux ? Je te citerai la SNCF comme exemple. Pourquoi c'est la merde ? parce qu'ils n'ont pas de concurrence donc ils se contentent du minimum.
Qu'appelles-tu incompatibilité ? Ne veux-tu pas dire différence plutôt ? Oui c'est possible qu'il y ait des différences entre les implémentations, et c'est tant mieux : chacun possédera ses avantages et inconvénients ! Exemple : l'interface List possédant plusieurs implémentation
Résonnement par l'absurde : supposons que "1 norme + diverses implémentations" était mauvais. Prenons l'exemple du SQL...
SQL est une norme, et il existe plusieurs SGBD (SQL Server, Oracle, PostgreSQL => donc le SQL c'est mauvais. Là on arrive déjà à une absurdité : quasiment tous les systèmes se basent sur le SQL.
Si l'on se restreint à 1 SGBD (par non-hasard) SQL Server => il n'est disponible que sous Windows (licence, dépendances, et tout le bordel...) Nouvelle absurdité, car Windows est loin d'être un OS de référence pour y héberger les serveurs.
On pourrait aussi prendre d'autres exemple pour montrer que plusieurs implémentations c'est la merde :
plusieurs spécificités à apprendre : chacun va implémenter au minimum la norme, mais pourra proposer des fonctionnalités/spécificités supplémentaires
documentation divisée : 1 par implémentation
moins rapide à se développer : développeurs dans leur coin plutôt que tous concentrés sur le même programme
Dans les 2 cas il y aura des avantages et des inconvénients.
On peut maintenant citer des exemples où avoir diverses implémentations pourrait aider : - en production j'ai besoin de performances : j'utilise donc un SGBD plutôt performant (Oracle, SQL Server, ...) - en local je n'ai pas envie de mettre 2jours à installer un SGBD, ni payer les licences, ... : j'utilise PostgreSQL, libre, qui s'installe en 2 clics Maintenant : - soit je développe 2 requêtes SQL (1 par SGBD) (conséquence des multiples SGBD) - soit je développe tranquillement via JPA, qui possède plusieurs implémentation, et qui peut interagir avec divers SGBD.
- Edité par Pinguet62 17 juillet 2015 à 15:24:46
Angular 2 est l'avenir, jQuery c'est de la merde !!! - Java 8 c'est l'an 2016+ (programmez en 1 ligne)
1 seule implémentation c'est mieux ? Je te citerai la SNCF comme exemple. Pourquoi c'est la merde ? parce qu'ils n'ont pas de concurrence donc ils se contentent du minimum.
Bien-sûr, d'où le fait d'avoir précisé implémentation "libre". Il me semble que du coup, ce genre de problème est moins fréquents.
Je ne vais pas répondre à ton message en entier car nous sommes d'accord sur le principe.
Juste pour préciser. Je n'ai pas dis que plusieurs implémentation était de la merde. Loin de là.
Ce que je voulais en répondant à mfabrice64, c'était faire contre-poids de l'avantage en présentant non pas que les bons cotés mais également les mauvais.
Pinguet62 a écrit:
Dans les 2 cas il y aura des avantages et des inconvénients.
Voila tout est dis ...
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles- ♡ Copying is an act of love.
Je ne travaille pas à la SNCF ni n'ait de part dans cette entreprise, mais quand même, faut arrêter de leur taper dessus au bout d'un moment.
Pour te répondre mfabrice74 :
7 : non non non et non, pour la dernière fois, C et C++ sont deux langages différents, tellement différents qu'en C++, on a un mécanisme appelé RAII qui évite les fuites mémoires tout en étant plus efficace qu'un garbagge collector.
10 : l'indice TIOBE ne veut rien dire et est totalement inutile.
Clair. Il y a bien 20 ans qu'on sait faire du C++ sans s'occuper de la mémoire et bien 10 ans qu'on hurle à pleins poumons sur les gens qui pensent le contraire et il y en a toujours pour penser que ce n'est pas le cas.
Accessoirement, mis à part le point sur le GC et le point sur la communauté, le reste est également respecté par une vaste variété de langages.
Sur le point du GC, c'est surtout une question de choix. Typiquement en C++ pas de GC et pourtant dans 99.9% des cas, rien à faire à la main. Sans compter le fait qu'il y a des domaines où tu ne peux juste pas avoir de GC.
Sur le point de la communauté, grande communauté ne signifie pas communauté d'experts. Si l'on fait le lien avec l'orienté objet, combien de développeurs qui se targuent de faire de l'OO ne savent même pas ce que sont SOLID et Demeter ? Et sur ceux qui le savent combien essaie ne serait-ce que de l'appliquer un minimum ? Réponse : pas lourd. Et je ne vise pas que les dévs Java, qu'on soit clairs.
@@ache les liens que tu donnes datent tout de même de janvier 2011, l'implémentation d'Oracle JDK et OpenJDK est censé à être le même d'ici quelques années (ne serait-ce que pour des raisons de maintenance je pense).
@Ksass` Est-ce que les concepts de SOLID et Demeter font parti du programme pour que les gens en soient au courant ? Combien de lien sur internet montre les langages qui appliquent ces concepts et une comparaison entre ces différents concepts via des exemples (code) ? Pourquoi la POO écrase les autres concepts aujourd'hui ?
@Ksass` (1) Est-ce que les concepts de SOLID et Demeter font parti du programme pour que les gens en soient au courant ? (2) Combien de lien sur internet montre les langages qui appliquent ces concepts et une comparaison entre ces différents concepts via des exemples (code) ? (3) Pourquoi la POO écrase les autres concepts aujourd'hui ?
(1) SOLID je l'ai vu une première fois quand j'étais en IUT. Demeter je l'ai appris plus tard mais il est aussi important pour avoir du code maintenable et évolutif. Mais, non, ça fait rarement parti des formations. Et c'est pas un hasard, les formations sont justement souvent très en retard sur ce qu'on sait effectivement faire. Typiquement tu prends l''enseignement de C++, dans la majorité des formations, c'est du grand n'importe quoi.
Après bien sûr il y a l'autre partie : les vieux de la vieilles "qui ont toujours fait comme ça, et puis ça marche pas mal, et puis j'en sais plus que toi parce que je suis dans le métier depuis plus longtemps donc c'est moi qui ai raison". Du coup la programmation orientée objet c'est souvent, je met tout privé, et puis je met des getters et des setters (donc je décapsule tout et je n'abstrais pas la résolution du problème). Bref ça ressemble à du C où les structures seraient un tout petit poil plus intelligentes mais certainement pas aussi intelligentes que le voudrait l'objet.
A noter d'ailleurs que pas mal de bouquins d'UML propagent justement ce genre de trucs alors qu'ils se veulent enseignants d'une méthode pour avoir des conceptions robustes, un comble. On attendrait de ces bouquins qu'ils se reposent sur les formalisations (au sens mathématique) récentes d'UML, mais non.
(2) Des liens qui expliquent l'importance, de manière surprenante, il y en a pas mal en fait, à condition de chercher au bon endroit et d'avoir déjà des pointeurs. Mais pour ce qui est des codes qui montrent leur application, c'est un peu problématique puisque cela se passe plus au niveau de l'organisation, de la conception et de l'architecture. Le bouquin de @koala01 en parle plutôt bien, avec des exemples de codes, mais ça reste relativement rare.
La notion d'invariant d'objet et l'implication de la relation d'héritage sur ces invariants est globalement assez incomprise.
(3) La POO écrase de moins en moins les autres paradigmes ces dernières années. Et c'est tant mieux. Le mono-paradigme c'est un excellent moyen de se limiter. Mais la raison pour laquelle la POO est ultra répandu est certainement l'omni-présence de Java suite au phénomène de mode qui a accompagné son arrivée (après la percée de l'OO avec SmallTalk).
C'est intéressant de savoir qu'il existe d'autres paradigme (de tête j'avais la POO par prototype du JS), mais si c'est pour rester dans le domaine de la théorie ce n'est pas très vendeur, si je ne peux pas avoir d'exemple concret je ne pourrais pas me faire une idée sur ces concepts (aussi intéressants soient-t-ils).
Ne pas être orienté objet (ex: en C) est une limitation, en Java tu peux toujours créer une classe Global avec des méthodes static, puis faire un import static : tu obtiendras le même paradigme qu'en C, l'inverse n'est pas vrai. Java a prit un peu de temps pour implémenter les lambdas par exemple mais on pouvait déjà créer des classes anonymes en Java depuis la version 1.1, c'est quelque chose qui revient à la mode : PHP7 et Ecmascript 6 vont l'implémenter. Comme quoi on n'est pas si limité que ça finalement... sauf si tu penses le contraire.
C'est intéressant de savoir qu'il existe d'autres paradigme (de tête j'avais la POO par prototype du JS), mais si c'est pour rester dans le domaine de la théorie ce n'est pas très vendeur, si je ne peux pas avoir d'exemple concret je ne pourrais pas me faire une idée sur ces concepts (aussi intéressants soient-t-ils).
Il n'y a pas besoin de chercher bien loin pour comprendre l'intérêt de ces concepts.
SRP : principe de responsabilité unique. Une classe à une responsabilité précise. Si une classe a plusieurs responsabilités, on augmente les chances que l'une vienne tirer dans les pattes de l'autre. Cela rend également la maintenance plus difficile puisque lorsqu'une fonctionnalité bug, il va falloir regarder tout le code de la classe y compris celui qui n'a rien à voir. De plus, quand une classe a déjà plusieurs responsabilités, le programmeur a moins de scrupules et à en ajouter encore et encore, amplifiant progressivement les problèmes précédents.
OCP : principe ouvert/fermé. Une classe doit être ouverte à l'extension, fermée aux modifications. Pourquoi on ferme la classe aux modifications ? Parce qu'une fois que son fonctionnement a été validé, toute modification de son code est une chance de péter quelque chose par inadvertance. L'exemple typique de la classe qui n'est pas fermé aux modifications, c'est celle qui va caster des objets d'une hiérarchie de son type de base vers des types dérivés, il suffit qu'on ajoute une classe à la hiérarchie pour devoir aller mettre à jour les fonctions en question et risquer de péter des trucs (en plus de se prendre la tête à trouver toutes les fonctions qui faisaient ce genre de cast crado). Pour autant, on a envie de pouvoir ajouter des fonctionnalités ( != responsabilités) à nos classes. On le fera alors par extension.
LSP : principe de substitution de Liskov. Celui-ci est probablement le plus important. Et on peut faire un exemple très simple pour expliquer pourquoi. Il nous dit que si B dérive de A alors B doit respecter toute les propriétés de A. Cela inclut donc, avoir un invariant au moins aussi restrictif. Accepter en entrée de fonction, autant sinon plus d'entrée, renvoyer aux sorties de fonctions au maximum ce que renvoyait A. Une longue explication avec un exemple là : https://openclassrooms.com/forum/sujet/template-et-polymorphisme#message-88045425 .
ISP : La ségrégation des interfaces. Mieux vaut séparer les interfaces en petits blocs simples que faire une grosse interface avec beaucoup de fonctions. C'est le SRP qu'on applique aux interfaces en fait. Un exemple simple, c'est les widgets d'une interface graphique, tu vas en avoir des cliquable (I), des modifiables (I), des activables/désactivables (I), etc.
DIP : inversion des dépendances. Il faut dépendre des abstractions et pas des implémentations. Si de l'extérieur, on dépend de l'implémentation de la classe et pas uniquement de son interface (ou alors que son interface a été mal designée), la modification de l'implémentation de cette classe va potentiellement péter le fonctionnement du code appelant. C'est par exemple un des problèmes que pose le couple getter/setter : on dépend complètement des variables internes de la classe : on n'a rien abstrait.
Pour la loi de Demeter, elle nous dit simplement qu'on n'a le droit de dialoguer qu'avec nos voisins directs. Donc soi-même, nos attributs, nos paramètres en entrée de fonction, nos variables locales. Si on respecte pas ça, généralement, on a de l'appel chaîné qui se crée à base de get().get().get().faireUnTruc(). Le résultat c'est que les accès deviennent rapidement tentaculaires et très difficile à tracer.
Toutes ces notions n'ont qu'un objectif, faciliter l'extension et la maintenance (en premier lieu d'ailleurs), on est loin d'un truc théorique. Et ces règles sont loin d'être inapplicables. Après, le propre du bon développeur, c'est de savoir quand il est acceptable de les briser (sauf le LSP).
Gugelhupf a écrit:
Ne pas être orienté objet (ex: en C) est une limitation, en Java tu peux toujours créer une classe Global avec des méthodes static, puis faire un import static : tu obtiendras le même paradigme qu'en C, l'inverse n'est pas vrai. [...] C'est des techniques de conception.
Ne pas avoir un vrai paradigme générique est aussi une vraie limitation (quand le paradigme générique est implémenté par du casting derrière, non ce n'est pas un vrai paradigme générique), en C++ il est encore trop limité parce qu'il n'est typé qu'à l'instanciation. Un exemple concret de conception bien plus flexible que ce qu'on peut faire en OO c'est les algos de la SL C++, c'est pas du tout OO et c'est hyper bien fichu.
L'intégration des lambdas et des fonctions de second ordre c'est justement une ouverture à la programmation fonctionnelle, mais il faut bien comprendre que par là, Java ne se limite plus à l'OO. Java n'a jamais été un langage complètement OO et il l'est de moins en moins. Et c'est pas dommage, se limiter à un seul paradigme c'est une vraie barrière qu'on s'impose (surtout quand on bride le paradigme lui même). Mais même comme ça, on est très loin de ce que peuvent faire les langages fonctionnels avec le pattern-matching, l'inférence de type qui est généralement profondément ancrée, etc.
Et là, je ne suis que dans les paradigmes majeurs, mais un autre élément d'importance pour la création de logiciels robustes, c'est la programmation par contrat, et dans la majorité des langages, il n'y a rien pour écrire directement son contrat et laisser le compilateur poser les vérification. On peut parler de la programmation concurrente, qui est généralement intégrée sous la forme de bibliothèques et pas comme base du langage (et souvent les techniques enseignées date de Mathusalem). Etc.
Merci pour ces définitions Ksass`, à vrai dire je n'ai pas vu de chose très contradictoire avec Java. S'il y en a, n'hésite pas à me montrer des petits exemples avec du code.
"Java c'est de la merde parce que la généricité est géré à base de cast, bouh les nuls, vive le C++ qui le fait mieux" mouè, si on pouvait comparer 2 langages par ce simple argument ça serait facile. En plus cet argument vise à critiquer l'implémentation du langage, et non son utilisation (point de vu du développeur). Donc on s'éloigne du sujet initial. A la limite il faudrait lister tous les concepts, et noter leur utilisation par le développeur, leur implémentation dans le langage, avec une pondération, ... pour évaluer globalement le langage par rapport aux autres.
Gugelhupf a écrit:
C'est intéressant de savoir qu'il existe d'autres paradigme [...], mais si c'est pour rester dans le domaine de la théorie ce n'est pas très vendeur
Ces concepts n'ont pas vraiment de lien avec le langage, mais plutôt avec la façon dont développera le programmeur. Mais j'y jetterai un œil car cela semble intéressant.
Ksass`Peuk a écrit:
Pinguet62 a écrit:
J'avoue, Java c'est vraiment de la merde !
Faudra que tu m'expliques ce que tu as pris (parce que j'en veux aussi) pour trouver cette conclusion dans ce que j'ai raconté
Les débats entre Java et .NET on commencé il y a des années et ne sont toujours pas fini. Les débats entre Java/.NET et C++ non plus. En plus ils n'ont aucun sens : c'est comme comparer une berline et un 4x4 (les crossover s'en sortent plus ou moins bien, cumulant les avantages ou les inconvénients des 2 en fonction du point de vu).
Les conclusions seront : il n'y a pas de super langage. Chacun a ses limitations et avantages dans certains domaines.
- Edité par Pinguet62 20 juillet 2015 à 14:11:12
Angular 2 est l'avenir, jQuery c'est de la merde !!! - Java 8 c'est l'an 2016+ (programmez en 1 ligne)
"Java c'est de la merde parce que la généricité est géré à base de cast, bouh les nuls, vive le C++ qui le fait mieux" mouè, si on pouvait comparer 2 langages par ce simple argument ça serait facile.
Non, c'est sûr, c'est qu'un exemple parmi tant d'autres. La généricité de C++ est un poil mieux foutue qu'en Java, mais elle est pourrie à chier par rapport à Ocaml ou Haskell. C'est qu'un exemple pour montrer que certains paradigmes sont mieux ancrés dans un langage ou dans un autre et que la présence ou non de ces paradigmes permet ou pas des choses au développeur.
Quand je parle de se limiter à des paradigmes, je ne parle pas nécessairement de Java. C'est vrai pour tout langage (voir pour tout développeur : on peut faire du Ocaml en se limitant au fonctionnel pur mais on ne tirera pas parti du toute la puissance du langage). Le pendant inverse, c'est que quand on veut intégrer trop vite tout ce qui est possible et imaginable, sans essayer de créer une cohérence globale, ça donne la norme C++ que personne ne comprend même pas les gens qui l'ont écrite et qui a pour résultat d'être enseigné n'importe comment.
Pinguet62 a écrit:
En plus cet argument vise à critiquer l'implémentation du langage, et non son utilisation (point de vu du développeur). Donc on s'éloigne du sujet initial.
C'est pas faux. Je ne sais pas comment c'est précisé dans la norme Java.
Pinguet62 a écrit:
Les débats entre Java et .NET on commencé il y a des années et ne sont toujours pas fini.
Les débats entre Java/.NET et C++ non plus. En plus ils n'ont aucun sens : c'est comme comparer une berline et un 4x4 (les crossover s'en sortent plus ou moins bien, cumulant les avantages ou les inconvénients des 2 en fonction du point de vu).
Complètement. Mais ici, je vise le débat mono-paradigme VS multi-paradigme. C'est plus général et à mon sens, le second est très largement préférable. C++ a fait ce choix il y a longtemps, Java a commencé avec la généricité et continue à intégrer d'autres paradigmes, C# aussi. Bref, je ne crois pas que se cantonner à l'objet soit un bon choix, ni que l'objet soit le paradigme qui permette le plus de choses.
Gugelhupf a écrit:
Merci pour ces définitions Ksass`, à vrai dire je n'ai pas vu de chose très contradictoire avec Java. S'il y en a, n'hésite pas à me montrer des petits exemples avec du code.
Il n'y en a pas . Dans certaines vieilles versions de Java il y avait des défauts qui y étaient liés (là je parle vraiment de mémoire). SortedList qui héritait de List ou un truc du genre (que les Java-istes confirment), ce qui viole le LSP. Ce genre de défauts ont été corrigés depuis pas mal de temps.
Rien ne s'oppose à respecter SOLID et Demeter en Java. Ni dans n'importe quelle langage intégrant l'OO d'ailleurs.
Merci pour ces définitions Ksass`, à vrai dire je n'ai pas vu de chose très contradictoire avec Java. S'il y en a, n'hésite pas à me montrer des petits exemples avec du code.
C'est pas à proprement parlé une chose très contradictoire mais plutôt une subtilité. C'est assez facile de comprendre pourquoi.
/* Normal cases */
Integer i = new Integer(1);
Integer iC = new Integer(1);
assertFalse(i == iC);
assertTrue(i == 1);
assertTrue(i.equals(1));
Integer i2 = 1;
Integer i2C = 1;
// WTF!!
assertTrue(i2 == i2C);
assertTrue(i2 == 1);
assertTrue(i2.equals(1));
@max-om-93 : j'avais déjà vu cet exemple. Je l'aime bien. Il est lié à l'implémentation, ou est-ce un bug de la norme, ou est-ce autorisé par la norme pour de bonnes raisons ?
Après, je ne trouve pas que ce soit complètement en rapport à avec ce que j'ai dit (à part le côté tout objet, pas vraiment tout objet).
@max-om-93 : j'avais déjà vu cet exemple. Je l'aime bien. Il est lié à l'implémentation, ou est-ce un bug de la norme, ou est-ce autorisé par la norme pour de bonnes raisons ?
Après, je ne trouve pas que ce soit complètement en rapport à avec ce que j'ai dit (à part le côté tout objet, pas vraiment tout objet).
Non non rien à voir avec ce que tu disais. Je rebondissais sur le post de Gugelhupf
Ce n'est en aucun cas lié à l'implémentation ou un bug, c'est quelque chose qui a été souhaité. Il y a la présence d'un cache pour les intégers compris entre -128 et 128. Si tu ne spécifie pas explicitement que tu as besoin d'une nouvelle instance, tu auras toujours la même pour une même valeur.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles - ♡ Copying is an act of love.
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles - ♡ Copying is an act of love.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Mon projet: SpotRoom. N'hésites pas à passer dire ce que tu en penses !
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles - ♡ Copying is an act of love.
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles - ♡ Copying is an act of love.
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles - ♡ Copying is an act of love.
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles - ♡ Copying is an act of love.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles - ♡ Copying is an act of love.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C