Il s'agit d'une "solution" pour les PC de bureau et les ordinateurs portables. Mad Hatter repose sur Linux et contient notamment une interface basé sur GNOME (l'original vient d'être intégré à Solaris), Ximian Evolution, Mozilla, StarOffice, et Java. Les deux derniers éléments appartiennent à SUN et leur présence indique qu'il ne s'agit pas d'une distribution libre (cela n'a d'ailleurs jamais été le but) mais l'ensemble constitue concurrent frontal à Windows XP et MS Office (ce qui est d'ailleurs ouvertement l'objectif).
MadHatter sera plus concrètement présenté mi-septembre dans le cadre du SunNetwork.
Aller plus loin
- Project Mad Hatter (annonce et captures d'écrans) (4 clics)
- SUN et Linux (3 clics)
- GNOME pour Solaris (2 clics)
# Premier titre ?!.
Posté par Space_e_man (site web personnel) . Évalué à 10.
[^] # Re: Premier titre ?!.
Posté par almacha . Évalué à 1.
("les brevets logiciels" est redevenu le 1er titre)
# Re: SUN annonce Mad Hatter
Posté par Fabien Jakimowicz . Évalué à 10.
[^] # Re: SUN annonce Mad Hatter
Posté par Anonyme . Évalué à 10.
[^] # Re: SUN annonce Mad Hatter
Posté par ploum (site web personnel, Mastodon) . Évalué à 10.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: SUN annonce Mad Hatter
Posté par passant·e . Évalué à 10.
Enfin bref, sûrement une sublitlité qui l'est trop pour moi.
voila
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: SUN annonce Mad Hatter
Posté par Anonyme . Évalué à -6.
Ils sont peu etre en vacances ?
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 10.
Enfin bref, sûrement une sublitlité qui l'est trop pour moi. »
La subtilité c'est le caractère libre ou non d'éléments indispensables tels que l'installeur et le gestionnaire de paquets. Staroffice et Java sont propriétaires mais il est possible de s'en passer.
Qu'en est-il pour cette distribution ?
[^] # Re: SUN annonce Mad Hatter
Posté par gndl (site web personnel) . Évalué à 10.
[^] # Re: SUN annonce Mad Hatter
Posté par Éric (site web personnel) . Évalué à 5.
Hum ... soit j'ai du mal comprendre soit cet argument n'a aucun sens
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 3.
C'est ta question qui n'a pas de sens, plus précisément c'est le mot « mieux » qui n'a pas de sens (simplification abusive). Donc la réponse à la première question c'est que tu as mal compris.
[^] # Re: SUN annonce Mad Hatter
Posté par let antibarbie = xp <- xp - 1 . Évalué à 10.
[^] # Re: SUN annonce Mad Hatter
Posté par linuxidable . Évalué à 5.
Ce que je voulais dire c'est qu'une boite qui n'existe que grace au libre et qui vend du proprio par dessus peut donner le sentiment de trahir le libre, d'où une image plus négative que celle d'une boite comme Sun qui ne doit (devait) rien au libre et qui a évolué dans sa mentalité pour ce rapprocher du libre. En réalité je pense que Sun est au moins aussi opportuniste que Suse mais les conditions font qu'elles ne dégagent pas la même image.
[^] # Re: SUN annonce Mad Hatter
Posté par Boa Treize (site web personnel) . Évalué à 6.
Donc Sun, c'est bien, parce que au milieu de tous leurs développements propriétaires, ils lâchent de temps en temps quelques trucs libres, mais SuSE, c'est mal, parce qu'au milieu de tous leurs développements libres, ils ont deux trucs moins libres ?
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 4.
[^] # Re: SUN annonce Mad Hatter
Posté par Éric (site web personnel) . Évalué à 2.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 0.
[^] # Re: SUN annonce Mad Hatter
Posté par Boa Treize (site web personnel) . Évalué à 5.
Je suis d'un avis opposé. L'installeur et le gestionnaire de paquets sont très spécifiques à une distribution. Je dirais même que c'est la partie la moins intéressante à reprendre dans une autre distro. Je préfère nettement avoir un installeur ou un gestionnaire de paquets gratuit-mais-pas-assez-libre qu'un environnement de développement tout aussi gratuit et tout aussi peu libre qui peut évoluer de manière douloureuse voire fatale pour mes développements, à la bonne volonté de son propriétaire (même si avec Java on est assez protégé par le poids industriel et l'inertie qu'il a pris).
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à -2.
Donc d'après toi s'il y a Staroffice et Java de Sun sur une distrib, on ne peut pas s'en passer. On ne peut pas utiliser une alternative, on est obligé de s'en servir. Évidemment pour les gens comme ça, mieux vaut que ce soit l'installeur qui soit proprio. Mais je ne parlais pas de ces cas non réalistes (et c'était explicite).
Le problèlme que peut poser Sun Java en tant que langage proprio est bien sûr le même quelle que soit la distribution, existe pour toutes celles qui le proposent, et sur toute distrib 100% libre aussi si on l'installe.
[^] # Re: SUN annonce Mad Hatter
Posté par Marc Lacoste . Évalué à 5.
Dans une optique Desktop, complètemment. SO offre la meilleure compatibilité avec les documents MS office, et offre des fonctions en plus vis a vis d'OO.o appréciables pour l'utilisateur, comme une BD et un correcteur. Une JVM est également indispensable, des fois que dans la boite, ils aient un logiciel client spécifique en bouffe-ram.
Je vois plus une distrib comme ça comme un accompagnement à SO, avec le label SUN qui pète bien pour un décideur préssé. C'est une bonne chose, la base installée, l'acceptation générale se renforceront.
> Le problèlme que peut poser Sun Java en tant que langage proprio
Et alors? Le java, c'est pas grave.
* avoir une jvm, c'est pas grave, c'est pour faire tourner des trucs, qui eux sont importants
* avoir une jre au boulot, c'est pas ton choix, tu n'es pas responsable
* avoir une jre chez soi, le choix est libre, tu pourrais aussi bien faire du c++ ou du python.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à -1.
Il va de soi que pour quelqu'un qui veut du Java, cette distrib ne pose aucun problème, et convient même plutot bien. Donc je ne vois pas l'interet de cette intervention, ce n'est pas la question.
[^] # Re: SUN annonce Mad Hatter
Posté par Boa Treize (site web personnel) . Évalué à 4.
Ce n'est pas du tout ce que j'ai dit ou voulu dire. Je ne vois pas comment tu es arrivé à une telle conclusion.
Un installeur et un gestionnaire de paquets ne sont que des outils servant à gérer une machine, ils ne servent pas à créer une oeuvre, soit-elle technique ou artistique (ou les deux bien sûr). S'ils évoluent, je peux toujours utiliser une autre distribution, avec un autre installeur et un autre gestionnaire de paquets, ou même suivre la recette donnée dans Linux From Scratch.
Par contre, Java et StarOffice sont des outils que l'on utilise pour créer une oeuvre, et si leur état venait à changer brusquement, de manière incompatible, on pourrait se voir forcé à abandonner ses développement en leur état et à les reprendre sous une autre forme (un autre langage ou un autre format de fichier), ce qui représente un coût plus important qu'un changement d'installeur ou de gestionnaire de paquets.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 2.
En tant que réponse à ce que je disais, ça me parait la seule interprétation, c'est pour ça que je le soulignais, je me doute bien que tu ne le penses pas.
Relis bien : je suis d'accord avec ce que tu dis là sur le fait qu'un installeur/gestionnaire proprio est moins grave que des outils de développement proprio s'il faut faire un choix entre ces deux alternatives. Mais il n'y a aucune obligation de faire ce choix : on peut se passer de Java même si Java est installé, et ce sur toute distrib. Par contre on ne peut pas se passer de certains outils comme l'installeur ou le gestionnaire de paquets (ou alors c'est qu'on refait sa distrib).
Je suis d'accord avec ce que tu dis dans ton post là, mais c'est une considération sur des outils qu'on va utiliser, ce n'est plus le même problème que la question initiale ou on compare des aspects propriétaires de distribs, et où on ne va pas forcément utiliser les outils proprio. Tu fais une remarque sur les outils, tandis qu'il s'agissait d'une remarque sur les distribs et là la différence change tout !
[^] # Re: SUN annonce Mad Hatter
Posté par samds . Évalué à 3.
ca a pas du arriver bien souvent !
[^] # Re: SUN annonce Mad Hatter
Posté par Moby-Dik . Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 2.
[^] # Sun faire du 100% libre
Posté par Marc Lacoste . Évalué à 3.
Quand ils ouvrent OpenOffice.org partiellement (en lgpl) (et gardent SO à coté), c'est parceque des morceaux (correcteur, adabas) ont été achetés séparément et ont une licence fermée, ils restent dans SO commercial.
Bon, ok, ça fait pas 100% mais au moins ils comprennent l'intérêt du LL pour dévellopper un truc (OO.o) qui les arrangent.
Faut pas oublier que Sun (comme Oracle, IBM, Apple, d'autres) veulent devenir calife à la place du calife (MS). Après ils font souvent des choix politiques, pas toujours techniques.
[^] # Re: Sun faire du 100% libre
Posté par samds . Évalué à 1.
Je sais pas si c'est vraiment possible qu'il n'y ait pas de calife, parce que y aura tjs un malin pour prendre la place laissee deliberement libre.
Mais aux dernieres nouvelles, il semble pas que ca choque tant de monde que ca dans le monde qu'une societe dispose d'autant de pouvoir. C'est du totalitarisme numerique ca, et je suis pas du tout certain d'accepter ca encore tres longtemps.
# Re: SUN annonce Mad Hatter
Posté par ploum (site web personnel, Mastodon) . Évalué à 4.
Mais entre nous, c'est vraiment moche. (transformer Gnome2 en cette horrible chose...)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: SUN annonce Mad Hatter
Posté par Gluck_ (site web personnel) . Évalué à -1.
Enfin, les gouts et les couleurs...
Et pour le message plus haut, ca detrone pas la manif que moi j'ai toujours en premiere page
[^] # Re: SUN annonce Mad Hatter
Posté par Yusei (Mastodon) . Évalué à 2.
(c'est vrai que c'est laid le Gnome à la sauce Sun on dirait du Gnome1 avec un mauvais thème)
[^] # Re: SUN annonce Mad Hatter
Posté par mamelouk . Évalué à 6.
ca fait tres windows like...
je pense que le but de ce projet n'est que de copier windows... c'est assez domage...
m'enfin je bosse pas chez sun moi...
[^] # Re: SUN annonce Mad Hatter
Posté par Gluck_ (site web personnel) . Évalué à 3.
Si ils veulent ouvertement concurrencer windows, la solution la plus simple, c'est de faire la "meme chose" en mieux. Et pour l'utilisateur lambda qui en a rien a foutre, ca passe par du windows like
[^] # Re: SUN annonce Mad Hatter
Posté par L. R. . Évalué à 6.
Rien ne dit que l'interface ne va pas bouger entre temps !
Mais à voir la beauté de CDE sous Solaris, qui n'est pas vraiment destiné à un "grand public de consommation", je trouve qu'ils ont déjà fait des progrès avec Gnome :))
Qui sait ? Peut-être qu'ils vont engager une équipe de graphistes pour améliorer le design et tout ça ? W8'n C comme on dit.
[^] # Re: SUN annonce Mad Hatter
Posté par phobos . Évalué à 1.
Je ne trouve pas ca plus moche qu autre chose .. Pas tres original , mais ca aurait pu etre pire .
[^] # Re: SUN annonce Mad Hatter
Posté par amielp . Évalué à 7.
[^] # Re: SUN annonce Mad Hatter
Posté par spart . Évalué à 8.
Je ne suis pas d'accord, l'aspect esthétique est négligeable...
Ce qui importe c'est qu'il est écrit "This Computer", et pas "My Computer".
Sans blague, c'est très révélateur.
L'essence de Windows, ce n'est pas son interface mais son esprit "mon chien, ma femme, mon logement, que j'ai acquis avec mes sous".
La profonde beaufitude de cela.
Sun reprend la lettre sans reprendre l'esprit, et c'est une excellente nouvelle.
[^] # Re: SUN annonce Mad Hatter
Posté par tgl . Évalué à 10.
Sacha Guitry.
[^] # Sacha Guitry
Posté par passant·e . Évalué à 1.
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: Sacha Guitry
Posté par tgl . Évalué à 5.
http://www.omnibus.tm.fr/FR/leslivres/ficheslivre/054.html(...)
Une représentation avec Jean-Pierre Marielle dans le rôle principal est d'ailleurs passée sur France 2 il y une quinzaine de jours, c'était un régal.
[^] # Re: SUN annonce Mad Hatter
Posté par BubbleBobble . Évalué à 2.
Je ne vois pas où se trouve la beaufitude dans la notion de propriété... Faudrait m'expliquer !
Personnellement, en parlant de mes biens personnels, je considère qu'il s'agit de MA voiture, de MA montre, de MON ordinateur, de MON fric, de MA maison, de MES gosses, de MON chien, etc...
Et puis surtout, que personne n'essaye de me faire "croire" que MA femme n'est pas la mienne, parce qu'il prendrait très vite MON poing dans SA gueule.
Tu vois, la propriété, ça existe, ne serait-ce que par les responsabilités qui en découlent (et qui t'obligent notemment à avoir une assurance auto, une assurance maison, une assurance responsabilité civile, etc)
[^] # Re: SUN annonce Mad Hatter
Posté par BubbleBobble . Évalué à -6.
Ca, c'est la technique de la mort qui tue : je ne suis pas d'accordavec un avis, alors je le moinsse ! encore des personnes qui ont tout compris dans le système de notation et qui abuse de leur droit de vote pour se défouler de toutes leurs frustations quotidiennes.
Raaaaahhhh, lovely !
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 1.
Sans doute parce que c'était pas la peine de crier de manière aussi agressive. Enfin je dis ça, j'aurais surement moinssé pour cette raison si le post avait été visible. Ca te fait une explication, qui n'a rien d'un « pas d'accord » (en fait je suis plutot d'accord, la remarque sur le possessif n'est pas justifiée, surtout en langue anglaise qui l'utilise bien plus).
[^] # Re: SUN annonce Mad Hatter
Posté par Nelis (site web personnel) . Évalué à 3.
Personnellement, je ne considérerai ni mes gosses, ni mon chien comme des "biens personnels" ... Ce qui n'empêche que ce sont TES gosses (tu es leur père) et TON chien (tu en es responsable, mais de là à le considérer comme un bien ...)
[^] # Re: SUN annonce Mad Hatter
Posté par BubbleBobble . Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par elamapi . Évalué à 2.
Je crois que c'est quand même une spécialité de LFR ce genre de débat ....
C'est un peu lassant à la longue mais ca reste marrant.
[^] # Re: SUN annonce Mad Hatter
Posté par tgl . Évalué à 2.
La «beaufitude» n'est pas non plus la première chose à laquelle je pense quand je vois un «My Computer» sur un bureau Windows. Mais en l'occurence, le bureau en question que je peux parfois avoir sous les yeux est un serveur serveur d'applications qui n'est absolument pas le mien, et quinzes autres personnes ont la même chose sous les yeux...
Dans le monde Windows, la notion d'«ordinateur personnel» est profondement ancrée, au moins chez les utilisateurs. La notion de réseau, la multiplicité des utilisateurs, toutes ces choses là ne sont que des ajouts tardifs, mais qui n'ont pas changé l'esprit de ce qui est servi au utilisateurs, et maintiennent ces derniers dans l'ignorance des joies de l'informatique partagée.
Donc tout ça pour dire que si je n'adhère pas tout à fait à sa conclusion, je trouve l'observation de spart très intérressante. Vive «This Computer».
[^] # Re: SUN annonce Mad Hatter
Posté par durandal . Évalué à 4.
[^] # Re: SUN annonce Mad Hatter
Posté par nigaiden . Évalué à 4.
Mais pourquoi c'est "poste de travail" ? Comme si l'ordinateur n'était qu'un outil de travail ! N'importe quoi ! C'est pourtant simple : pour moi le travail s'arrête quand je rentre à la maison. Je ne veux plus entendre parler de boulot. Bordel de bordel.
J'exige que cette icône s'appelle "poste de loisirs" et je vais de ce pas me plaindre auprès de Microsoft France.
Ca va comme ça ?
[^] # Re: SUN annonce Mad Hatter
Posté par tgl . Évalué à 3.
Aaaargh ! Faudra que je demande si c'est possible de passer le serveur d'applis windows en français alors. Je me demande quelles sont mes chances si j'explique que «oui mais vous comprenez, quand je trolle contre windows sur linuxfr, et bah on me reprends...»
# Re: SUN annonce Mad Hatter
Posté par Benoit Loki . Évalué à 7.
C'est incroyable le nombre de personnes qui denigrent Java et adore le C. ET malheureusement, c'est souvent sans connaitre Java. Desole pour l'aspect trollesque de mon commentaire, mais j'en ai marre d'entendre que le C est le meilleur langage du monde !
[^] # Re: SUN annonce Mad Hatter
Posté par Yusei (Mastodon) . Évalué à 2.
(à commentaire trollesque, réponse trollesque)
[^] # Re: SUN annonce Mad Hatter
Posté par adri . Évalué à -7.
[^] # Re: SUN annonce Mad Hatter
Posté par a_jr . Évalué à 1.
Et s'ils le franchissent, c'est un grand pas pour le libre, meme si y'a une bonne dose de proprietaire. C'est un grand pas parce que la base est libre. Il ne restera plus ensuite qu'a changer composant par composant ce qui n'est pas libre par du libre.
Le bonjour chez vous,
Yves
[^] # Re: SUN annonce Mad Hatter
Posté par Gentoo][Gravis . Évalué à 2.
et hop, vive les trolls
je sais ==> []
[^] # Re: SUN annonce Mad Hatter
Posté par Benoit Loki . Évalué à 3.
En tout cas, ca vaut pas Java sur l'interface graphique et surtout c'est moins complet en version standard, t'es vite oblige de rajouter des bindings gtk ou autre et tu perds alors une partie de la portabilité.
Ceci dit , je pense que pour develloper des applications 100% gnu, c'est p-e le langage le + riche et le + efficace en ce moment. De memoire, il y a scketch et scribus qui sont tres biens et tres prometteurs.
[^] # Re: SUN annonce Mad Hatter
Posté par wismerhill . Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par Gloo . Évalué à 5.
Par Java, je veux dire Java et/ou JVM par la suite.
Existe-t-il un environnement graphique, un OS ou un jeu en Java qui tienne la route ?
Est-ce que Java est porté sur plus de 11 architectures ?
Est-ce que Java peut tourner sur des machines avec très peu de ressources ?
Java est-il normalisé ANSI//ISO ?
La reponse à ces questions est, il me semble, non.
Il y a très peu de personne qui se fichent de tout ca simultanement, ce qui explique ce dont tu parles. Evidemment il y a des projets comme jakarta qui indique que java c'est bien pour faire d'autres choses. Par exemple, en exagerant à peine, faire du web avec des machines multi proc et des giga de ram, mais ce n'est pas toute l'informatique. Loin de là.
Enfin bon, perso, j'aime bien le Java et le C.
[^] # Re: SUN annonce Mad Hatter
Posté par Nap . Évalué à 7.
et un mobile, je pense qu'on peux appeler ça une machine avec peu de ressources
[^] # Re: SUN annonce Mad Hatter
Posté par Gloo . Évalué à 0.
Les portables, tout comme les pda, n'ont plus rien de commun avec les microcontroleurs de l'industrie. (je repond ici aussi au poste plus bas).
[^] # Re: SUN annonce Mad Hatter
Posté par Gentoo][Gravis . Évalué à -5.
mais meme en LOGO, je peux te faire un jeu qui tourne sur portable. Lol, tu sors d'ou toi ;)
[^] # Re: SUN annonce Mad Hatter
Posté par vrm (site web personnel) . Évalué à 2.
pour le jeu : http://www.puppygames.net/(...) essaie la demo, elle tourne sous linux
java ca tourne sur les téléphones mobiles avec 4 CPU et 7To de ram ?
[^] # Re: SUN annonce Mad Hatter
Posté par Bungee Tux . Évalué à 5.
Non, mais tous les langages ont leur application favorite. Ada pour le temps reel, assembleur et c pour le bas niveau, c et c++ pour les jeux/contraintes fortes sur la performance, bash et python pour les scripts, prolog pour l'ia etc...
"Est-ce que Java est porté sur plus de 11 architectures ?"
Existe t'il des librairies graphiques de qualite portees sur 11 architectures ?
"Est-ce que Java peut tourner sur des machines avec très peu de ressources ?"
Oui, il etait meme concu pour ca au tout debut. Son empreinte memoire peut etre tres reduite grace a la reutilisation objet.
"Java est-il normalisé ANSI//ISO ?"
Il evolue bcp et propose bcp + que la libc. Il est donc difficile de le normalise. Mais il reste assez stable dans le temps pour interesser bcp d'industriels.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 2.
Oui.
« "Java est-il normalisé ANSI//ISO ?"
Il evolue bcp et propose bcp + que la libc. Il est donc difficile de le normalise. Mais il reste assez stable dans le temps pour interesser bcp d'industriels. »
La réponse à la question posée est donc non.
[^] # Re: SUN annonce Mad Hatter
Posté par wismerhill . Évalué à 1.
Oui.
Et tu peux en citer, libre de préférence, ça pourrait m'intéresser.
[^] # Re: SUN annonce Mad Hatter
Posté par vrm (site web personnel) . Évalué à 0.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 0.
Mais vu la tournure de la question de wismerhill, ce n'est pas ce qui l'intéresse (je ne répondait qu'à la question de départ, pour celle-ci je ne sais pas)
[^] # Re: SUN annonce Mad Hatter
Posté par Gruik Man . Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par tgl . Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . Évalué à 9.
Oui mais la question est finalement peu intéressante parce qu'il faut bien se rendre compte que ça n'a jamais été un argument décisif dans l'adoption d'un langage. Le C++ n'est normalisé ISO que depuis 1997 (je n'ai pas réussi à retrouver le lien exact mais je donne quand même comme exemple un des projets de normalisation de C++):
http://www.comnets.rwth-aachen.de/doc/c++std.html(...)
et ça n'a pourtant pas empêché son utilisation bien avant sa normalisation. Les langages sont soumis à normalisation souvent bien après qu'ils aient été largement diffusés parmis les entreprises (c'était le cas pour le C++ mais aussi pour le COBOL). Ensuite, il existe un organisme de "normalisation" JCP (Java community process) permettant de s'assurer que le langage ne va pas dans un direction qui va à l'encontre des intérêts de ceux qui l'utilisent, Java suit donc un processus très précis pour son évolution :
http://www.jcp.org/en/procedures/overview(...)
Les fameux membres de cet organisme ne sont pas franchement des inconnus, on retrouve parmis les plus grosses entreprises du monde (et aussi des representants du libre comme Apache pour ce qui est de J2EE) garantissant que Java ne va pas à la dérive :
http://www.jcp.org/en/participation/committee(...)
Bref ce "Java est-il normalisé ANSI//ISO ?" est une fausse question qui n'interesse pas grand monde (surtout ceux qui n'aiment pas Java pour diverses raisons certaines valables d'autres non).
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 2.
La norme est de 98 mais la question intéressante c'est quand les travaux ont commencé. Pour Java, est-ce que les travaux d'une normalisation publique/civile ont commencé ?
Quant à dire que ce n'est pas un argument décisif, chez les industriels peut-être, mais dans le LL sûrement pas, Java aurait été bien plus utilisé et aurait apporté beaucoup d'ailleurs.
« et ça n'a pourtant pas empêché son utilisation bien avant sa normalisation. Les langages sont soumis à normalisation souvent bien après qu'ils aient été largement diffusés parmis les entreprises »
Oui, et ça ne change rien à l'intérêt de la normalisation.
« Ensuite, il existe un organisme de "normalisation" JCP (Java community process) permettant de s'assurer que le langage ne va pas dans un direction qui va à l'encontre des intérêts de ceux qui l'utilisent, Java suit donc un processus très précis pour son évolution : »
Si la question sur une norme ISO a été faite c'est évidemment par opposition à une norme propriétaire. Ce que tu dis n'est pas une réponse, juste une remarque annexe, qui n'était même pas contestée.
« Bref ce "Java est-il normalisé ANSI//ISO ?" est une fausse question »
Non.
« qui n'interesse pas grand monde (surtout ceux qui n'aiment pas Java pour diverses raisons certaines valables d'autres non). »
Certainement pas, personnellement les plus enthousiastes sur Java que je connais (et ils aiment vraiment ce langage et la plateforme) regrettent qu'il n'y ait pas de vraie norme. D'ailleurs si le langage passait en norme ISO et que Sun libérait sa JVM il y aurait beaucoup moins de monde, dans le LL, à ne pas aimer Java. Entre autres parce que les progrès de l'implémentation Sun sont reconnus. Quant aux raisons pour lesquelles quelqu'un n'aimera pas Java, je ne vois pas en quoi Java serait spécifique sur le plan du langage/plateforme : tous les langages et toutes les bibliothèques standard ont leurs avantages et leurs intérêts.
[^] # Re: SUN annonce Mad Hatter
Posté par a_jr . Évalué à 3.
...
La réponse à la question posée est donc non.
Si on regarde la norme ANSI/ISO pour le C, on ne fait pas grand chose avec. Il est tout simplement impossible de faire un programme qui fasse un minimum de choses interessantes avec uniquement du code ISO en C.
Si on pousse le debat un peu plus loin, on peut parler de la norme POSIX. Un programme a la fois ISO et POSIX peut deja faire un peu plus de choses.
Mais pour que le C soit vraiment puissant, il faut utiliser des bibliotheques externes (comme glib par exemple) Or glib est portee sur un grand nombre d'architectures, est d'une stabilite plutot bonne, et n'est neanmoins ni ISO ni POSIX ni rien du tout. Et je ne parle meme pas d'autres bibliotheques comme celles qui implementent OpenGL ou autre...
Enfin, si on veut acceder aux ressources de la machine (par exemple /proc), le C devient d'une grande puissance et perd toute portabilite.
Alors, pour conclure, et comme d'autres ont conclu avec d'autres arguments, est-ce que le fait que Java soit ISO comme le C est vraiment important ? Est-ce que ce n'est pas plus important d'avoir une norme Java (que malheureusement Sun definit selon son bon vouloir) que les differents compilateurs java/JVM respecteraient pour une meilleure portabilite ?
Avoir des normes est important. Mais il ne faut pas se tromper de norme !
Le bonjour chez vous,
Yves
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 2.
Avoir une norme c'est s'interdire d'utiliser d'autres normes, des bibliothèques, etc ? Personne n'a dit ça, c'est même assez farfelu comme idée.
(je pense que ça répond à toute la suite du post, dont une phrase importante est « une norme Java (que malheureusement Sun definit selon son bon vouloir) » puisque le problème est là)
[^] # Re: SUN annonce Mad Hatter
Posté par a_jr . Évalué à 4.
Et c'est tellement farfelu que je trouve que c'est un drole d'argument que de dire que Java n'est pas ISO alors que C l'est.
Et par ailleurs, utiliser le C en ne voulant respecter que la norme ISO, bah, euh, c'est ce que je disais, on ne peut rien faire!!!
Par ailleurs, un truc que je n'ai pas aborde plus haut: pourquoi se limiter au fait que C soit ISO et pas Java ? Si c'est Perl le langage le plus adapte a ce qu'on veut faire, Je trouve aussi mauvais de dire "Java n'est pas le bon langage parce que Java n'est ISO" que de dire "il faut utiliser C parce que C est ISO".
On s'en fiche, que ce soit ISO. Ce qui compte, c'est d'utiliser le langage le mieux adpte au besoin. Et d'utiliser les normes liees au langage en question. Les normes ISO et POSIX et d'autres si besoin pour le C, et la norme Java qui n'est pas une vraie norme (a moins que je ne sois mal renseigne) mais qui est definie par les specs de java (entre les mains de SUN - ce serait bien qu'un groupe independant en aie la maitrise).
Le bonjour chez vous,
Yves
[^] # Re: SUN annonce Mad Hatter
Posté par allcolor (site web personnel) . Évalué à 3.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 3.
Si pour toi une norme publique ne présente aucun intérêt, c'est pas étonnant...
« Et par ailleurs, utiliser le C en ne voulant respecter que la norme ISO, bah, euh, c'est ce que je disais, on ne peut rien faire!!! »
C'est bien tu l'as déjà dit. Même réponse : l'intérêt de la norme ne se trouve pas dans la création de programmes purement ISO.
« Par ailleurs, un truc que je n'ai pas aborde plus haut: pourquoi se limiter au fait que C soit ISO et pas Java ? Si c'est Perl le langage le plus adapte a ce qu'on veut faire, Je trouve aussi mauvais de dire "Java n'est pas le bon langage parce que Java n'est ISO" que de dire "il faut utiliser C parce que C est ISO". »
Et ? Évidemment, mais je n'ai pas dit le contraire dans la remarque initiale. Si on exclue Java parmi un ensemble de solutions, ce sera en raison d'un ensemble d'arguments. Qui a dit que C était forcément la solution qui s'imposait quand on veut un langage ISO ? Voilà encore une chose farfelue que tu as cru lire et qui n'était pas dite.
« On s'en fiche, que ce soit ISO. Ce qui compte, c'est d'utiliser le langage le mieux adpte au besoin. »
L'idéal serait de ne pouvoir prendre en compte que des considérations techniques évidemment. Le fait que ce ne soit pas ISO est un inconvénient qui s'ajoute éventuellement, c'est un problème indépendant du reste. Mais ça a des conséquences sur les outils, si Java avait été ISO et la JVM libre, le LL l'aurait bien plus utilisé, il y aurait plus de choix, plus de portabilité. Parce que Java est une option intéressante ou à envisager si on fait abstraction du coté proprio. Mais actuellement l'offre en outils est trop limitée (en diversité, Sun fournit beaucoup mais je parle de plusieurs fournisseurs) par rapport aux autres langages.
« (...) la norme Java qui n'est pas une vraie norme (a moins que je ne sois mal renseigne) mais qui est definie par les specs de java (entre les mains de SUN - ce serait bien qu'un groupe independant en aie la maitrise). »
Huh? Mais tu exprimes là exactement le reproche que l'on fait quand on regrette que Sun possède tout et que la norme ne soit pas ISO. Je ne sais pas ce que tu as imaginé mais il ne s'agit que de ça, et tu reconnais toi-même le problème. Problème qui ne sera pas forcément suffisant pour écarter systématiquement Java et lui préférer un langage comme C ou C++, mais c'est juste un argument parmi d'autres, qui apporte sa contribution dans un choix...
[^] # Re: SUN annonce Mad Hatter
Posté par a_jr . Évalué à 2.
J'ai pas compris ta reaction.
La norme ISO presente un interet! Mais pas question de s'y limiter pour le C.
Quant a Java, s'il faut creer une norme, ce n'est surement pas parce qu'elle existe pour le C. S'il faut la creer, c'est dans un besoin de normaliser Java, c'est tout.
Qui a dit que C était forcément la solution qui s'imposait quand on veut un langage ISO ? Voilà encore une chose farfelue que tu as cru lire et qui n'était pas dite.
Surement pas moi.
Au vu d'autres post precedents de ta part, je prefere te laisser me dire ou j'ai pu "croire lire ca" alors que "ce n'etait pas dit".
Et si ca doit degenerer en querelle de vocabulaire comme ca a ete le cas dans d'autres de tes posts, ou tes arguments etaient surement tres bons, mais pas directement en rapport avec mon propos, soit tu demarres un nouveau thread, soit tu me contactes par mail (un moteur de recherche te donnera mon adresse en quelques clics)
Le fait que ce ne soit pas ISO est un inconvénient qui s'ajoute éventuellement
Pas eventuellement, mais surement. Ca rassure les decideurs, que ce soit ISO. En ce qui concerne Java, c'est le fait que ce soit SUN qui decide de Java qui rassure les decideurs. Malheureusement, ce qui rassure les decideurs ici fait peur aux fervents programmeurs et utilisateurs du libre!
si Java avait été ISO et la JVM libre, le LL l'aurait bien plus utilisé
Seulement si la JVM avait ete libre. A moins que je ne me trompe, ni Perl ni Python ne sont ISO. Pourtant, personne ne dira le contraire quand je dis qu'ils sont tres utilises dans le libre!
Que Java soit ISO est par contre un plus.
Mais actuellement l'offre en outils est trop limitée (en diversité, Sun fournit beaucoup mais je parle de plusieurs fournisseurs) par rapport aux autres langages.
Trop limite pas en fournisseurs, mais en qualite chez les autres fournisseurs. Nous avons tout de meme une liste plutot pas mal ici: http://www.dwheeler.com/java-imp.html(...)
Dans cette liste, en libre, on trouve gcj, japhar, joeq, kaffe, latte, sablevm et surement d'autres (j'espere ne pas m'etre plante en lisant cette doc, car je ne connais pas ces logiciels a part kaffe et gcj)
Par contre, dans cette liste, je crois qu'il n'y a rien de convaincant par rapport a la jvm de Sun.
Huh? Mais tu exprimes là exactement le reproche que l'on fait quand on regrette que Sun possède tout et que la norme ne soit pas ISO. Je ne sais pas ce que tu as imaginé mais il ne s'agit que de ça, et tu reconnais toi-même le problème.
Pourquoi ce "huh" ?
Qui es-tu pour me dire "Je ne sais pas ce que tu as imaginé mais il ne s'agit que de ça, et tu reconnais toi-même le problème" ?
A nouveau, danakil, si t'as des reproches a me faire ou des attaques directes, tu n'auras aucun mal a trouver mon mail sur le net.
Le bonjour chez vous,
Yves
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 1.
Quant a Java, s'il faut creer une norme, ce n'est surement pas parce qu'elle existe pour le C. S'il faut la creer, c'est dans un besoin de normaliser Java, c'est tout. »
Tout à fait.
« Au vu d'autres post precedents de ta part, je prefere te laisser me dire ou j'ai pu "croire lire ca" alors que "ce n'etait pas dit".
Et si ca doit degenerer en querelle de vocabulaire comme ca (...) »
C'est pas du tout mon intention, on a pu mal se comprendre, et ça peut être de ma faute. Les forums web ont quelques inconvénients par rapport à Usenet, quelques citations auront manqué, ou auront été mal interprétées.
« Seulement si la JVM avait ete libre. A moins que je ne me trompe, ni Perl ni Python ne sont ISO. Pourtant, personne ne dira le contraire quand je dis qu'ils sont tres utilises dans le libre!
Que Java soit ISO est par contre un plus.»
Exact. Le problème avec Java est (était ?) qu'un implémenteur ne pouvait pas reprendre le nom de « Java » sans que Sun vérifie la conformité. Il ne s'agit donc pas que ce soit ISO, je suis d'accord, c'est plus large que ça.
« Trop limite pas en fournisseurs, mais en qualite chez les autres fournisseurs. (...) »
Oui, c'est bien dans ce sens là que je disais ça.
« Pourquoi ce "huh" ?
Qui es-tu pour me dire "Je ne sais pas ce que tu as imaginé mais il ne s'agit que de ça, et tu reconnais toi-même le problème" ?
A nouveau, danakil, si t'as des reproches a me faire ou des attaques directes, tu n'auras aucun mal a trouver mon mail sur le net. »
Aucun reproche ni attaques directe, il y a un truc sur lequel on s'est mal compris (peut-être de ma faute, je n'ai plus le thread en tête et j'ai la flemme de relire -- ça n'en vaut surtout pas le coup). Le « huh? » est juste une onomatopée de surprise... et je ne vois pas ce que tu as mal pris dans le reste (le "qui es-tu pour me dire..." ), en tous cas il ne fallait pas -- si je comprends bien, tu l'as lu comme si je parlais sur un ton de "donneur de leçon", je faisais juste remarquer qu'il y avait forcément méprise quelque part, n'y vois rien d'autre.
[^] # Re: SUN annonce Mad Hatter
Posté par Laurent Laborde (site web personnel) . Évalué à 2.
"
Pardon mais, faire du C purement ISO ca veut dire n'utiliser que les mot-clés du C pour vous ? Vous avez fumé ou quoi ?
Il me semble que l'ISO specifie le langage, et il n'interdit pas d'utiliser des librairies.
la norme defini une syntaxe et un "comportement" :
/* commentaire ANSI */
// commentaire pas ANSI
La norme definit qu'un char doit faire 1 byte, qu'on declare une struct de telle maniere et pas autrement, que le premier element d'un tableau est l'element 0, etc
Bref, je comprend pas votre troll... qui n'a aucun rapport avec Mad Hatters en plus.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 1.
Il me semble que l'ISO specifie le langage, et il n'interdit pas d'utiliser des librairies. »
Libs qui ne seront pas ISO, et pas forcément portable, donc pour être plus précis, leur remarque est correcte au sens strict, mais pour aller dans le sens que tu dis, on aura par exemple un noyau d'appli parfaitement ISO et des portions dépendantes de bibliothèques présentes et non ISO. Comme tu le dis, il ne s'agit pas que d'utiliser la définition du langage.
[^] # Re: SUN annonce Mad Hatter
Posté par tgl . Évalué à 3.
> La réponse à la question posée est donc non.
Alors que C# lui fait l'objet d'un "norme" ECMA.
...Aïe, nan, pas taper.
[^] # Re: SUN annonce Mad Hatter
Posté par Moby-Dik . Évalué à 3.
La perspective que Microsoft puisse implémenter un langage normalisé est-elle complètement inacceptable pour la pensée binaire moyenne de l'évangéliste open source ? ;)
[^] # Re: SUN annonce Mad Hatter
Posté par tgl . Évalué à 5.
- Parceque je ne considère pas du tout l'ECMA comme un organisme de normalisation (à la ISO par exemple). Va voir la liste de leurs standards, et tu verras qu'il s'agit juste d'un organisme assez marginal de publication pour grands industriels. D'ailleurs, tu en connais beaucoup toi des langages normalisés à l'ECMA à part le C# et l'ECMAscript ? Tu en connais des normes sans guillemets qui viennent de l'ECMA ?
- Parceque pour avoir lu en partie la dite "norme", ce que je ne te souhaite pas, je la trouve bourrée de lacunes et d'approximations, qui à côté feraient passer les docs de Sun sur Java pour une spécification formelle.
La perspective que Microsoft puisse implémenter un langage normalisé est-elle complètement inacceptable pour la pensée binaire moyenne de l'évangéliste open source ? ;)
Je constate simplement que Microsoft peux faire "normaliser" n'importe quoi, pour peu qu'on y mette des guillemets. Et je regrette bien sûr le manque d'originalité d'un tel constat, mais l'honneteté intellectuelle m'interdit d'en faire un différent.
[^] # Re: SUN annonce Mad Hatter
Posté par Christophe Fergeau . Évalué à 2.
[^] # Re: SUN annonce Mad Hatter
Posté par Laurent Laborde (site web personnel) . Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par a_jr . Évalué à 1.
Je ne sais pas si c'est a toi ou a tgl (post suviant) que j'aurais du repondre...
Mais il y a deux elements a prendre en comptes pour un programmeur qui participe au libre:
- Que Microsoft implemente une norme, et au vu du passe de Microsoft, ca fait peur. Et c'est je pense un a-priori, car si c'etait debian qui faisait cela (c'est surement pas le role de debian), les evangelistes open-source a pensee binaire moyenne crieraient au genie.
- Quand Microsoft implemente un langage qu'il ait pondu la norme ou que la norme vienne d'ailleurs, il y a des incompatibilites. Du moins avec la jvm de Microsoft. Je n'en sais pas assez pour dire si c'est le cas pour d'autres langages (je ne programme pas en visual C). Resultat, avec un tel passif, c'est normal que ca fasse peur. Peur, aussi bien a celui qui apprecie le libre qu'a l'evangeliste open-source a pensee binaire moyenne. Inacceptable, non.
Vu ton vocabulaire, c'etait evidemment de l'humour de ta part, avec un fond de serieux. je reponds dans le meme ton, mais je distingue bien l'evangeliste open-source a pensee binaire moyenne (c'est bien, c'est mal, mais y'a pas d'intermediaire) de la personne sensee :)
Le bonjour chez vous,
Yves
[^] # Normes ECMA et Microsoft
Posté par Marc Lacoste . Évalué à 4.
Non, ce n'est pas un a priori, il y a des précédents. J'aime bien le Rich Text Format comme exemple de norme made in MS. Ca part d'un bon principe, à la fin des années 80 : rendre les traitements de textes interopérables (oui, vous avez bien lu); voyant le manque de possibilités de transfert de données entre WordPerfect et WordPro, entre PC et Mac. Alors il font une norme de présentation de données, le RTF, qu'ils rendent publique. Elle reste propriétaire, mais est disponible, comme pour le PDF d'Adobe aujourd'hui.
La première version est disponible avec Word/Windows 3 en 92, et comprend les possibilités de ce dernier. Le RTF est assez vite repris par les autres traitements de texte, et un temps, ce fut bien ;). Mais Word progresse. La norme avec. Le RTF devient lourd, des problèmes d'incompatibilités apparaissent. Tant et si bien qu'aujourd'hui, Word ne respecte plus cette norme en totalité! Et les dévellopeurs d'OO.o préfèrent le .doc comme format d'échange.
http://marc.lacoste.free.fr/stage/rtf/(...)
La morale de cette histoire, c'est que Micrsoft est capable de pondre une norme, et même une bonne norme (on m'a dit que C# était pas mal), ou d'en suivre une. Mais ils ont une tendance forte, une fois qu'elle est acceptée, à déformer un peu leur interprétation. Oh, pas grand chose, rien d'énorme. Mais suffisamment pour qu'on pense que les autres ne la respectent plus. Ce n'est pas qu'ils soient fondamentalement mauvais, mais ce sont des gens capitalistes, qui veulent dévellopper au maximum leur profits en tirant parti de leur monopole de fait . C'est d'ailleurs l'assurance n°1 d'une forte rentabilité, et il est garanti par le gouvernement US qui le voit d'un bon oeil. N'importe quelle entreprise ferait la même chose.
Bon, j'arrête mon ton de grand-père Michel. Et je note que l'ECMA est fortement lié à l'ISO, alors, hein, la certif ISO du C... pareil.
Je n'aime pas trop les normes ISO, lourdes, bordéliques et payantes. Je préfère les dévellopements communautaires, plus pragmatiques, moins bureaucratiques. Par exemple, l'IETF a produit SMTP et LDAP, mises en oeuvre (et beaucoup) à x.400 et x.500 équivalentes qui ne sont pas suivies et sombrent dans l'oubli. Donc, j'apprécie le point de vue de Sun, qui ne veut pas donner d'armes à MS en normalisant java strictement, mais offre quand même de participer à son dévellopement via le JCP.
[^] # Re: SUN annonce Mad Hatter
Posté par Anonyme . Évalué à 3.
Mais alors qu'elle est l'application favorite de Java? Car dans le fond, on dit souvent, oui Java c'est *la* solution contre le mauvais code, contre l'incompatibilitée des plateformes, les effets de bord etc.
Pourtant, j'ai du code Java pourri de chez pourri, Java n'est pas si portable que ça (jamais pour une application qui employe beaucoup de lib ou un peu vieille), et quand il compilé en natif, je pense que les effets de bords sont pas si négligeable que ça...
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 1.
Il n'y a pas de réponse catégorique pour toutes les applications d'un certain type, mais ce serait le développement web ici. Swing peut aussi être une sérieuse motivation de choisir Java. Bien sûr c'est faire une généralisation, il y a des contre-exemples dans les deux sens...
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . Évalué à 3.
Sans être _la_ solution, Java a quand même permis d'éviter quelques petits pièges du C++ comme par exemple la gestion de la mémoire ou de simplifier certaines notions de l'objet comme le polymorphisme. Lors de tests de performance, j'ai constaté beaucoup moins de fuites mémoire sur des programmes en Java que sur des programme en C++ et pour ça le Garbage Collector est vraiment apréciable (non les smartpointers de la STL ne sont pas efficaces). Alors sans dire que Java a reglé tous les problèmes, on peut quand même dire que ça a amélioré certaines choses.
Pourtant, j'ai du code Java pourri de chez pourri, Java n'est pas si portable que ça (jamais pour une application qui employe beaucoup de lib ou un peu vieille), et quand il compilé en natif, je pense que les effets de bords sont pas si négligeable que ça...
Le code reste toujours écrit par un programmeur, ça n'a pas changé avec Java, il est toujours possible d'écrire comme un goret sans commenter son code et ce sera toujours comme ça avec ou sans Java. Quand à compiler en natif je ne vois pas l'intérêt à part peut-être un soucis de performance, et encore, mieux gérer les synchronized, éviter l'utilisation de trop d'objets temporaires couteux en mémoire et à la création, corriger les speed bottlenecks sont des solutions à envisager bien avant la compilation en natif.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 1.
Encore faut-il être compétent en C++. Je ne pense pas l'être assez et je me débrouillerais donc mieux en Java qu'en C++ de ce point de vue, mais quelqu'un qui maîtrise le C++ saura éviter bien des problèmes de mémoire parce qu'il fait du code propre et non du « C avec des classes ». Même sans parler d'utiliser les smart pointers de boost, rien qu'en utilisant bien la bibltiohèque C++ et en n'utilisant de la mémoire dynamique qu'en dernier recours, on évite bien des pièges. Beaucoup de gens n'utilisent pas assez ce qu'a apporté C++, c'est compréhensible pour plein de raisons, mais ça fausse la comparaison à mon avis.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . Évalué à 3.
Je ne parlais pas de ceux de boost en particuliers, je me suis mal exprimé, je voulais parler des pointeurs intelligents en général (smartpointers ... mélanger le français et l'anglais dans un commentaire n'est pas une bonne idée) style auto_ptr de la lib standard. Il y'a surement d'autres implémentations de pointeurs intelligents mais j'avoue que je ne fais plus beaucoup de C++ et que je ne me tiens plus vraiment au courant.
rien qu'en utilisant bien la bibltiohèque C++ et en n'utilisant de la mémoire dynamique qu'en dernier recours, on évite bien des pièges. Beaucoup de gens n'utilisent pas assez ce qu'a apporté C++, c'est compréhensible pour plein de raisons, mais ça fausse la comparaison à mon avis.
Qu'on implémente des pointeurs intelligents qui comptent les références sur eux montre bien que ce n'est pas aussi évident et que des fois ce n'est pas une question de maitrise du C++ : par exemple une méthode qui lève une exception et qui execute donc le code correspondant à la place du code prévu, des pointeurs qui pointent sur null ... ce genre de choses, sans compter les erreurs d'étourderie, qu'on ne peut pas toujours éviter bon codeur ou mauvais, font qu'un code n'a pas le comportement attendu. C'est un refrain connu le programmeur responsable qui alloue et désalloue la mémoire parfaitement sans jamais une erreur mais dans la vraie vie c'est rare ... très rare. Quant à utiliser l'allocation dynamique qu'en dernier recours c'est à mon avis très illusoire dès qu'on a besoin de conteneurs tels que vector ce qui est le cas dans beaucoup de programmes (voire la majorité), supposons que je souhaite aficher une liste de comptes rapatriés d'une base je suis clairement obligé d'allouer dynamiquement une liste, ce n'est qu'un exemple mais il y'en a des centaines dans les programmes.
Je suis d'accord avec toi pour dire que beaucoup de gens n'utilisent pas ce qu'a apporté le C++ mais ça n'enlève rien au fait que confier la gestion de la mémoire au programmeur n'est pas forcement une bonne idée et que justement Java corrige cette erreur (ça en induit d'autre comme par exemple quand la heap atteint le seuil de garbage collection trop vite et force le GC à s'executer dans des intervalles très courts ce qui impacte clairement la performance mais bon ce n'est pas le propos du thread). Pour moi le tort du C++ est clairement d'avoir voulu garder un rapport avec le C pour ne pas dépayser, Java a su au moins rompre l'héritage en utilisant un GC.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 2.
Tu insistes beaucoup sur les pointeurs intelligents, mais ce n'est pas à ça que je pensais, j'en ai parlé comme solution à envisager si on a besoin de mémoire dynamique, mais je pensais surtout à privilégier la mémoire automatique, et utiliser des références, pas des pointeurs. Ca peut paraitre évident, mais c'est une habitude trop peu répandue (surtout si on a fait du C avant).
Je ne suis pas trop d'accord avec ton exemple de liste avec vector ou autre conteneur : du moins dans l'exemple que tu donnes, on peut tout faire en mémoire automatique. Je ne dis pas qu'il n'y a pas de cas avec vector où il faut utiliser de la mémoire dynamique (avec des pointeurs dans le vecteur par exemple), mais on peut quand même souvent s'en passer. Et en plus la mémoire automatique est plus rapide, et tout se passe bien avec les exceptions...
Je suis bien d'accord que dès qu'il y a de la désallocation explicite à faire, les fuites sont quasi-inévitables. Mais je parle justement d'utiliser des méthodes qui ne nécessitent pas la désallocation : mémoire automatique surtout, pointeurs intelligents s'il faut du dynamique, et dynamique sans pointeurs intelligents en dernier recours, ce qui réduit considérablement les endroits où il y a des désallocations à faire. (Et je ne suis pas d'accord si tu dis que la mémoire automatique c'est laisser au programmeur la gestion de la mémoire. Quand on utilise des pointeurs oui, mais là ce n'est pas le cas)
Si mes souvenirs sont bons, Java ne propose pas de mémoire automatique, on passe toujours par un new ? Si c'est bien le cas, ça me paraît abusif de dire que Java corrige un problème de C++, parce que c'est en partie supprimer quelque chose d'utile et qui ne posait pas de problème. Mais je peux me tromper sur ce point, ou ça a peut-etre été introduit depuis ma dernière utilisation...
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . Évalué à 2.
Oui mais dès que tu as besoin d'instancier des classes tu utilises l'opérateur new et donc l'allocation dynamique (oui on peut parfaitement utiliser la pile et non la heap mais la pile n'est pas vraiment faite pour les objets donc on fait rarement de cette façon). On fait de l'objet ne l'oublions pas donc l'objectif est d'utiliser des classes. Dès que tu utilises des objets tu es pratiquement obligé de renoncer à la mémoire automatique et la desallocation se fait à la main. Si j'ai insisté sur les pointeurs intelligents c'est parce que ça montre un besoin de la part des programmeurs d'avoir un système de gestion mémoire automatique (ce que possède Java).
Je ne dis pas qu'il n'y a pas de cas avec vector où il faut utiliser de la mémoire dynamique (avec des pointeurs dans le vecteur par exemple), mais on peut quand même souvent s'en passer
Pour reprendre mon exemple, mes comptes ce sont évidemment des objets (ce n'était peut-être pas très clair) qui contiennent des informations relatives à chaque compte et à chaque nouveau compte récupéré j'instancie mon objet compte que je place dans un vector (de pointeurs à cause des objets que je mets dedans) à des fins d'affichage, dans ce cas on est d'accord j'utilise bien la mémoire dynamique et là si on place des objets compte chèque et compte titre qui sont dérivés de compte on doit effectuer le nettoyage à la main. On pourrait trouver des dizaines d'exemples du même type.
Et en plus la mémoire automatique est plus rapide, et tout se passe bien avec les exceptions...
Oui je suis d'accord mais avec cet exemple là :
Compte *l_compte = new Compte;
l_compte->changerProprietaire(nom);
//d'autres trucs ici
delete l_compte;
Si ma fonction lève une exception je ne passe pas au niveau du delete et mon pointeur n'est jamais libéré.
(Et je ne suis pas d'accord si tu dis que la mémoire automatique c'est laisser au programmeur la gestion de la mémoire. Quand on utilise des pointeurs oui, mais là ce n'est pas le cas)
Loin de moi l'idée de dire que des variables automatiques sont gérées par le programmeurs (quand même ! ;-), pour les pointeurs oui on est d'accord mais là où je ne suis pas d'accord c'est que ce n'est pas aussi simple que ça de ne pas utiliser de pointeurs. Tu inclus d'ailleurs dans ton raisonnement l'utilisation de pointeurs intelligents comme un "best pratice" pour faire du code sûr mais tout ça ce n'est en quelque sorte que du "bricolage" par rapport à ce qui est fait en Java ... c'est un peu comme dire qu'on peut faire de l'objet en C ... oui on peut mais ce n'est pas spécialement pensé pour. C'est la même chose avec le C++.
Si mes souvenirs sont bons, Java ne propose pas de mémoire automatique, on passe toujours par un new ? Si c'est bien le cas, ça me paraît abusif de dire que Java corrige un problème de C++, parce que c'est en partie supprimer quelque chose d'utile et qui ne posait pas de problème. Mais je peux me tromper sur ce point, ou ça a peut-etre été introduit depuis ma dernière utilisation...
Des variables ont des portées de bloc ou de méthode en Java aussi, elle n'ont pas le même scope et les variables locales sont aussi détruites en fin de bloc donc en ça, Java a aussi une gestion de la mémoire automatique. Java n'utilise pas de pointeurs mais des références et le new n'empêche pas de disposer d'une mémoire automatique.
Bref, Java a clairement été conçu pour être un dérivé simplifié de C++ et pour corriger certain défauts dont la gestion de la mémoire mais ça n'enlève rien à la qualité du C++ (ça reste un bon langage que j'aprécie beaucoup) et son utilisation massive le prouve mais je pense sincèrement que le jour où les perfs en Java seront équivalente au C++ ce sera la fin du C++.
[^] # Re: SUN annonce Mad Hatter
Posté par wismerhill . Évalué à 2.
Compte *l_compte = new Compte;
l_compte->changerProprietaire(nom);
//d'autres trucs ici
delete l_compte;
Si ma fonction lève une exception je ne passe pas au niveau du delete et mon pointeur n'est jamais libéré.
C'est très facile de régler ce problème.
Tu met le tout dans un try qui intercepte toutes les exceptions, si une exception survient tu libère ton pointeur et tu relance l'exception telle quelle.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . Évalué à 1.
Bof, on peut effectivement faire comme ça mais ce n'est pas très joli et question perf ce n'est pas terrible non plus.
[^] # Re: SUN annonce Mad Hatter
Posté par Moby-Dik . Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . Évalué à 1.
Comme le nom l'indique, ce n'est pas le but.
Qui a dit le contraire mais ça n'empêche qu'un programme doit avoir des exceptions et des méthodes pour les gérer.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 1.
Et tu les utilises très bien avec de la mémoire automatique, c'est la méthode normale, faire du dynamique c'est uniquement si on ne peut pas faire autrement. La pile convient très bien.
« Pour reprendre mon exemple, mes comptes ce sont évidemment des objets (ce n'était peut-être pas très clair) qui contiennent des informations relatives à chaque compte et à chaque nouveau compte récupéré j'instancie mon objet compte que je place dans un vector (de pointeurs à cause des objets que je mets dedans) »
C'était clair que c'était des objets, mais tu ne dis pas pourquoi tu utilises des pointeurs, ce n'est pas une obligation. Rien ne t'empêche de mettre tes objets nouvellement créés directement dans ton vector, sans passer par des pointeurs. Ou alors il y a une raison qui t'en empeche, mais celle-là tu ne l'as pas explicitée.
« Compte *l_compte = new Compte;
l_compte->changerProprietaire(nom);
//d'autres trucs ici
delete l_compte;
Si ma fonction lève une exception je ne passe pas au niveau du delete et mon pointeur n'est jamais libéré. »
{
Compte l_compte() ;
l_compte.changerProprietaire(nom);
// d'autres trucs ici
}
Que cette manière de faire ne convienne pas toujours, ok, mais dans le cas de ton exemple, je ne vois rien qui l'empeche.
« Tu inclus d'ailleurs dans ton raisonnement l'utilisation de pointeurs intelligents comme un "best pratice" pour faire du code sûr mais tout ça ce n'est en quelque sorte que du "bricolage" par rapport à ce qui est fait en Java ... c'est un peu comme dire qu'on peut faire de l'objet en C ... oui on peut mais ce n'est pas spécialement pensé pour. C'est la même chose avec le C++. »
Un pointeur intelligent là ou on pouvait utiliser de la mémoire automatique, c'est pas une « best practice » :) , à moins d'être très à l'aise avec ces derniers, personnellement j'éviterais. Les pointeurs intelligents je ne les indiquais que comme possibilités à envisager, j'insistais beaucoup plus sur la mémoire automatique. Ca ne parait vraiment pas plus « bricolage » qu'un « design pattern » quelconque, qu'un ramasse-miette, ou d'autres choses, le tout est de connaître l'outil qu'on utilise.
« Des variables ont des portées de bloc ou de méthode en Java aussi, elle n'ont pas le même scope et les variables locales sont aussi détruites en fin de bloc donc en ça, Java a aussi une gestion de la mémoire automatique. Java n'utilise pas de pointeurs mais des références et le new n'empêche pas de disposer d'une mémoire automatique. »
Ma question c'est : ces variables locales peuvent-elles être des instances de classe, et alors leur constructeur et la libération de mémoire est-elle faite à la fin du bloc ? Évidemmnent si j'ai parlé de pointeurs en Java il s'agit de références, ça va sans dire...
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . Évalué à 1.
Non, comme je le disais ce n'est pas la méthode normale. La pile n'est pas seulement disponible pour les variables locales, elle sert aussi à sauver le contexte d'exécution, l'exemple que je donnais était simple (je ne vais pas écrire une classe de 2000 lignes pour un exemple) mais supposons que j'utilise _beaucoup_ d'objets dans ma méthode, là le risque de dépassement est clair. En général on instancie pas d'objets sur la pile, le heap est parfaitement adapté comme espace utilisateur, d'autant que question sécurité utiliser la pile ce n'est pas vraiment terrible. D'ailleurs, Java ne place que des références sur la pile et jamais d'objets (ok pas pour les même raisons mais bon ... C# n'alloue jamais d'objets sur la pile non plus).
C'était clair que c'était des objets, mais tu ne dis pas pourquoi tu utilises des pointeurs, ce n'est pas une obligation. Rien ne t'empêche de mettre tes objets nouvellement créés directement dans ton vector, sans passer par des pointeurs. Ou alors il y a une raison qui t'en empeche, mais celle-là tu ne l'as pas explicitée.
Oui il y'a une raison qui est liée au conteneur, si je me souviens bien, on ne peut pas mettre des objets d'une classe de base et des objets de la classe dérivé dans ce conteneur (je ne me souviens plus la raison) ce qui implique qu'on utilise des pointeurs. Et là notre problème de libération mémoire se pose.
{
Compte l_compte;
l_compte.changerProprietaire(nom);
// d'autres trucs ici
}
Que cette manière de faire ne convienne pas toujours, ok, mais dans le cas de ton exemple, je ne vois rien qui l'empeche.
Oui bien sûr avec un exemple tel que celui-là (qui est décidement mal choisi), on peut utiliser la pile mais bon (cf quelques lignes plus haut). Eventuellement si on veut à tout prix utiliser la pile on peut mettre un pointeur sur la pile mais finalement ça revient au même vu qu'on sera tout de même obligé de supprimer le pointeur pour éliminer l'objet.
Ca ne parait vraiment pas plus « bricolage » qu'un « design pattern » quelconque, qu'un ramasse-miette, ou d'autres choses, le tout est de connaître l'outil qu'on utilise.
C'est un pattern justement ;-). Je trouve que c'est un bricolage parce que pour disposer de tous les avantages du java il faut bien choisir son pointeur intelligent (auto_ptr ne fonctionne pas avec la STL par exemple) et que ça crée des dépendances supplémentaires, bref c'est contraignant tout simplement parce que le langage n'a pas été prévu pour. Je me souviens d'un papier de Stroustrup parlant d'un GC pour C++ preuve que même son créateur est conscient que c'est une fonctionnalité qui manque.
Ma question c'est : ces variables locales peuvent-elles être des instances de classe, et alors leur constructeur et la libération de mémoire est-elle faite à la fin du bloc ?
Ok je n'avais pas compris. Quand on instancie un objet dans une méthode, la référence est effectivement libérée à la fin du bloc mais l'objet lui est toujours en mémoire et attends d'être éliminé par le GC. Le comportement n'est pas différent d'un new en C++ à la différence que ce n'est pas au programmeur de se soucier de l'élimination de l'objet. Pour les autres variables (types primitifs), comme je le disais, le système est le même qu'en C++, elles sont détruites en fin de bloc.
[^] # Re: SUN annonce Mad Hatter
Posté par Moby-Dik . Évalué à 1.
D'où viennent ce genre de recommandations ??
Au pire si tu ne veux pas mettre d'objet complexe sur la pile, et ne pas faire d'alloc manuelle non plus, tu peux utiliser un std::auto_ptr, hein... C'est pas sorcier.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 0.
D'un bouquin de de C ou de Java ;-)
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 1.
Là il y a un bouquin de C++ que tu dois brûler ou des personnes dont il faudrait arrêter d'écouter les conseils... Sérieusement.
« En général on instancie pas d'objets sur la pile, le heap est parfaitement adapté comme espace utilisateur, d'autant que question sécurité utiliser la pile ce n'est pas vraiment terrible. »
Ce n'est « en général » que si on s'obstine à appliquer en C++ des habitudes venant de C ou de Java. Sinon c'est à éviter quand on fait du C++. L'instanciation dont tu parles, dans la mémoire globale (et pas dans le heap, a priori, même si le compilo peut faire comme ça) n'est pas plus adaptée, juste plus coûteuse. Et évidemment amène les risques liés aux pointeurs. C'est un peu facile de ne pas prendre la solution normale proprosée par le langage, et ensuite de se plaindre des difficultés liées à une solution plus compliquée et contenant plus de risques, mais que tu a décidé d'utiliser.
« D'ailleurs, Java ne place que des références sur la pile et jamais d'objets (ok pas pour les même raisons mais bon ... C# n'alloue jamais d'objets sur la pile non plus). »
Ben c'est pas une référence puisque ces langages offrent moins de types de mémoire possibles. Je vois mal comment Java pourrait mettre autre chose que des références sur la pile puisque la durée de vie des objets n'est pas liée aux blocs... c'est normal vu les contraintes du langage.
« Oui il y'a une raison qui est liée au conteneur, si je me souviens bien, on ne peut pas mettre des objets d'une classe de base et des objets de la classe dérivé dans ce conteneur (je ne me souviens plus la raison) ce qui implique qu'on utilise des pointeurs. Et là notre problème de libération mémoire se pose. »
C'est parce qu'une copie est effectuée, qui va copier dans le type de base, enfin je suppose. Mais tu te places aussi dans un cas où des références plutot que des pointeurs ne conviennent pas, et où la libération des pointeurs poserait problème (contrairement à une utilisation généralisée de pointeurs, là on sait plus facilement où regarder). Boost propose aussi des pointeurs intelligents qui supportent la copie (donc la SL aussi)...
« Oui bien sûr avec un exemple tel que celui-là (qui est décidement mal choisi), on peut utiliser la pile mais bon (cf quelques lignes plus haut). »
Mais bon, t'as décidé de ne pas faire comme ça, ça me parait être la principale raison.
« C'est un pattern justement ;-). Je trouve que c'est un bricolage parce que pour disposer de tous les avantages du java (...) »
Tous les avantages de Java ? C'est une curieuse manière de voir les choses quand tant de choses sont supprimées et que l'on n'a plus le choix. L'avantage c'est juste qu'il y a un ramasse-miettes ; qu'il soit obligatoire n'en est pas forcément un.
Le GC est une solution qui peut convenir, ce n'est pas la solution qui corrige des difficultés du C++. Une solution digne de ce nom ne dégrade pas.
« je me souviens d'un papier de Stroustrup parlant d'un GC pour C++ preuve que même son créateur est conscient que c'est une fonctionnalité qui manque. »
Et ? Le fait que ça manque veut seulement dire que l'ajout des possibilités d'un GC serait un plus. Et ça parait évident. Mais il ne s'agit que d'un ajout, pas d'un remplacement... heureusement, en particulier puisque C++ possède des choses plus efficaces et simples, qu'il serait néfaste de supprimer (choix fait dans Java).
« Le comportement n'est pas différent d'un new en C++ à la différence que ce n'est pas au programmeur de se soucier de l'élimination de l'objet. »
Que le programmeur n'ait pas à s'en soucier, c'est l'avantage. Que ce soit « comme un new en C++ », c'est là l'inconvénient. En C++ justement on cherche à les éviter. C'est quand même bien porc de taper dans la mémoire dynamique quand on peut utiliser de l'automatique...
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . Évalué à 1.
Et moi je ne vois pas ce qu'il y'a de pas clair dans ce que j'explique. Comme je l'ai déjà dit, il y'a pleins de bonne raisons pour ne pas mettre d'objet dans la pile et pour toutes ces bonnes raisons ce n'est pas la méthode normale pour allouer des objets:
- La pile n'est pas un espace mémoire immense et mettre des objets (et a fortiori gros) dans la pile c'est s'exposer à un risque de stack overflow.
- Le programme sauvegarde son contexte d'execution dans la pile et ça implique des problèmes de sécurité puisque la pile est "executable". Le buffer overflow ce n'est pas seulement dans mes cauchemars.
Et il y'a aussi les problèmes dans le cas de programme multithreadé que j'avais oublié (merci pBpG). La pile n'est pas vraiment un espace thread-safe et effectivement on peut arriver à des résultats rigolos.
Utiliser la pile pour les types primitifs absolument je suis entièrement d'accord mais pour des objets non ou alors quand vraiment le besoin de performance se fait sentir. Là, il y a un bouquin de C++ que tu dois brûler ou des personnes dont il faudrait arrêter d'écouter les conseils... Sérieusement.
C'est un peu facile de ne pas prendre la solution normale proprosée par le langage, et ensuite de se plaindre des difficultés liées à une solution plus compliquée et contenant plus de risques, mais que tu a décidé d'utiliser.
Bien bien ok toi tu utilises la pile mais d'autres personnes non (sûrement des mauvais programmeurs) et dans ces cas là le problème se pose, tu peux retourner le problème dans tous les sens mais ça reste toujours la même chose : la gestion mémoire n'est pas simple et est source d'erreur (dans la vraie vie, dans les programmes des entreprises mais pas dans les tiens ok).
Le GC est une solution qui peut convenir, ce n'est pas la solution qui corrige des difficultés du C++. Une solution digne de ce nom ne dégrade pas.
Elle ne dégrade pas au contraire. Bon, sérieusement, j'ai fait de l'audit de code C++, j'en fais aussi (Java cette fois-c)i actuellement pour la boite ou je travaille et clairement le nombre de memory leaks est bien plus élevé dans le programme C++ que dans ce programme Java. Le GC est à mon avis plus efficace que des désallocations manuelles. En ça c'est une bonne solution, permettre d'avoir des programmes plus fiables c'est tout de même le plus important.
Pour finir, j'aprécie le C++ et ses qualités mais je l'ai assez pratiqué pour savoir qu'il a des défauts, que Java corrige entre autre. Après on peut se mettre la tête dans le sable et tout nier en bloc mais c'est un fait et probablement qu'un jour un langage corrigera les erreurs du Java. C'est tant mieux, c'est ça l'évolution.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 1.
Et moi je ne sais pas où tu as lu qu'il n'y avait pas de telles raisons.
« Utiliser la pile pour les types primitifs absolument je suis entièrement d'accord mais pour des objets non ou alors quand vraiment le besoin de performance se fait sentir. Là, il y a un bouquin de C++ que tu dois brûler ou des personnes dont il faudrait arrêter d'écouter les conseils... Sérieusement. »
Je crois que tu ajotues beaucoup de choses à ce que j'ai dit (en supprimant les nuances que je pense pourtant bien avoir ajoutées la plupart du temps). En particulier puisque tu parles d'objet de grande taille par exemple :-/
Je ne réponds pas sur le reste parce que je suis plutôt d'accord (ta comparaison avec les audits de C++ et Java ne me surprend pas quand du dynamique est utilisé (et il y en a forcément)). Quant à Java il ne s'agit pas de le dénigrer, je l'apprécie aussi ; et de manière très classique, dans un projet, si ses inconvénients ont finalement peu d'importance, ça fait un excellent choix. On s'est retrouvé à parler de Java mais ce n'était pas mon propos, je parlais juste de certains aspects trop souvent « sous-utilisés » de C++ (dont par exemple l'utilisation indirecte de mémoire dynamique en la « cachant » par des conteneurs en automatique -- note bien que ça ne veut pas dire que toutes les données se retrouvent sur la pile)
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par pasBill pasGates . Évalué à 3.
Toi t'as jamais eu de stack overflow...
La pile c'est pas fait pour mettre tout et n'importe quoi, sans compter que quand tu fais du multithread ca devient tres rigolo, tu passes a un autre thread ton element mis sur la pile, l'autre thread s'execute et pendant ce temps, ton thread depile, passe sur un autre appel et ecrase les donnees, le resultat est tres rigolo...
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par Christophe Fergeau . Évalué à 1.
c'est plus un pb de "je sais pas coder donc je fais n'importe quoi" qu"un pb de stack ou de multithread. Tu peux aussi allouer un object sur la pile et retourner son adresse dans un prog monothread et te demander pourquoi ca crashe tant que tu y es.
[^] # Re: SUN annonce Mad Hatter
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 1.
Sauf que tu ne veux pas lire la remarque dans le contexte de départ, mais dans celui que tu souhaites lui coller. Et là bien sûr ça n'a pas de sens.
[^] # Re: SUN annonce Mad Hatter
Posté par Moby-Dik . Évalué à 2.
Ah bon ? Pourquoi ?
Tu sais qu'on peut mettre le new dans un constructeur et le delete dans un destructeur d'une classe conteneur (ou dans des méthodes spécialisées), n'est-ce pas ?
Tu sais qu'on peut mettre des objets comme membres d'un autre objet (avec allocation auto) ?
Donc je ne vois pas en quoi on est obligé de faire de l'allocation manuelle. Evidemment en Java "new" est utilisé à toutes les sauces donc tu as l'impression que c'est obligatoire dans les autres langages...
[^] # Re: SUN annonce Mad Hatter
Posté par Ludovic Laurent . Évalué à 2.
http://glenn.sanson.free.fr/fb/(...)
[^] # Re: SUN annonce Mad Hatter
Posté par Thomas Cataldo (site web personnel) . Évalué à 3.
Le jeux "Vampire, the masquerade" est en Java.
> Est-ce que Java est porté sur plus de 11 architectures ?
Ben si tu considère gcj/gij alors oui
> Est-ce que Java peut tourner sur des machines avec très peu de ressources ?
Les téléphones portables, et les VMs pour PDA (J9 d'IBM par exemple)
Donc la réponse à tes questions est loin d'être non.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 4.
Le jeux "Vampire, the masquerade" est en Java.
> Est-ce que Java est porté sur plus de 11 architectures ?
Ben si tu considère gcj/gij alors oui »
Ca me parait un peu facile de faire des réponses indépendantes. Le problème de Java est justement que la JVM de Sun s'en sort bien sur quelques plateformes, mais se limite à ces plateformes et est propriétaire. Et la solution d'utiliser des alternatives libres est possible, mais risque de ne pas conserver les performances, le bon respect de la définition du langage, etc. C'est plutot ça qui est reproché à Java.
[^] # Re: SUN annonce Mad Hatter
Posté par thedidouille . Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par imr . Évalué à 2.
Non, ils ont utilisé java comme moteur de script du moteur de jeu.
When starting Vampire, we looked for ways to incorporate a scripting engine more easily than creating our own from scratch yet again. There were several scripting systems we examined and tested.
After a crash course in Java, we did a few simple tests incorporating it into our game engine. It passed each one with flying colors. In a matter of a few weeks, we had solved the major challenges involved in interfacing a standard, freely distributable Java virtual machine to our 3D RPG engine.
Ce n'est pas la même chose.
[^] # Re: SUN annonce Mad Hatter
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
Restons calme, il utilise java... pour les scripts. J'avais d'ailleurs pas trop compris a l'epoque, pourquoi utiliser java comme language de script. (utiliser un language de script dans un jeu oui d'accord, mais est ce que java est vraiment adapte ?). A tel point que je m'etais demandé si ils confondaient pas avec javascript :)
[^] # Re: SUN annonce Mad Hatter
Posté par imr . Évalué à 1.
http://www.gamasutra.com/features/20000802/huebner_02.htm(...)
(il faut appuyer trés vite sur stop pour lire l'article sans se logguer :)
Ce qui est interressant c'est que cette équipe avait créé un langage de script pour jedi knight avant de faire vampire et, dans cet autre article http://www.gamasutra.com/features/19990611/java_13.htm(...) , ils expliquent qu'en intégrant java, ils ont obtenu de meilleures perfomances qu'avec leur langage de scripts maisons sans avoir eu à passer plusieurs mois pour le développer et sans avoir eu de problémes à l'intégrer au moteur de jeu.
"The JVM is a lot faster than the systems we wrote ourselves; their kernel is more heavily optimized, the available Java compilers produce much more optimized object code, and the newest JVM systems include just-in-time (JIT) compilation to native instructions as a standard feature. And since the language is so much richer than our previous C-subset, it gives the designers a much wider range of possibilities."
Une fois l'article lu, ca semble en fait évident, à l'origine java était fait pour être embarqué, donc l'"embarquer" dans un jeu n'est pas trés compliqué et offre un bon rendement performance obtenue/travail fourni.
[^] # Re: SUN annonce Mad Hatter
Posté par amielp . Évalué à 1.
oui
http://java.sun.com/cgi-bin/java-ports.cgi(...)
et
http://www.geocities.com/marcoschmidt.geo/jvm.html#jdkjre(...)
[^] # Re: SUN annonce Mad Hatter
Posté par Nelis (site web personnel) . Évalué à 2.
http://www.roboforge.net/(...)
Oui oui, c'est du Java
[^] # Re: SUN annonce Mad Hatter
Posté par sandrake . Évalué à 3.
http://arkanae.tuxfamily.org/(...)
et une nouvelle version multi-joueurs en cours de développement :
http://www.arkanae.org/(...)
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . Évalué à 4.
On peut le faire en connaissant les deux. On peut aussi trouver de meilleurs langages que Java, sans être obsédé par un seul langage comme le C et donc préférer tel ou tel autre suivant le type d'application.
Sans parler de la portabilité et du coté propriétaire de la JVM sun.
[^] # Re: SUN annonce Mad Hatter
Posté par Anonyme . Évalué à 5.
http://linuxfr.org/2003/06/24/13002.html(...)
Ca pourrait etre pas mal, et permettrait surement de la porter sur de nouvelles architectures.
[^] # Re: SUN annonce Mad Hatter
Posté par Anonyme . Évalué à 7.
le createur de Java nous explique qu'ils n'ont pas voulu mettre la JVM en OpenSource pour eviter que n'importe qui sorte une version incompatible, comme ca a ete le cas avec Microsoft. Mais il estime que Java a bientot ateint un stade qui le permettrai de sortir une version OpenSource bientot.
[^] # Re: SUN annonce Mad Hatter
Posté par Moby-Dik . Évalué à -3.
A rien.
[^] # Re: SUN annonce Mad Hatter
Posté par Bungee Tux . Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par Moby-Dik . Évalué à 0.
[^] # Re: SUN annonce Mad Hatter
Posté par wistily . Évalué à 1.
# Modification apportées a Gnome ?
Posté par crevette . Évalué à 1.
Quelles sont elles ? Seront elles appliqué dans les version "officielles" Gnome (un peu a la Ximian)?
[^] # Re: Modification apportées a Gnome ?
Posté par thedidouille . Évalué à 1.
[^] # Re: Modification apportées a Gnome ?
Posté par Christophe Fergeau . Évalué à 1.
# Re: SUN annonce Mad Hatter
Posté par cozon (site web personnel) . Évalué à 3.
Même si pour Openoffice (enfin StarOffice), le support de Sun est plutôt logique, maintenant Sun a besoin de Mozilla et de Evolution, et il faut espérer qu'ils vont encore plus encourager ces deux projets.
# Re: SUN annonce Mad Hatter
Posté par Moby-Dik . Évalué à -10.
Et donc c'est censé constituer un concurrent frontal à Windows XP et Ms Office, ce tas de boue ??
Moi, je parie qu'ils sont morts de rire, les gars qui s'occupent de la veille concurrentielle à Redmond. Je voudrais être à leur place, juste une fois...
[^] # Re: SUN annonce Mad Hatter
Posté par Stéphane Traumat (site web personnel) . Évalué à 6.
Je travaille dans une SSLL qui développe des logiciels libres pour des entreprises et nous développons en Java (entre autre, mais aussi php, C... )
Java est vraiment ce que nous avons trouvé de mieux !
Nous pouvons développé les applications métiers de nos clients en Java ( client SWING ou WEB avec le sereur d'applications JOnAS ) et nos clients restent sous Windows...
une fois que nous avons développé les applications en Java, nous pouvons facilement proposé des migrations vers Linux ( cf. chronopost : http://www.indexel.net/doc.jsp?id=2313&origin=4(...) )
De plus, des choses comme JavaWebStart nous facilite la tâche en nous facilitant le déploiement.
Donc, si Java, c'est vraiment bien, vraiment pratique et crois moi que Microsoft a peur ( cf. ils ont enlevé la machie virtuelle de windows XP )
http://about.me/straumat
[^] # Re: SUN annonce Mad Hatter
Posté par Moby-Dik . Évalué à -4.
On parle d'une distrib orienté poste de travail bureautique, pas d'un environnement de développement. Tu commences à comprendre ?
[^] # Re: SUN annonce Mad Hatter
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
Tu dis : " Il n'y a aucune valeur ajoutée à part deux softs proprios hautement remplaçables (StarOffice -> OpenOffice, Java -> poubelle)"
Je te dis qu'un poste de travail alternatif à windows et comprenant java est très interessant pour de nombreuses boites (comme la note et comme chronopost)
Voila. Je te parle de poste de travail.
Un de nos clients qui possède un soft de CRM en java est en train d''envisager la migration
http://about.me/straumat
[^] # Re: SUN annonce Mad Hatter
Posté par Moby-Dik . Évalué à 1.
Au fait, rassurez-moi : "Mad Hatter", c'est un nom de code, hein ? C'est pas le nom définitif du bidule ?
[^] # Re: SUN annonce Mad Hatter
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Ca faisait du style "Ouais, pas besoin de java, personne l'utilise, les boites en ont rien à fouttre..."
Et pour être franc, je trouvais ca prétentieux... je ne m'aviserais pas de dire que le C ou le PHP ne servent à rien.
http://about.me/straumat
[^] # Le C c'est Bien!
Posté par Anonyme . Évalué à 1.
[ je suis déjà dehors ]
[^] # Re: SUN annonce Mad Hatter
Posté par jcs (site web personnel) . Évalué à 2.
C'est, je pense, un des grands avantages de Java : les applets et Java Web Start. D'ailleurs Microsoft n'a pas lancé .NET pour rien.
# SUN vs SCO
Posté par KDO . Évalué à 1.
[^] # Re: SUN vs SCO
Posté par cedric . Évalué à 2.
[^] # Re: SUN vs SCO
Posté par traboolix . Évalué à 1.
Quand au cote d'esthetique je le trouve pas mal pour un poste de travail et ca change du cde.Quand a gnome il est deja livre sous Solaris 2.9
[^] # Re: SUN vs SCO
Posté par Fox666 . Évalué à 1.
Message perso pour KDO:
Salut, je suis une ancienne connaissance (Fox, tu te rappel ?)
J'aimerais reprendre contact, c'est important, si tu lis ceci
écris moi a gvidal@softhome.net et dis moi comment
te contacter, merci !
# Re: SUN annonce Mad Hatter
Posté par superpop . Évalué à 6.
Et de l'autre, ils nous sortent un packaging composé en grande partie LL.
Chez Sun, ils ont un double langage j'ai l'impression .. Très proprio envers les managers, Très LL envers la communauté ....
Est ce que Sun aujourd'hui, c'est pas un peu SCO à son heure de gloire ?
Est ce que dans quelques années, si leur CA va mal et qu'ils sont au fond du gouffre, ne vont-t-ils retourner leur veste et par exemple faire payer Java ?
[^] # Re: SUN annonce Mad Hatter
Posté par a_jr . Évalué à 1.
J'imagine que tu voulais dire SCO au lieu de SUN ? Mais tout le monde aura corrige je pense.
Chez Sun, ils ont un double langage j'ai l'impression .. Très proprio envers les managers, Très LL envers la communauté ....
Est ce que Sun aujourd'hui, c'est pas un peu SCO à son heure de gloire ?
Sun me semble etre une entreprise qui s'adapte. Elle a mis le temps avant de sortir une offre Linux. C'est parce qu'elle n'etait pas en position de faire concurrence directe a Redhat ou d'autres distribs. Sun a du inventer un produit complementaire qui tienne compte des autres offres (Solaris entre autres, evidemment)
Par ailleurs, (attention le troll), ils font tres attention a la communaute. Ils ont fourni beaucoup de logiciels libres a la communaute, et pas des moindres. Pourtant, ils sont en position de pouvoir donner d'un cote et de vendre d'un autre cote. Et ceux qui paient attendent de payer, mais attendent un service que Sun leur fournit. C'est pour cela que tu as raison concernant le double langage. Mais Sun ne fait que s'adapter a ses interlocuteurs, tout en voulant gagner sa croute. Rien de plus!
(arf, si, surement, mais je ne suis pas dans le bureau du grand patron non plus)
Le bonjour chez vous,
Yves
[^] # Re: SUN annonce Mad Hatter
Posté par superpop . Évalué à 3.
Je parlais bien de Sun et pas de SCO. SCO a porté plainte contre IBM et lancer une bataille anti LL.
Mais Sun, en renouvellent son contrat avec SCO [http://zdnet.com.com/2100-1104_2-1024633.html(...)] en plein tapage médiatique est allé dans le sens de SCO. Ce qui est une manière très habile de discrediter les LL sans explicitement le dire ...Certains diront qu'ils font du Unix (Solaris) et qu'il est normal qu'ils paient la licence. Mais je trouve la coincidence assez grossière ....
C'est pourquoi je parlais de ce double langage.
a+
[^] # Re: SUN annonce Mad Hatter
Posté par a_jr . Évalué à 0.
Yves
# Re: SUN annonce Mad Hatter
Posté par Anonyme . Évalué à 7.
http://www.sun.com/smi/Press/sunflash/2003-08/sunflash.20030813.1.h(...)
Ils expliquent dedans que Mad Hatter pourrait etre la solution pour supprimer les nombreux problemes de securite que l'on rencontre sur Microsoft Windows, notament avec des virus comme MSBlast.
# Logo Sun Network
Posté par Ludovic . Évalué à 2.
http://sunnetwork.sun.com/(...)
http://orangina.fr/(...)
[^] # Re: Logo Sun Network
Posté par Matho (site web personnel) . Évalué à 1.
Surtout au niveau de leur stratégie. Enfin ce qui chez d'autres s'appele stratégie. Pke chez SUN, je ne suis pas sur qu'ils savent VRAIMENT ce qu'ils comptent faire dans les prochains mois.
Je vous laisse vous remémorrer la rumba de la distrib linux SUN, de son abandon, des solaris i386, des "SCO a raison, achetez du SUN" etc...
Secouez moi !!!! Secouez moi !!!!
Heu bon là ça suffit a force, ça va finir par me faire g*rber :/
[^] # Re: Logo Sun Network
Posté par Lionel Fournigault . Évalué à 0.
essayent de s'accrocher à Linux et au marché du PC.
Moi je me demande à qui ils vont pouvoir vendre cette chose surtout
que c'est pas très homogène au niveau du gui (staroffice + gnome) ca
la fout mal pour un desktop. Enfin bon ce que j'en dit.
[^] # Re: Logo Sun Network
Posté par Guillaume Proux . Évalué à -1.
(clin d'oeil d'un ancien de ya longtemps pendant pas longtemps...)
# [HS] DLFP est référencé par google news
Posté par Marc Lacoste . Évalué à 5.
la preuve par cette dépêche:
http://news.google.fr/news?q=mad+hatter(...)
Enfin, le pouvoir psychologique sur les esprits des plus grands DSI du pays de DLFP égale celui des plus nobles journalistes du milieu!
[^] # Re: [HS] DLFP est référencé par google news
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
[^] # Re: [HS] DLFP est référencé par google news
Posté par Gniarf . Évalué à 1.
(enfin si, autant les oublier)
[^] # Re: [HS] DLFP est référencé par google news
Posté par Rossel Olivier . Évalué à 1.
Allez hop, dos crawle dans la piscine ----------->[~~~ o|-< ~~~]
[^] # Re: [HS] DLFP est référencé par google news
Posté par traboolix . Évalué à 3.
Ils ont de l'humour chez Sun
[^] # Re: [HS] DLFP est référencé par google news
Posté par Laurent Laborde (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.