Soucis avec certains produits OpenSource (Nouveau, IcedTea) - Page 2

et t'as même pas tigcc dessus ?

Pour tes polices, ça dépend aussi de l'environnement de bureau que tu utilises: les versions récentes de GNOME codent toujours 96 dpi en dur quelle que soit la valeur fournie par le pilote (parce qu'ils ne font plus confiance à cette dernière), dans KDE, c'est configurable (comme tout), mais respecte la valeur fournie par le pilote par défaut. Mais je ne sais pas si OpenJDK respecte la valeur fournie par l'environnement (exportée dans les XSettings par gnome-settings-daemon sous GNOME ou par xsettings-kde (que je conseille d'installer si ce n'est pas encore le cas) sous KDE) ou s'il a encore un réglage à sa sauce. Les toolkits standard (Qt, GTK+) respectent les réglages de l'environnement de bureau, mais Java est toujours un peu "bizarre".

Kevin Kofler (./33) :
mais Java est toujours un peu "bizarre".

-Java+OpenJDK

-OpenJDK +le JDK/JRE de Sun, version Open ou non
C'est pratiquement le même code. S'il y a des différences, c'est que les distributions ont modifié OpenJDK pour être moins bizarre, donc si tu crois que l'édition propriétaire s'intègre mieux, tu es totalement à côté de la plaque.

Ah ? OK, pourquoi pas. J'ai toujours entendu du mal d'OpenJDK. Sans doute que ça a évolué

Les problèmes avec OpenJDK, c'était surtout du code non-standard qui utilise des interfaces internes à l'implémentation (notamment com.sun.* et sun.*), implémentation qui a changé par endroits pour des raisons de licence. (Et encore, ce problème était encore plus fréquent avec GNU Classpath qui était une implémentation totalement différente.) Maintenant, avec Java 7, ils ont viré ces interfaces non-standard aussi de l'édition propriétaire pour éliminer les différences entre les 2 versions, et les développeurs gueulent que c'est "incompatible", mais AMHA ils ont bien fait. Ces interfaces n'auraient jamais dû être utilisées, et maintenant les développeurs sont obligés de rendre leur code portable comme l'était le but de Java dès le départ. (Et pour les interfaces internes qui restent dans Java 7 et OpenJDK, le compilateur se plaint maintenant avec un avertissement (warning) quand on essaie de les utiliser.)

Niveau intégration avec le système, IcedTea (la version de OpenJDK distribuée en pratique) a toujours été en avance sur l'édition propriétaire.

Kevin Kofler (./37) :
et maintenant les développeurs sont obligés de rendre leur code portable comme l'était le but de Java dès le départ

peut être le but de java, mais pas forcément de leur projet... j'ai un couteau suisse, mais quand je coupe une pomme, je ne m'efforce pas de rendre l'opération possible avec le tire bouchon...



et les développeurs ont raisons de raler : ça représente un cout non négligeable de refondre du code, des appels aux interfaces... et même si des automates en sont capables, il faudra de toutes manière faire une revue de code, une nouvelle recette, des tests de non régression... et ca ce n'est pas négligeable...

vince (./38) :
peut être le but de java, mais pas forcément de leur projet... j'ai un couteau suisse, mais quand je coupe une pomme, je ne m'efforce pas de rendre l'opération possible avec le tire bouchon...

C'est à cause de cette attitude que c'est bien qu'Oracle ait supprimé ces APIs aussi de leur édition propriétaire, sinon on n'aurait jamais d'applications compatibles avec OpenJDK de la part des développeurs qui pensent comme toi!

et les développeurs ont raisons de raler : ça représente un cout non négligeable de refondre du code, des appels aux interfaces... et même si des automates en sont capables, il faudra de toutes manière faire une revue de code, une nouvelle recette, des tests de non régression... et ca ce n'est pas négligeable...

Fallait suivre ce que disait de faire la documentation depuis toujours: ne pas utiliser les interfaces en com.sun.* ou sun.*. Il était écrit noir sur blanc depuis le départ que ces interfaces pouvaient être modifiées ou supprimées à tout moment. C'est la décision d'utiliser quand-même ces interfaces qui engendre le coût en question, pas la décision d'Oracle de les supprimer comme Sun s'était réservé le droit depuis le départ.

Kevin Kofler (./39) :

vince (./38) :
peut être le but de java, mais pas forcément de leur projet... j'ai un couteau suisse, mais quand je coupe une pomme, je ne m'efforce pas de rendre l'opération possible avec le tire bouchon...

C'est à cause de cette attitude que c'est bien qu'Oracle ait supprimé ces APIs aussi de leur édition propriétaire, sinon on n'aurait jamais d'applications compatibles avec OpenJDK de la part des développeurs qui pensent comme toi!

Souvent, cette attitude on ne la choisit pas. Je ne sais pas ce qu'il en est pour toi, mais si je décide de faire en sorte que le tire bouchon aussi puisse couper la pomme, je vais y passer du temps et ce n'est pas prévu. Le temps que je passe à coder, des gens le payents, je ne sais pas ce qu'il en est pour toi, mais moi, j'ai besoin de cet argent pour vivre et je ne peux pas me permettre de refuser de faire ce pour quoi je suis payé simplement pour vouloir développer quelque chose qui ne servira pas.

Kevin Kofler (./39) :

et les développeurs ont raisons de raler : ça représente un cout non négligeable de refondre du code, des appels aux interfaces... et même si des automates en sont capables, il faudra de toutes manière faire une revue de code, une nouvelle recette, des tests de non régression... et ca ce n'est pas négligeable...

Fallait suivre ce que disait de faire la documentation depuis toujours: ne pas utiliser les interfaces en com.sun.* ou sun.*. Il était écrit noir sur blanc depuis le départ que ces interfaces pouvaient être modifiées ou supprimées à tout moment. C'est la décision d'utiliser quand-même ces interfaces qui engendre le coût en question, pas la décision d'Oracle de les supprimer comme Sun s'était réservé le droit depuis le départ.

Elles n'ont pas de cout tant qu'on est pas le couteau sous la gorge pour le faire...

Et ben, c'est exactement pour ça qu'Oracle vous met le couteau sous la gorge maintenant. Pour une fois qu'Oracle fait quelque chose de bien pour le logiciel libre, tout le monde gueule.

J'espère que cela servira de leçon: Dépendre des spécificités d'une implémentation particulière, surtout quand la documentation avertit noir sur blanc qu'elles peuvent changer à tout moment, n'est pas et ne sera jamais future-safe!

C'est pas comme ça que les "pros" voient les choses : ils ont mis "java 6" dans les cibles supportées et si un client demande une cible non supportée, le portage sera à ses frais... (et comme on l'expliquait -avec bien du mal- à un ex collègue : même si une techno de cette année permet de faire tout proprement tiptop, on ne peut pas se permettre de réécrire ce qui a été fait il y a dix ans si aucun besoin métier ne nous y contraint...)

Le problème, c'est surtout que le code non-standard s'est retrouvé à des endroits (applets Java sur des sites web, par exemple) où on a vraiment besoin de code portable, ou du moins compatible avec OpenJDK (parce que dans le monde des distributions GNU/Linux, ce n'est pas toi qui choisis la VM qui fera tourner ton application, ni même ton utilisateur, mais la distribution qu'il utilise! Et la plupart des distributions ont choisi OpenJDK pour des raisons de licence évidentes), et donc Oracle a fait ce qui était de plus logique pour résoudre ce problème. De plus, ça leur permet d'utiliser le même code pour OpenJDK et l'édition propriétaire, donc ils ont moins de code à maintenir, et les utilisateurs d'OpenJDK ne sont plus confrontés à des incompatibilités gratuites. Bref, tout le monde y gagne, sauf évidemment les développeurs qui ont abusé des interfaces privées.

ou bien (et ça sera probablement le cas) ils se contenteront d'un warning "attention, la cible open jdk n'est pas officiellement supportée"

C'est bien pour ça que c'est important que les interfaces en question soient retirées de toutes les éditions comme Oracle l'a fait. Les sites ne pourront pas demander Java 6 pour l'éternité.

oui et non, même si c'est compatible avec prout-caca-jdk en théorie, tant qu'une recette n'aura pas été faite, la cible ne pourra pas être réputée "supportée" par l'éditeur.

Le problème, c'est surtout qu'on ne puisse pas avoir plusieurs versions majeures de JVM de façon concomitante dans un même navigateur... c'est hallucinant qu'on ne puisse pas avoir un attribut du genre java_version = "n" au moment de l'appel de l'applet (ou qu'il n'y ait pas un "preferred version" en dur directement dans les binaires) et qu'on ne puisse pas avoir plein de JVM actives à la fois (voire manuellement sélectionnables via un plug-in qui intercepterait les lancements d'applets).

c'est vrai, d'autant que, s'agissant de vm, il ne devrait pas y avoir de restriction sur le nombre et le type...

Parce que c'est lourd? Parce qu'on ne veut pas avoir affaire aux problèmes de licence des anciennes versions? Etc.

Tout code conforme à la spécification Java marche sans problèmes avec la version la plus récente. C'est la spécification qu'il fallait viser, pas une implémentation particulière.

Ou au minimum, en vue du portage, utiliser des ram calls pour ne pas disperser ce code technique !

Nil > ça poserait aussi de gros problèmes de sécurité : si les applets pouvaient choisir une version de la JVM, suffirait de demander une ancienne version pour pouvoir réexploiter les failles corrigées dans les versions ultérieures (et backporter les correctifs n'est pas réaliste)

Kevin Kofler (./49) :
Parce que c'est lourd? Parce qu'on ne veut pas avoir affaire aux problèmes de licence des anciennes versions? Etc.

C'est pourtant ce que fait MS. C'est lourd, certes, mais ça fonctionne.

Zerosquare (./51) :
Nil > ça poserait aussi de gros problèmes de sécurité : si les applets pouvaient choisir une version de la JVM, suffirait de demander une ancienne version pour pouvoir réexploiter les failles corrigées dans les versions ultérieures (et backporter les correctifs n'est pas réaliste)

Ca obligerait les développeurs de JVM a corriger les bugs connus des JVM. Mais ça fait combien... 7 versions majeures à maintenir. On peut dire décemment qu'on ne maintient plus les versions de plus de 10 ans. Ca fait de Java 4 à Java 7, soit 4 versions majeures (et - oh, magie - ça couvre les versions utilisées actuellement dans le monde pro !). Sachant que les versions majeures continuent à avoir des correctifs un certain temps après la sortie de la version n+1, je ne suis pas certain que ça soit si gênant que ça.
En outre, comme j'indiquais, ça pourrait être une action demandée à l'utilisateur. Ou une option décochée par défaut. Ou que le navigateur (Fx a fait ça pour certaines JRE1.6) désactive les JVM pour lesquelles des failles importantes ne sont pas corrigées...

Je ne connais pas beaucoup de boîtes qui font du support logiciel sur 10 ans, excepté dans des cas très spécifiques ; déjà que souvent, on peut s'estimer heureux quand on a 5 ans...

Et puis ça reste un pis-aller pas terrible. Si tu fais une API rétrocompatible, les anciens softs profitent aussi de certaines évolutions sans que ça demande de boulot supplémentaire. S'il y a des problèmes de compatibilité insoluble, tu peux aussi faire une API versionnée avec une base de code unique (si une appli demande une version précédente, les trucs qui sont incompatibles sont émulés en utilisant des wrappers). C'est mieux que de se traîner X versions de la base de code.

Nil (./52) :
C'est pourtant ce que fait MS.

Justement, c'est un excellent indice qu'il s'agit d'une très mauvaise idée.

Ca fait de Java 4 à Java 7

Java 4??? Cela s'utilise-t'il toujours?!

Zerosquare (./53) :
Je ne connais pas beaucoup de boîtes qui font du support logiciel sur 10 ans

http://www.redhat.com/about/news/press-archive/2012/1/red-hat-enterprise-linux-stability-drives-demand-for-more-flexibility-in-long-term-operating-system-deployments

Mais de là à installer toutes les versions en même temps…

Et puis ça reste un pis-aller pas terrible. Si tu fais une API rétrocompatible, les anciens softs profitent aussi de certaines évolutions sans que ça demande de boulot supplémentaire.

Et c'est exactement ce que fait le Java. Il y a juste quelques applications hors la spécification qui cassent.

Kevin Kofler (./43) :
parce que dans le monde des distributions GNU/Linux, ce n'est pas toi qui choisis la VM qui fera tourner ton application, ni même ton utilisateur, mais la distribution qu'il utilise!

parfaitement faux, chaque fois que touche un linux quelconque sur lequel j'ai besoin de java, je vire l'intégralité de tout ce qui pourrait ressembler de près ou de loin à un java fourni par la distro, je télécharge le targz/rpm depuis chez oracle, décompression dans /usr/java, lien symbolique /usr/java/latest vers ce qui me va bien, définition de JAVA_HOME dans les profile, et roule ma poule!

Ce n'est souvent pas openjdk lui même qui pose problème, mais le packaging merdique des différents composants, c'est proprement incompréhensible à moins d'être un debian nerd ou un redhat nerd.

entre les headless les hotspot les jre jdk versions libs et paquets virtuels, j'ai toujours plus vite fait de faire le ménage et d'installer un vrai java officiel.

Nil: d'ailleurs p-ê via JAVA_HOME tu dois pouvoir lancer des firefoxs qui utilisent des java différents.

squalyl (./55) :
Nil: d'ailleurs p-ê via JAVA_HOME tu dois pouvoir lancer des firefoxs qui utilisent des java différents.

Oui, c'est ce qu'on fait, on a autant de profils Fx que de JVM, mais c'est très chiant pour les utilisateurs (tu te retrouves avec des sessions différentes, des favoris, un historique différents, de la mémoire vive utilisée pour rien...).

owi owi

sinon y'a sync

Kevin Kofler (./54) :
Justement, c'est un excellent indice qu'il s'agisse d'une très mauvaise idée.

qu'il s'agit

squalyl (./57) :
sinon y'a sync

Oui, mais ça a plein d'autres implications (j'y ai pensé, t'inquiète ) : on ne peut pas se satisfaire d'une solution où on hébergerait les informations sur un serveur tiers, donc ça implique de mettre en place un serveur dédié à ça pour ceux qui ont besoin de cette spécificité (on n'accorde plus d'accès ftp aux gens, on avait quelques abus ).

oui on peut faire un serveur sync local en 3 coups de cuillère à php, j'ai fait, c'est un serveur tiers, pas celui de mozilla qui était trop complexe.

mais faut avoir les ressources anéfé.