[F] [mOved] Mon langage est mieux que le tien - Page 58

Uther (./1710) :

Tout un article plein d'alarmisme, et quelques paragraphes finaux qui disent qu'en fait, rien ne va changer. Et puis ça ne concerne que Java EE, pas Java lui-même (Java SE).

Le problème c'est que depuis quelques années c'est JavaEE, qui maintient Java :
- JavaME a juste disparu depuis l'avènement de iOS et d'Android.
- Java SE pour les applets n'a jamais décollé est il est désormais complètement marginalisé suite aux problèmes de sécurité. Maintenant le HTML5/JavaScript permet de réaliser la plupart des choses que permetaient les Applets, sans plugins.- JavaSE pour les applications desktop reste anecdotique, et Oracle ne fait plus trop d'efforts dessus depuis quelques années.

Les implémentations libres de Java EE sont très connues et s'en sortiront très bien même dans l'éventualité où ils devraient arrêter de s'appeler "Java EE".

La seule implémentation Libre vraiment bonne de est OpenJDK qui est totalement contrôlée par Oracle, et la seule qui aurait pu lui faire de l'ombre était Harmony, que Oracle a justement condamné a mort.

Le soucis des implémentations libres, c'est que Oracle garde une épée de Damoclès dessus. En effet, il reste maitre du kit de certification Java qui lui est tout sauf libre. Oracle en est le seul maitre et il y accorde l'accès de manière tout a fait discriminatoire. C'est comme cela qu'il a signé l'arrêt de mort du projet Apache Harmony qui n'a pas pu être certifié et donc été abandonné par son plus gros controbuteur IBM, car ça mettait les utilisateurs à la merci des brevets de Sun/Oracle.

Il y a certes l'OpenJDK, mais pour y contribuer, il faut céder la propriété du code a Oracle qui l'utilisera pour sa version propriétaire.
Par contre si on forke, on retrouve à nouveau dans la situation de Harmony : on ne sera probablement jamais certifié et on est donc exposé a une attaque en justice d'Oracle, ce qui est dissuasif pour toute entreprise sérieuse.Bref c'est de la GPL, mais pas vraiment libre pour autant

Godzil (./1712) :
Haaaa si java pouvais disparaitre, le monde s'en porterais tellement mieux!

Godzil (./1716) :
pas encombré d'une boite de merde et de brevets

De nombreuses applications Java développées dans les entreprises sont du Java SE. Ce n'est pas parce qu'on est une entreprise qu'on a forcément besoin de l'EE. Et quand on fait du Java EE, on fait du Tomcat/TomEE, du JBoss, etc., et on s'en fout s'il y a écrit "Java EE" dessus ou non. Et personne n'utilise l'intégralité de Java EE, on n'utilise que les morceaux intéressants, par exemple: les servlets web (Tomcat ou équivalent), la persistence JPA (Hibernate, développé par l'équipe de JBoss), etc.

Oracle n'a aucune chance en justice si le travail est une œuvre dérivée de code qu'ils ont publié sous GPL. La GPL permet explicitement d'utiliser les brevets que détient l'auteur qui a placé le code sous GPL quand le code sous GPL les utilise.

        QFileInfo finfo(dlg.sound());
        QString name = finfo.completeBaseName();
        QTableWidgetItem* item = new QTableWidgetItem(name);
        ui->tableTimers->setItem(row, COLUMN_SOUND, item);

On sait que derrière tout troll se cache une vérité, et en l'occurence, j'aimerais savoir ce que vous en pensez à l'usage, en tant que pro, pour ajouter ça à mon catalogue de bonnes pratiques, tout simplement.

Godzil (./1726) :
myMarvelousButton.setBGColor(myTheme.btn.bg.red(), myTheme.btn.bg.red(), theme.btn.bg.red());
par exemple est tout a fait acceptable

Godzil (./1712) :
Haaaa si java pouvais disparaitre, le monde s'en porterais tellement mieux!

[b]Godzil (./1716) : le java a toujours été une boite a emmerdes que ca soit a travers les innombrables trous de sécurité, conso mémoire, CPU etc.. Au point qu'une application poussé en java comme Minecraft est incapable de tourner sur des machines récente mais peu puissante, alors que les "clones" écrit dans un vrai language eux tournent très bien sur cette meme machine, avec pourtant des fonctionnalité similaires.[/spoiler]

ui->tableTimers->setItem(
	row,
	COLUMN_SOUND,
	new QTableWidgetItem( QFileInfo( dlg->sound() ).completeBaseName() )
);

Folco (./1722) :
Pour donner un exemple, préférez-vous lire ça :

        QFileInfo finfo(dlg.sound());
        QString name = finfo.completeBaseName();
        QTableWidgetItem* item = new QTableWidgetItem(name);
        ui->tableTimers->setItem(row, COLUMN_SOUND, item);

me()));ou ça : ui->tableTimers->setItem(row, COLUMN_SOUND, new QTableWidgetItem(QFileInfo(dlg->sound()).completeBaseNa

Uther (./1728) :
Et personnellement s'il y a bien un langage omniprésent a faire disparaître en priorité, je dirais qu'il s'agit du C++.

robinHood (./1730) :
> ou pensez-vous qu'il y ait un juste milieu ?

ui->tableTimers->setItem(
	row,
	COLUMN_SOUND,
	new QTableWidgetItem( QFileInfo( dlg->sound() ).completeBaseName() )
);

Folco (./1734) :
Ok, merci Godzil et tous les autres.

robinHood (./1730) :
> ou pensez-vous qu'il y ait un juste milieu ?

ui->tableTimers->setItem(
	row,
	COLUMN_SOUND,
	new QTableWidgetItem( QFileInfo( dlg->sound() ).completeBaseName() )
);

C'est le juste milieux côté inconvénient ça ? Le code prend de la place, et toujours pas de breakpoint/watch dans cette instruction

Kevin Kofler (./1732) :
Nooooon!!! Faire disparaître la STL et la remplacer par Qt serait une bonne idée, mais le langage C++ en lui-même est très bien.

Godzil (./1733) :
Pour Minecraft je ne suis pas vraiment d'accord, c'est je trouve un tres bon exemple, et je doute que le jeu soit si mal optimisé, ca fait des années que Mojang travail a l'optimisation de ce jeu dans la version Java, et avec un succes relatif. La ou les version dn C/C++ qu'on retrouve sur les iOS/Android/Windows 10 et les version consoles n'ont pas ces problemes de performances.

Godzil (./1733) :
C'est pour moi un bon exemple du fait que Java n'est pas vraiment adapté a ce genre d'application, car entre l'allocation mémoire, et les problèmes de lenteurs avec le binding natif font que ce n'est vraimetn pas l'idéal pour un jeu qui utilise de maniere intensive les resources de ta machine. L'exemple est tres parlant si tu alloue la valeur par defaut pour le pool mémoire dans ce jeu (512M) des que le jeu arrive a 100% de mémoire consommé et cherche a allouer des objets en plus, tu te mange des putain de ralentissement. Des que tu augmente (en relancant bien sur parceque la VM java est vraimetn bien foutut avec ca...) tu n'a plus ces ralentissements du au GC.

Godzil (./1733) :
Pour moi le fait que java cherche a gerer entierement sa mémoire a sa sauce en forcant l'attribution d'un pool mémoire est une absurditée sans nom. Plutot que d'avoir la possibilité, comme n'importe quelle application native, d'acceder a toute la mémoire systeme au besoin, on va creer un pool d'une taille souvent ridicule par défaut.
Je suis bien d'accord pour le C++, sur le language a proprement parler le Java est probablement meilleurs que le foutoir qu'est le C++ (bonjour les templates!), mais par contre l'environnement du language et le fonctionnement de la VM, la foultitude de parametres a la con qu'on peux passer a la VM a l'instentiation est, je pense, une énorme erreur de conception du Java. Le .Net a mon sens est mieux foutut sur ce point, probablement pas parfait, mais bien mieux.

Uther (./1737) :

Kevin Kofler (./1732) :
Nooooon!!! Faire disparaître la STL et la remplacer par Qt serait une bonne idée, mais le langage C++ en lui-même est très bien.

Qt corrige certes une partie des défaut de C++ en apportant une bibliothèque vraiment agréable, du niveau de ce que propose Java. Mais ça reste un rafistolage d'une construction pourrie qui apporte encore plus de lourdeur a l'édifice avec ses "moc" qui viennent se rajouter a un système de header déjà horribles.

nitro (./1738) :
A la limite, on pourrait dire qu'il existe un sous-ensemble du C++ qui est presque bien.