Pourquoi Ubuntu 14.04 reste-t-il avec (l'ancienne) Eclipse 3.8 lorsque 4.3 est sorti?
Ubuntu est généralement une distribution de pointe. Mais pourquoi s'en tient-il à une version 2011 d'Eclipse alors que nous en sommes à 4 ans 4.x développement?
Ce n'est même pas facultatif et ne peut pas être installé à partir des référentiels. Et ce n'est pas non plus "facile" à partir d'un téléchargement. Pour une raison quelconque, l'implémentation de référence Java SE 7, OpenJDK, ne suffit pas, et vous avez besoin de la version Oracle. Pourquoi? Cela n'est pas disponible non plus dans le référentiel, et vous avez besoin d'un peu bizarre repo tiers non fiable pour cela ou suivez un chapitre entier sur comment l'installer vous-même .
Il y a eu des problèmes il y a trois ans. Quand Juno 4.2 est sorti, il y avait beaucoup de problèmes de performances . Le directeur d'Eclipse, Mike Milinkovich explique l'une des raisons est le manque de financement. Pour la première fois dans une version majeure:
"Le test de performances a été désactivé car l'équipe de la plateforme Eclipse a un sérieux problème de ressources."
Pour cette raison, les développeurs ont publié sans nom et sans promotion version 3.8 simultanément avec 4.2 pour combler l'écart pour ce problème (espérons-le) temporaire, et sa popularité a provoqué une nette tendance à la baisse parmi les développeurs. Comme un Eclipse b3 développeur mentionné :
"J'ai été stupéfait par l'amélioration des performances après le changement. La plate-forme 3.8 est BEAUCOUP plus rapide"
Le 3.8 la version est toujours une alternative populaire à la 4.x branche parmi les développeurs (demandez à mes collègues ou à google), je pense principalement à cause de (véritables) problèmes de confiance. Mais le pont (lire: support pour 3.8) a fermé maintenant que 4.3 est libérée.
Les problèmes fondamentaux (financement et développeurs) n'ont cependant pas été résolus, comme le montre geste de don d'argent de Google à la Fondation Eclipse dans l'espoir que d'autres entreprises suivront. Est-ce à dire que 4.3 n'est toujours pas à la hauteur de 3.x normes?
Ce n'est pas un problème avec un plugin ou une fonctionnalité pour une langue spécifique, c'est un problème dans le cœur de la plateforme elle-même. (Mais j'utilise WST avec des plugins Javascript et V8 pour PHP et Node en particulier.)
Ce n'est pas non plus un problème de plate-forme spécifique. Il y a plaintes similaires des utilisateurs de Linux, Windows et OSX. (Mais j'utilise Linux (Mint 13).)
D'une part, vous avez des gens qui disent à l'EOL pour 3.8 "prouve" que 4.3 va bien maintenant. En revanche (voir commentaires):
"Je suis revenu à 3.8 en raison de plantages constants sur ubuntu avec 4.3"
3.8 est loin d'être sans problème et cela ne me dérangerait pas d'avoir une expérience de développement plus fluide. Je me demande donc pourquoi Eclipse 4 est 'caché de nous' par les gens qui décident quelles versions de logiciel sont 'bonnes pour nous' (AKA qu'est-ce qui entre dans le dépôt officiel)?
- lucide (10.04 LTS)
- Eclipse 3.5.2-2
- précis (12.04 LTS)
- Eclipse 3.7.2-1
- raring (13.04)
- Eclipse 3.8 . 1-1
- impertinent (13.10)
- Eclipse 3.8 . 1-4
- fidèle (14.04 LTS)
- Eclipse 3.8 . 1-5.1
- utopique (14.10)
- Eclipse 3.8 . 1-5.1
Mise à jour 2014-05-30: Je viens d'essayer Kepler (à nouveau) et il souffre toujours de problèmes d'interface utilisateur. Par exemple.:
Et non, changer la couleur d'arrière-plan de la barre d'outils de la fenêtre inactive dans les préférences ne résout pas ce problème. (Même si c'était le cas, ce serait un choix par défaut idiot).
Je voudrais savoir, de la part de quelqu'un qui n'est pas biaisé positivement ou négativement en raison de son propre flux de travail hautement spécialisé et modifié - de préférence d'une personne ayant de l'expérience dans le processus de maintenance de paquets Ubuntu pour les paquets non triviaux - pourquoi cette décision est prise par une équipe de professionnels qui savent ce qu'ils font pour la distribution Linux la plus utilisée?
Eclipse Juno est sorti 2012-06-27 . Le 2012-07-17 n bug concernant la réactivité de l'interface utilisateur a été signalé. Quatre mois plus tard, vers le 2012-11-14, le premier patch a été publié sur le site de mise à jour officiel.
Cependant, de nombreux utilisateurs ont complètement manqué la sortie des correctifs. Je suppose que les informations se sont noyées dans le FUD, et d'autres nouvelles plus importantes , qui se sont répandues à cette époque. Fin 2012, j'ai posté un réponse sur SO . Apparemment, je n'étais pas le seul pour qui le correctif a résolu ce problème de performances. Le 22/02/2013, Eclipse 4.2.2 a été publié, qui contenait le même patch, mais j'ai continué à recevoir des votes positifs pour ma réponse le SO jusqu'en juin).
Le seul fait connu parmi les développeurs est probablement qu'Eclipse a eu de sérieux problèmes de performances à un moment donné. Cependant, la connaissance de la portée, de l'ampleur et de la durée de ces problèmes me semble être une série d'idées fausses courantes. Il y a eu une période de quatre mois au cours de laquelle c'était une bonne idée pour de nombreux utilisateurs d'Eclipse de s'en tenir à la branche 3.8. Je dis "beaucoup" parce que j'ai travaillé avec 4.2.0 et 4.2.1 et c'était O.K. pour moi. Subjectivement, la commutation des onglets était environ deux fois plus lente et le IDE a gelé peut-être une fois par jour pendant quelques secondes. Pour mes collègues, le problème était beaucoup plus grave. Je suppose que cela dépendait de votre configuration et sur votre flux de travail, cependant, je n'ai jamais eu envie d'enquêter davantage, car je savais que les développeurs de la plate-forme travaillaient sur les problèmes, et il y avait une bonne solution de rechange, en utilisant 3.8.
Un an et trois versions d'Eclpse plus tard, ces graves problèmes de performances sont toujours résolus. Bien sûr, cela ne signifie pas qu'il n'y a plus de problèmes de performances. A partir de maintenant, je trouver 1979 rapports dans le bugzilla Eclipse avec le mot-clé "performance". Cela ne signifie pas qu'Eclipse est très buggé, mais seulement qu'il est très bien documenté et ouvert. Que vous soyez ou non affecté par l'un de ces problèmes, encore une fois, cela dépend de la configuration, des plug-ins que vous utilisez et de votre flux de travail. Je suis Java, plug-in et EMF. Je travaille avec des espaces de travail moyens à grands (~ 1M LoC), et Eclipse 4.3.1 est assez rapide . La version 3.8 n'est pas une option pour moi car, comme Eric l'a dit, elle ne recevra pas toutes les mises à jour importantes. Les gens continueront de l'utiliser à l'avenir. Beaucoup d'entre eux continueront également à utiliser Internet Explorer 5.5. Si vous essayez la branche 4.x et notez tous les problèmes de performances, veuillez les signaler , mais soyez précis sur votre configuration.
De l'officiel page Wiki :
Plusieurs défauts de performances majeurs ont été corrigés dans Juno SR2 (4.2.2). Les membres de la communauté ont confirmé que ces correctifs résolvent substantiellement les problèmes de performances liés à l'ouverture, à la fermeture et à la commutation de l'éditeur et de la vue. Ces correctifs sont largement disponibles dans Juno Service Release 2 (février 2013). Tous les défauts sont également résolus dans le flux de versions de Kepler (juin 2013).
Votre déclaration "La version 3.8 a été spécifiquement publiée comme une alternative plus rapide et plus stable à la 4.2" est clairement incorrecte; 3.x est entré dans sa maintenance de "fin de vie" et n'a certainement pas été publié comme alternative à 4.x.
Bien que les gens soient invités à continuer d'utiliser le flux 3.x s'il convient à leurs besoins, sachez que, à mesure que les différents projets progresseront, il y aura une divergence significative dans les fonctionnalités disponibles entre les deux versions ...