Serveur minecraft

Peut-être que je me trompais sur Java – Monter un serveur MineCraft

Le 19 décembre 2019 - 29 minutes de lecture

Note de l'éditeur: Étant dans un canal Java, la plupart d'entre nous connaissent très bien le langage et sont dans son écosystème depuis au moins deux ans. Cela nous donne la routine et l'expertise mais induit également une certaine vision en tunnel. Dans une nouvelle série Java extérieur les non-Javaistes nous donneront leur point de vue sur notre écosystème.

Je ne suis pas le plus grand fan de Java. Je peux lire Java si nécessaire, et j'en ai écrit quelques-unes dans des situations d'urgence, mais je n'en ai pas l'habitude. J'en ai les mêmes impressions stéréotypées que beaucoup d'autres personnes non Java: c'est grand et lent et exclusivement écrit par des gens qui portent des cravates pendant la programmation.

Je suis peut-être mieux connu pour une déconstruction élaborée de PHP, mais cela est arrivé parce que PHP suscite une frustration unique en moi. Java inspire surtout, ah, l'ennui.

Mais attendez. PHP est populaire car il a un avantage singulier: il supprime quelques étapes du rituel cauchemardesque qu'est le développement web. Java n'a pas un énorme avantage comparable, donc il doit le faire quelque chose droite. Sinon, Oracle ne se vanterait pas des neuf milliards de périphériques exécutant Java. Cela n'alimenterait pas les tripes d'un nombre important de grands sites Web. Le système d'exploitation du smartphone dominant ne serait pas entièrement construit au-dessus. Je n'aurais pas de grille-pain exécutant une machine virtuelle Java. (Cela fonctionne mieux que vous ne le pensez! Il vous suffit d'attendre un peu qu'il se réchauffe.)

Alors peut-être – peut être – J'ai tout faux Java. J'ai peut-être été injuste avec ça. Peut être.

Il serait peut-être temps de réexaminer mes notions préconçues sur Java. Pour briser certains mythes, si vous voulez.

Pour référence, j'ai tâté dans un certain nombre de langues, mais je fais surtout du Python et j'aime beaucoup de ses décisions de conception. Python a un petit chevauchement philosophique avec Java, c'est donc un point de comparaison intéressant.

Java est lent

Java définitivement se sent gros et lent pour moi. Le mot est comme de la mélasse dans mon cerveau. Quand je pense à Java, je me souviens des très rares rencontres que j'ai eues avec lui sur le bureau. Azureus, le client Java BitTorrent que tout le monde utilisait pour télécharger les versions d'Ubuntu il y a plus de dix ans, est peut-être le plus tristement célèbre. C'était étonnamment lent étant donné que tout ce qu'il a fait était de télécharger des fichiers, et tout le monde a sauté sur µTorrent quand il est sorti. µTorrent est bien sûr écrit en C ++, ce qui le rend plus rapide et plus performant.

Le truc, c'est que ça n'a aucun sens. Le seul client BitTorrent que j'utilise depuis des années est Deluge, qui est écrit en Python. (C) Python n'est certainement pas aussi rapide que Java, mais Deluge a toujours été accrocheur pour moi. La JVM est utilisée en partie parce qu'elle est assez rapide, alors d'où vient cette association avec la lenteur?

Autant que nous aimerions penser le contraire, il est difficile de faire de vraies mesures ici; tant de facteurs affectent la vitesse que même l'analyse comparative d'un seul programme par rapport à lui-même n'est pas fiable, sans parler de comparer deux logiciels complètement différents. La machine s'est-elle enlisée à faire autre chose? Le GC est-il intervenu à un moment inopportun? Une langue est-elle meilleure pour une tâche particulière? Suis-je en train d'utiliser une mauvaise JVM? Une application est-elle mieux écrite que l'autre? Même si je pouvais contrôler tous ces facteurs, il est toujours difficile de mesurer la la perception de vitesse, c'est de cela qu'il s'agit vraiment. Le mieux que je puisse faire est d'y réfléchir.

Programmes lents, langage lent

Et je soupçonne un peu de biais de confirmation ici. Si un programme est lent, nous blâmons le programme – mais si un Java le programme est lent, nous blâmons Java. Java est même particulièrement désavantagé ici; il est facile de remarquer qu'un programme GUI est écrit en Java, puisque Swing ressort comme un pouce endolori, mais plus difficile d'être sûr qu'il est écrit en C ++ ou similaire.

D'après mon expérience, cela est particulièrement visible dans les cercles de jeu, où vous pouvez trouver des informations approfondies sur les performances de jeu de personnes qui n'ont jamais écrit de ligne de code. Minecraft est lent parce qu'il est écrit en Java, vous voyez, tandis que Starbound est lent parce que les développeurs ne l'ont pas "optimisé". Quoi que cela signifie.

Un autre facteur possible, bien que je ne sache pas à quel point cela est vrai: j'ai l'impression que de nombreux développeurs écrivent C ++ parce qu'ils le veulent, mais écrivent Java quand ils le doivent? J'ai rencontré beaucoup de code C ++ qui n'a aucune raison impérieuse d'être écrit en C ++, mais beaucoup de code Java avec une histoire qui commence "nous avons écrit cela avec Rails et l'avons porté quand il est devenu trop lent". (Ou «c'est pour Android, nous avons donc dû le faire».) En d'autres termes, Java semble être un outil commun pour accélérer le code qui est déjà trop lent, donc tout programme Java donné est raisonnablement susceptible de faire de très gros travaux. Ce n'est pas que Java est lent; c'est que les programmes lents ont tendance à être écrits en Java. Un problème d'auto-sélection.

Pendant ce temps, une grande partie du C ++ est écrite uniquement par dépit. Ou plutôt, il y a un sous-ensemble de programmeurs qui sont obsédés par des performances maximales et qui atteindront C ++ s'ils en ont besoin ou non, parce qu'être contre le «métal nu» leur donne des flous chaleureux et vaut totalement le risque de fausses erreurs de segmentation et de mémoire. Donc, un programme C ++ donné n'est pas nécessairement susceptible de faire le genre de travail intensif qui justifierait l'utilisation de C ++.

Le JIT est-il en faute?

J'étais à l'origine tenté de blâmer une partie de la lenteur perçue sur l'échauffement JIT, mais je ne suis pas sûr que ce soit probable. J'ai moi-même commencé à expérimenter l'échauffement JIT plus fréquemment, car j'utilise davantage PyPy. PyPy est une implémentation JITted Python (écrite en elle-même, d'où le nom), et l'un des grands obstacles à une adoption plus large est qu'il faut quelques secondes pour s'échauffer. Les programmes Python qui s'exécutent plus ou moins instantanément avec le stock Python entraînent un retard notable lorsqu'ils sont exécutés avec PyPy – et puisque Python est couramment utilisé pour les outils de ligne de commande, ce retard affecte de nombreux programmes.

Mais pour tout ce qui prend plus d'une demi-minute à courir, PyPy est beaucoup plus rapide. Je m'attendrais à ce qu'une JVM ait un JIT beaucoup plus avancé que le relativement jeune de PyPy, donc le temps de préchauffage serait sûrement encore plus court. Je doute que Java ait la réputation d'être lent simplement parce qu'il flanche un peu dans les vingt ou trente premières secondes.

J'ai également regardé l'échauffement JIT se produire en temps réel avec LÖVE, un moteur de jeu qui utilise LuaJIT. Si vous dessinez la fréquence d'images à l'écran, vous pouvez regarder il commence vers 10 et monte jusqu'à 60 en quelques secondes. Après cela, ça fonctionne bien. Encore une fois, le ralentissement est assez bref et cela ne m'a jamais donné l'impression que le moteur ou le JIT dans son ensemble est lent.

Java en tant que jouet

Je suis prêt à parier qu'il s'agit en grande partie de ragots datant de la première sortie de Java. Certains développeurs C ++ auraient sûrement perçu Java comme une réinvention du C ++ qui était comiquement lent… par rapport à C ++. La JVM Sun originale n’avait pas de JIT depuis plusieurs années, donc très tôt Java a été interprété comme la plupart des Python – mais sur un matériel beaucoup plus lent.

Cela a également un sens d'un point de vue culturel. Java a été présenté comme un langage «sérieux» – c'est-à-dire un concurrent du C ++ – à une époque où le seul langage «sérieux» était, euh, le C ++. Tout ce qui sentait même une langue interprétée était largement considéré comme un jouet. Encore plus que maintenant, je veux dire. Si l'éventail complet des «langages que quiconque utiliserait pour un développement sérieux» variait du C ++ à Java, bien sûr Java ressemblerait à une bête de somme. Collecte automatique des déchets? Que faites-vous, une sorte de bébé? Je parie que votre langue ne peut même pas se tromper.

Avance rapide de vingt ans, et la moitié de mon système d'exploitation est écrit en JavaScript. J'ai même écrit une fois une application de bureau en Perl (yolo). Au moins, Java est meilleur en comparaison?

Java est gonflé

Je n'aime pas le mot "ballonnement". Cela ne veut rien dire. Ou, plutôt, cela signifie «des trucs je ne vous souciez pas ", ce qui n'est pas une critique utile.

Une fois, quelqu'un m'a dit simultanément ⓐ qu'ils n'utilisaient pas GIMP pour les illustrations parce qu'il était gonflé et ⓑ ils étaient frustrés par le Paint.NET beaucoup plus simple car il manquait une fonction de puissance obscure dont ils avaient besoin … dont GIMP dispose.

Dans un souci de précision, voici certaines choses que «ballonnement» pourrait vouloir dire.

Les programmes Java utilisent beaucoup de mémoire

Toute mention de l'utilisation de la mémoire de Java me rappelle un conte de quand je travaillais chez $ TECHCOMPANY. J'étais responsable de l'entretien et de l'alimentation de notre système de construction, qui utilisait Closure Compiler, un «compilateur» JavaScript vers JavaScript écrit en Java.

Le système de construction a exécuté Closure comme java -Xmx1024M ..., qui définit la taille maximale du segment de mémoire sur 1 Go. Lorsque j'appelais Closure manuellement, j'oublierais parfois -Xmx commutateur, et la JVM serait instantanément en flammes. Plus tard, j'ai découvert le quelque peu obscur _JAVA_OPTIONS variable d'environnement, ce qui m'a évité d'avoir à m'en souvenir à nouveau, mais le mystère est resté. Quand j'ai fini par m'y intéresser, j'ai trouvé un choc d'intentions fascinant.

Nous avons utilisé des machines de développement partagées, chacune avec 64 Go. Nous avions un ulimit -v de 5 Go, ce qui a empêché tout processus d'allouer plus que cela. Par défaut, notre JVM a tenté d'allouer un quart de la RAM physique de la machine au démarrage – 16 Go. L'allocation a échoué, la JVM s'est donc arrêtée immédiatement. (La documentation a suggéré que le tas ne devrait pas dépasser 1 Go par défaut, mais il semble incorrect.)

Ce n'est pas une chose totalement déraisonnable pour la JVM. Linux distribuera volontiers de grandes allocations qu'il n'a pas réellement, et tant que les processus n'essaient pas de utilisation toute cette mémoire, tout fonctionne bien. La machine virtuelle Java en a profité pour allouer un énorme bloc à l'avance, évitant ainsi la nécessité de beaucoup d'allocations (lentes) plus tard. le ulimit était une heuristique grossière pour empêcher les processus d'emballement d'embourber la machine, mais elle en limitait un nombre qui ne voulait rien dire. (Hélas, ulimit -m – qui est censé limiter l'utilisation réelle de la mémoire – n'a pas fonctionné depuis Linux 2.4.)

Dans ma tête, cette histoire est «cette fois où Java voulait 16 Go». Injuste, je sais, mais il résonne avec un vague sentiment que Java est généralement connu comme un porc de mémoire. Même Java lui-même semble penser qu'il pourrait avoir besoin d'autant de mémoire. Pourtant, si je regarde au-delà du stéréotype, je ne peux pas trouver un béton désinvolture raison pour laquelle ce serait le cas.

Je peux imaginer que la plupart des facteurs de vitesse s’appliquent également ici: Java est blâmé quand un programme Java est gros, mais C ++ n’est pas blâmé quand un programme C ++ est gros; les grosses tâches ont tendance à finir écrites en Java; Les développeurs C ++ qui hyperoptimisent peuvent se moquer de la récupération de place et de la surcharge par objet.

Ah, mais bien que la vitesse soit difficile à quantifier même pour un seul programme, la taille est beaucoup plus déterministe. La même valeur du même type prendra généralement la même quantité d'espace d'une exécution à l'autre. Je sais qu'un objet CPython a 16 octets de surcharge, par exemple – un pointeur de type et un refcount. Je suis moins sûr de la surcharge des objets en Java – l'utilisation exacte de la mémoire est traitée comme un détail d'implémentation de la machine virtuelle, et Java a plusieurs machines virtuelles concurrentes en usage courant. (Je ne connais CPython qu'en lisant le code source, que je connais déjà.) Mais je doute sérieusement que n'importe quelle JVM ait besoin de plus de surcharge d'objets que Python, et dans certains cas, cela devrait en nécessiter beaucoup moins – Python n'a pas de primitives sans boîte . En fin de compte, Java ne devrait pas être bien pire que Python, et je ne pense pas à Python comme un porc de mémoire, donc je ne devrais certainement pas penser à Java comme tel.

Fake Science

Assez de spéculations. Si la taille est mesurable de manière plus fiable, faisons quelques mesures. Voici une comparaison terrible et non scientifique de l'utilisation initiale de la mémoire de quelques programmes de bureau choisis arbitrairement.

  • XMind (Java), un mind mapper: 416 Mo
  • yEd (Java), un éditeur de graphiques (comme dans les organigrammes, pas y = x²): 372 Mo
  • jDiskReport (Java), un rapport sur l'espace disque: 228 Mo
  • muCommander (Java), un navigateur de fichiers de style MC: 183 Mo
  • FreeMind (Java), un autre mind mapper: 181 Mo
  • SLADE (C ++ / wxWidgets), un éditeur de cartes Doom: 93 Mo
  • GIMP (C ++ / GTK), un éditeur d'images: 88 Mo
  • LMMS (C ++ / Qt), une station de travail audio numérique: 75 Mo
  • Deluge (Python / GTK), un client BitTorrent: 85 Mo

(Soit dit en passant, tous les programmes Java commencent avec au moins 11 Go virtuels – à l'exception de FreeMind, qui est livré avec un script shell qui ajoute -Xmx. Même un programme Java hello-world insignifiant alloue 10,5 Go pour moi, il semble donc que la taille de tas initiale par défaut soit toujours comiquement grande. J'ai 32 Go de mémoire physique, donc un quart serait de 8 Go; Je ne sais pas d'où viennent les valeurs de 10,5+ Go.)

Sensationnel. Je ne m'attendais pas à une telle différence, même en sachant que beaucoup de facteurs travaillent contre Java ici. GTK et Qt sont des bibliothèques partagées qui pourraient être partagées avec d'autres processus, et même une interface utilisateur Python enveloppe ces bibliothèques et stocke une grande partie de ses données au niveau C; Swing vit presque entièrement en Java et n'était utilisé que par le programme que j'avais ouvert. Java a bien sûr un runtime complet (qui semble prendre une ligne de base de 26 Mo), alors que le «runtime» C ++ est microscopique. Python a également un runtime, mais Deluge est un programme beaucoup plus simple que les autres; c'est juste la seule autre chose non C ++ que j'ai sous la main. Ou XMind et yEd pourraient simplement ne pas être représentatifs pour une autre raison.

Java (comme Python) doit également se souvenir de nombreuses informations de débogage qui sont généralement omises des programmes C ++ publiés, pour des raisons de réflexion et de traces de pile. La collecte des ordures a tendance à échanger la mémoire disponible contre la vitesse; Je ne sais pas en détail comment fonctionne le GC de ma JVM, mais j'ai vu des GC avec 100% de frais généraux ou plus, donc je ne serais pas surpris si cela était un facteur important ici. Je tiens à dire que GC a également des problèmes de fragmentation qui sont difficiles à résoudre.

Les chaînes de Java sont inutiles

Je soupçonne qu'un autre grand coupable est Java Chaîne type. Les chaînes Java sont «Unicode», dans le sens où «Unicode» a été défini dans les années 1990. Vous voyez, Unicode avait initialement promis qu'il n'aurait jamais plus de 65 536 caractères, donc deux octets suffiraient pour représenter quoi que ce soit. L'API Windows, au moins une boîte à outils GUI, Java, JavaScript (qui l'a probablement copié de Java), et d'autres pauvres âmes ont pris cela à cœur et ont déclaré que les chaînes utiliseraient toutes des caractères à deux octets. L'encodage des caractères a été résolu pour toujours.

Jusqu'à ce que Unicode soit allé "oups" et a promis qu'il n'aurait jamais plus de 1 114 111 caractères, donc Trois octets suffiraient à représenter quoi que ce soit, mais personne n'a un type entier à trois octets, alors arrondissons-le à quatre. Maintenant, Java est dans une position très délicate. Le texte ASCII prend deux fois plus d'espace qu'il n'en a réellement besoin. Mais un Java Chaîne ne peut pas représenter tous les caractères Unicode sans un autre mécanisme de codage, il est donc tout aussi possible d'écrire du code de gestion de texte bogué qui suppose que chaque caractère est un caractère réel. Le pire des deux mondes.

Les chaînes pourraient représenter une part importante de l'utilisation de la mémoire d'une interface graphique, avec la pléthore d'étiquettes et d'infobulles, auquel cas cela ferait une énorme différence. Je sais que les fichiers XML et de configuration sont également assez populaires dans le monde de Java, et ceux-ci produiraient naturellement des tonnes de chaînes. Je vois que Java 9 est configuré pour adopter un schéma plus compact, où les chaînes ASCII n'utiliseront de manière transparente qu'un octet par caractère sous le capot. Python est passé à un schéma similaire il y a plusieurs versions, et l'utilisation de la mémoire d'une application Django (Web) a chuté de 40% par rapport à une génération à deux octets. Java pourrait voir des améliorations comparables dans les programmes lourds en texte; un rapport sur l'impact sur une référence de serveur a révélé une amélioration de 21% de l'utilisation du segment de mémoire.

En clôture

Je suis allé là-dedans en m'attendant à trouver que Java était beaucoup plus compact que je ne le pensais, et… ce n'était pas le cas assez se produire. Même 228 Mo, ce n'est pas trop mal, mais 416 Mo, c'est un peu ridicule. Oh, j'ai accidentellement laissé YEd courir toute la nuit; il est passé à 854 Mo malgré ne rien faire, le plaçant à la troisième place derrière un programme artistique avec plusieurs grandes toiles ouvertes et mon navigateur avec plusieurs centaines d'onglets ouverts. Je ne sais pas ce que ça fait ni qui blâmer, mais ça n'a pas l'air bien. Il est intéressant de noter que FreeMind et XMind étaient respectivement les meilleurs et les pires, bien qu'ils soient du même genre de logiciel et écrits dans la même langue.

Maintenant, pour être un peu juste envers Java, je n'aurais honnêtement pas remarqué l'utilisation de la mémoire si je ne l'avais pas recherchée. je faire avoir 32 Go de RAM pour une raison. Et pourtant… mon téléphone entièrement basé sur Java a à peine 2 Go, et il semble gérer. Peut-être que je manque quelque chose ici. La diffusion des programmes Java est manifestement beaucoup plus large que celle des programmes C ++, et je ne sais pas pourquoi.

programmation-dans-une-cravate-mauvaise-sur-java

Je me sens hocher légèrement la tête en accord sans engagement avec cela, pendant que je regarde dans la pièce pour voir si quelqu'un d'autre pense que c'est vrai.

Le truc c'est que je n'ai aucune idée Pourquoi cela me semble raisonnable.

Le référentiel de packages Arch Linux est pratique ici, car il répertorie la taille installée pour chaque package. Mon vieil ami Closure Compiler fait 19,7 Mo. Hou la la! C'est beaucoup. Droite? Eh bien, peut-être pas. Le projet le plus similaire auquel je peux penser est Babel, qui compile le dernier ECMAScript en quelque chose de plus convivial, et il fait toujours 7,0 Mo. Le compilateur de fermeture peut faire une grande partie de ce que fait Babel, en plus il est construit plus comme un compilateur traditionnel, donc je ne suis pas surpris qu'il soit plus grand – au contraire, je suis surpris qu'il ne soit que deux fois plus gros. GCC, quant à lui, fait 116,1 Mo.

Il s'agit d'un moyen extrêmement peu fiable et non scientifique de mesurer la taille d'un logiciel. Mais il suffit que j’aie déjà de sérieux doutes sur ce point. Il est tentant de comparer certains logiciels de bureau antérieurs, mais même FreeMind et XMind – deux programmes Java qui servent à peu près le même objectif – ont des tailles installées très différentes de 27 Mo et 138 Mo, respectivement.

Je ne peux même pas penser à une anecdote qui expliquerait pourquoi je m'attends à ce que le logiciel Java soit gros. Je me demande si c'est parce que Java applets étaient relativement volumineux à l'époque où ils étaient populaires – lorsque beaucoup de gens utilisaient encore la connexion par ligne commutée.

Avant d'arrêter de choisir Closure Compiler, j'ai une autre interprétation de «l'empreinte du système de fichiers» – l'arrangement de fichiers source. La majeure partie du code source de Closure vit dans un répertoire de cinq niveaux de profondeur, ce qui semble légèrement extrême. Ce répertoire contient 347 .Java fichiers, ce qui semble également légèrement extrême. Beaucoup de ces fichiers semblent pourrait être regroupés en catégories sensibles, mais ils ne le sont pas.

La fermeture est peut-être une exception. GitHub me dit que le projet Java le plus étoilé est elasticsearch, dont le code réel est également enterré cinq niveaux plus bas. Je ne vois aucun répertoire contenant autant de fichiers ici, mais chaque répertoire semble en contenir dix de plus, et je n'ai pas encore trouvé de fond.

Parcourir le code source de l'un de ces projets (certes volumineux) semble intimidant. Il y a un certain étalement ici. La plupart des projets Python, en revanche, sont relativement compacts: quelques niveaux de profondeur, une demi-douzaine de fichiers de large.

Je soupçonne que cela se résume à une propriété très importante de Java: qu'un seul fichier ne peut contenir qu'une seule classe (publique). Si je comprends bien, Java n'a aucune notion d'exportations; si vous avez un fichier foo / Bar.class, la seule chose qui peut être importée est une classe publique appelée Bar. Peu importe la façon dont vous souhaitez organiser votre code, la taille de vos classes ou leur nombre, vous avez besoin d'un fichier distinct pour chaque classe publique. Les règles sont différentes, mais cela me rappelle un peu Perl, en quelque sorte. Wow, c'est une chose étrange à dire.

Comparez cela à Python, qui a une hiérarchie de packages d'aspect assez similaire. Le fichier foo / bar.py peut être importé comme chemin en pointillé foo.bar, et son contenu peut être appelé foo.bar.Bar. Mais foo.bar sera un espace de noms intermédiaire, un module objet, qui contient tout ce qui est défini dans le fichier. Les importations ressemblent à celles de Java, mais les fichiers sont de forme libre. Un seul fichier peut contenir de nombreuses petites classes, des fonctions gratuites, la plomberie publique et tout ce que vous voulez. Les fichiers Python peuvent contenir des des idées; Les fichiers Java sont enchaînés à tout ce que vous pensez qu'une «classe» devrait être.

J'ai du mal à imaginer travailler sur un grand projet avec cette limitation d'une classe par fichier. Créer une nouvelle classe (plutôt que de clouer sur une classe existante) implique déjà une certaine friction; avoir besoin de créer un tout nouveau fichier aurait un effet dissuasif énorme. Je voudrais probablement avoir le moins de classes possible, ce qui pourrait être la raison pour laquelle j'associe légèrement Java à de grandes classes velues. Plus de choses par classe signifie moins de classes dans l'ensemble – problème résolu!

Curieusement, Java Est-ce que avoir un moyen d'émuler des modules de type Python, mais je n'ai jamais vu ni entendu parler de son utilisation. importer de l'électricité statique permet d'importer directement des classes imbriquées, donc un fichier peut contenir une grande classe publique avec un nombre illimité de classes publiques statiques. La classe de niveau supérieur serait un conteneur stupide, similaire à un module Python, et toute combinaison de ses enfants statiques pourrait être importée par n'importe quel autre code. Hélas, si cela est aussi rare qu'il y paraît, la confusion qui en résulte entre les autres développeurs Java annulerait probablement les avantages.

En regardant à nouveau elasticsearch, le paquet la structure n'est pas trop différente de la façon dont je pourrais organiser un projet Python. Considère ceci une analyse répertoire, où de nombreux fichiers sont des classes standard qui ne dépassent pas la licence en haut du fichier. Il s'agit d'un package unique avec beaucoup de petites classes; ils ne sont répartis que sur plusieurs fichiers car la langue l'exige. Interprété de cette façon, elasticsearch est un projet assez soigné. J'ai même trouvé quelques répertoires contenant un seul fichier / classe, ce qui est exactement ce que je finirais avec si j'émulais des modules Python avec des répertoires de packages.

L'étalement des fichiers semble légèrement ennuyeux du point de vue du développement, mais il est étroitement lié à une loi assez fondamentale du langage. Désolé, Java; vous perdez ce tour.

Java a une grande bibliothèque standard

S'agit-il d'une plainte réelle déposée par quelqu'un? Je ne suis pas sûr. Il est parallèle à l'utilisation de «gonflé» pour les logiciels d'utilisateur final, donc ça vaut le coup d'oeil.

Les bibliothèques standard sont un compromis délicat. La bibliothèque standard dérisoire de C signifie que de nombreux projets réinventent les mêmes roues, mais gardent le langage lui-même plus simple et plus portable. D'un autre côté, la bibliothèque standard massive de Python est très pratique, mais a accumulé des charges de déchets étranges comme plus d'une douzaine de modules IRIX. Je préfère une bibliothèque standard qui augmente bien le langage de base, bien que je trouve de plus en plus qu'un gestionnaire de packages solide peut être beaucoup plus agréable que d'avoir l'évier de cuisine livré avec la langue elle-même.

Je ne vois pas de bonne façon de mesurer la taille d'une bibliothèque standard en plus de la taille sur le disque. Voici les tailles de certains runtimes linguistiques que j'ai installés sur ma machine, ainsi que les globes zsh que j'ai utilisés pour les mesurer. Mon intuition est que Java, .NET et Python ont des bibliothèques standard assez grandes; La rouille et le rubis en ont des plus modérés; et Perl est assez dépouillé. C n'est rien.

  • Mono 4.6: 43 Mo – /usr/lib/mono/4.5/**/*.dll
  • OpenJDK 7:33 Mo – /usr/lib/jvm/java-7-openjdk/jre/lib/rt.jar
  • CPython 3.5: 27 Mo – /usr/lib/python3.5/**/*.py~*site-packages*
  • Perl 5.24: 17 Mo – /usr/share/perl5/core_perl/**/*.p[ml]
  • Ruby 2.3: 8,9 Mo – /usr/lib/ruby/2.3.0/**/*.rb
  • Rust 1.12: 4.9 MB – /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-*.so
  • C: 2,0 Mo – /usr/lib/libc-2.24.so

Eh bien, euh, hm. Colorie-moi légèrement surpris.

Certes, c'est une comparaison terrible. La bibliothèque standard de Rust est compilée jusqu'au code machine (ce qui la rend plus petite). Je suppose que Mono et OpenJDK sont compilés en bytecode. Les bibliothèques CPython, Perl et Ruby sont du code source non compressé (les rendant plus grandes), mais excluent quelques composants binaires (les rendant plus petits), mais incluent une grande quantité de documentation en ligne (les rendant plus grandes), mais sont écrites en plus haut – langues de niveau (en les réduisant).

La position de Perl me fait d'autant plus douter de cette méthodologie. Tout ce que je peux vraiment conclure, c'est que la bibliothèque standard de Java est un peu plus grande que celle de Python, ce qui semble exact – Java est livré avec deux fois plus de packages GUI que Python, par exemple. Je ne vois aucun signe fort ici que la bibliothèque standard de Java est ingérable grand.

Le score jusqu'à présent

Java est-il la bête de somme qu'il est censé être? Les résultats sont mitigés. Je ne peux penser à aucune bonne raison pour laquelle Java serait accusé d'être particulièrement lent, en particulier dans un monde de plus en plus propulsé par JavaScript, et cela ne correspond pas à mes expériences récentes. Je suppose que Java a été le premier langage largement utilisé à s'appuyer sur une machine virtuelle, il a fallu beaucoup de flak pour cela et les premières impressions persistent pour toujours.

D'un autre côté, Java peut être plus faim de mémoire que ce à quoi je m'attendais. Je n'ai pas d'explication satisfaisante pour expliquer pourquoi c'est le cas ou pourquoi cela semble tellement pire sur mon bureau que sur mon téléphone. Il est possible que quelques-uns de mes rares points de données soient tout simplement mauvais. Il est également possible que Java soit vraiment un porc de mémoire, c'est pourquoi peu de logiciels de bureau public sont écrits en Java, et je ne le remarque jamais sur mon téléphone parce que je ne fais pas autant de tâches à la fois.

Je suis programmeur, mais je ne suis pas Java programmeur, donc la plupart de cela a été du point de vue de l'utilisateur final – où plusieurs autres facteurs contribuent à une perception négative injuste de Java. Java ne se rappelle aux utilisateurs de bureau que lorsqu'il fait quelque chose de gênant, comme l'exécution d'un service de démarrage rapide au démarrage (est-ce toujours une chose?) Ou un bug sur les mises à jour. J'ai mentionné brièvement que Swing sort comme un pouce endolori, et les programmes que j'ai essayés ont cimenté cette impression: ils utilisent les mauvaises couleurs et polices, ils utilisent par défaut le rendu de police sous-pixel de Java qui saigne mal, et ils font des choses bizarres comme émuler le Boîte de dialogue de sélection de fichiers Windows 95 sous Linux. Je gémis chaque fois que je rencontre un programme Swing, parce que je sais que ce sera maladroit et maladroit – et puisque le programme est si évidemment écrit en Java, j'associe «maladroit» à Java dans son ensemble.

Mais Java a une présence petite et rétrécie sur le bureau et disparaît des navigateurs, donc peut-être que la perspective de l'utilisateur final n'a pas tant d'importance. Java est toujours très populaire côté serveur et alimente presque exclusivement Android, et il doit y avoir une bonne raison à cela. Je reste sceptique mais curieux. Je vais devoir approfondir ce à quoi ressemble Java du point de vue du développement dans la deuxième partie.

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.