3 % d'après google et 1 % pour GNU/Linux (http://www.google.com/press/zeitgeist.html), et lorsqu'une tel partie des surfeurs n'a pas la possibilité d'avoir IE, les webmasters vont réfléchir à 2x avant d'obliger l'internaute à posséder IE...
Tu crois vraiment à ce que tu dis, là ? Dans n'importe quel contexte, 5%, c'est négligeable. Et si tu prends l'exemple des banques (qui ont un gros potentiel d'utilisateurs de services en lignes), je ne crois pas qu'elles se soucient toutes du respect des standards et autres.
Le problème d'IE, c'est plutôt dû aux incompatibilités de rendu entre versions, qui font qu'effectivement, bâtir un site pour IE, c'est un peu la guerre.
Mieux vaut, in fine, bâtir un site suivant les standards, car on peut être sûr qu'ils n'évolueront pas, plutôt qu'un site pour un navigateur, qui risque fort, un jour ou l'autre, de ne plus être vendu.
De plus, ca m'étonnerait qu'un utilisateur de Mac, après avoir connu Safari / Chimera avec les tabs (entre autres), réutilisent un browser tel que IE lorsqu'il est sous Win !
Boarf, j'ai pas le problème, j'utilise Opera partout :-)
Avant de critiquer la french-touch, essayez...
Je ne critique pas tant la french-touch que la manière dont la news a été produite. Sur le fond, vous avez évidement raison, si ça aide à faire baisser le prix du support, c'est toujours bien pour le client et pour le fournisseur.
En fait, c'est un reproche plus sérieux qu'on peut faire à JBoss, le côté pas vraiment Open-Source. En effet, si JBoss est en soi Open-Source, le fait que la doc soit presque exclusivement payante, et qu'elle soit nécessaire pour le mettre en oeuvre, en fait un outil à la limite, pour moi, des valeurs que représente l'Open-Source
Alors que le JBoss Group forke, ObjectWeb annonce officiellement son nouveau serveur d'application Open Source : JOnAS 3.1.
C'est toujours bien de commencer sa news par une bonne grosse polémique qui a à moitié rapport avec le sujet. Le fait que certains développeurs du JBoss Group (et développant donc JBoss) choisissent de quitter la société ne signifie en rien que le développement de JBoss va s'arrêter. MLais bon, ça n'a pas de rapport, à moins de vouloir comparer JOnAS et JBoss, ce qui ne serait pas une bonne idée.
La multiplication de ce type de produit Open Source « à qualité industrielle » est une bonne nouvelle pour tout ceux qui souhaitent développer des applications Internet ou intranet, sans être dépendant d'éditeurs comme IBM ou BEA.
Et aussi Oracle, tant qu'on y est. Cela dit, c'est effectivement très intéressant Pour les gens qui développent des applications basées sur J2EE.
Maintenant, je me pose une question, à propos de JOnAS. Est-il certifié J2EE, ou juste compatible J2EE ? A la lumière de l'expérience de JBoss, c'est une question qui mérite d'être posée, non ?
ObjectWeb est un consortium Open Source sans but lucratif, sur le modèle de la fondation Apache. Son objectif est de fournir un ensemble de logiciels middleware en Open Source. Il regroupe notamment l'INRIA, Bull, France Télécom...
Et malheureusement pour le développement de JOnAS, très peu d'acteurs du développement de ce serveur d'applications sont étrangers, ce qui limite forcément le déploiement de cet outil hors de nos frontières. De plus, la concurrence avec JBoss est assez dure à supporter, dans la mesure où JBoss dispose d'une base de téléchargements très importante (j'utilise ce chiffre car c'est le seul disponible).
Maintenant, le fait d'avoir deux projets OS de serveurs J2EE est dans l'absolu quelque chose de bien. Reste à savoir si les deux équipes peuvent soutenir les mêmes contraintes de développement. Et surtout, si elles peuvent suivre le rythme des sociétés commerciales.
Tu ne compiles pas ton programme pour une JVM, mais en Java. Et par conséquent, un code compilé avec le javac de Sun peut être exécuté sur la machine virtuelle IBM, ou inversement.
Donc déja, tu respectes une norme. Ensuite, cette norme est multi-plateforme, et donc s'exécute sur plusieurs OS. Personne dans le monde (pas ici, où les gens sont intelligents) ne semble se rendere compte que la vraie puissance de Java, c'est de prendre une application qui tourne sous Windows, genre un Word en java, et, simplement par un puissant copier/coller (SCP ou autres) être capable de la faire tourner avec tous les documents pour elsquels elle est faite sous Linux ou BeOS ou autres. C'est ça, la vraie puissance de Java. Le reste, c'est du pipeau marketting.
reste à esperer que cette version OpenSource sera 100% compatible avec le version Sun ! Ce serait etonnant, sinon la version Sun n'aurait plus raison d'exister...
Pourquoi ?
Il existe actuellement, dans le domaine Java, plusieurs environnements de développements Open-Source ou non, et ils coexistent tous "pacifiquement".
De la même manière, dans de nombreux contextes, on trouve des logiciels open-source et d'autres closed pour la même fonctionnalité, et chacun arrive à exister. Je ne vois pas pourquoi une machine virtuelle Open-Source tuerait celle de Sun (alors qu'il en existe déja plusieurs, ainsi que de nombreuses machines commerciales).
En lisant les commentaires, je vois que Java a rate son coup. Si j'ecrit un programme consequent en java, disons autour des 20000 lignes, genre un navigateur, j'ai combien de chance qu'il soit effectivement portable entre toutes les jvm ?
En théorie, toutes. Mais puisque tu sembles vouloir nous faire penser que la portabilité n'est pas atteinte, rajoutes-en une couche : sur combien d'OS tournera-t-il ?
En fait, il n'y a pas de problèmes entres différentes JVM de la même version du langage. C'est-à-dire différentes JVM 1.3, 1.4 ou bientôt 1.5.
Et si on ajoutes les versions, ca donne quoi ?
Les versions de quoi ? De ton programme ? De la JVM ? La portabilité est assurée entre différentes versions de la JVM Sun. Pour les autres, je ne m'avancerais pas.
Allez, on repart pour un tour de Java. Comme d'habitude, onv a avoir droit à l'avalanche de trolls, mais c'est pas grave...
Plus sérieusement,
littlewing nous tuyaute sur java.net
D'après ce que j'ai pu en voir, ce site est une tentative à la fois vers les développeurs et les utilisateurs, pour favoriser un peu Java qui souffre sur le bureau de l'utilsiateur.
Cyrille Morvan suit Zend et Sun au plus près :
Franchement ? C'est n'importe quoi ! Quand j'ai essayé le langage de compteurs, l'année dernière, la doc indiquait déja la possibilité d'utiliser du Java dans PHP. Mais j'imagine que ce genre d'annonces est là pour aider les décideurs pressés à créer leur site PHP avec un back-end J2EE, pour cumuler les avnatages.
Cependant, il est bon de rappeller que Java supporte déjà plusieurs langages de scripts (entre autre grâce à des projets opensource) : Python (Jython), JavaScript (Rhino), ColdFusion (macromédia), ...
Et aussi Java en tant que langage de script !
Et aussi le Scheme, et encore plein d'autres, mais il est toujours difficile de tous les lister.
Jerome Herman est notre envoyé spécial sur l'affaire Sun/Dell/HP :
Il ne faut pas se leurrer, cette annonce est essentiellement destinée à faire passer aux applets le saut conceptuel au-delà du JDK 1.1, et donc permettre les applets Swing, avec un peu de Java Web start, et toutes les vraies choses agréables. Bref, une autre preuve de la stratégie actuelle de Sun vers le poste de travail.
parasitid, développeur Java averti, se dévoue :
C'est vrai que cette version de NetBeans est la première développée hors du giron bienveillant de Sun, mais NetBeans est-il enfin agréable à utiliser ? Mystère !!!
leahpar nous colporte l'annonce du Club Java d'une discussion sur le LL :
Ayant été contacté par le sympathique organisateur pour y participer, je me permets de diffuser ici la partie signifiante du programme
9 H Accueil des participants, Petit Déjeuner,
9H 15 INTRODUCTION
L?évolution des relations entre JAVA et le logiciel libre.
9H30 La stratégie de SUN dans le logiciel libre au travers du JCP et des projets auxquels SUN contribue.
10H Une communauté française OPEN SOURCE : OBJECTWEB
10H 30 Pause Café
10H45 Une implémentation libre de J2EE : le serveur d?application JONAS
11H15 Une participation d?IBM au logiciel libre : ECLIPSE
11H45 Les développements de JDO pour ECLIPSE en logiciel libre par VERSANT
12H15 déjeuner
13H00 Les développements à l?aide de librairies libres d?ECLIPSE-UML
13H30 Un exemple de développement libre pour une Collectivité : LUTECE
13H40 Un exemple de développement libre pour une Collectivité : Conseil général du vald?oise
14H10 La compétitivité des Sociétés de Service en Logiciel Libre grâce à la réutilisation de composants libres
14H40 La problématique de l?utilisation de l?OPEN SOURCE
15H10 Le futur du logiciel libre et la modification des rapports entre éditeurs et clients finaux
Ca me lourde d'entendre que de soit-disantes vertus humoristique puissent être portées par des histoires où abonde la grossièreté. Et encore une fois, il ne s'agit pas d'une ou deux, puisque ça fuse en permanence.
Et quand c'est Bigard qui te sort un sketch sur le laché de salopes, qu'est-ce que tu fais ? Tu y vas, ou tu changes de station de radio ?
Si tu veux un bon échantillon de ce qu'on appelle courament de l'humour, tu mets Rires et chanson une journée, et u verras. Un conseil, éloignes tes enfants, c'est vraiment gras.
En l'occurence, j'ai branché ça ce matin en disant à mon fils, "viens je vais te faire écouter un truc marrant", faisant confiance au contenu du site et de la news. Bravo l'effet !
Attends, tu fais confiance à une bande de geeks pour le contenu éducatif des programmes ? C'est de l'aveuglement !
On est sur LinuxFr, ici, un site où l'usage veut que toute mentiond e Bill Gates provoque des poussées de trollitude, et toi, tu envoies ça dans les oreilles de ton marmot. Je suis étonné.
Où est l'avertissement ? Il n'y en a pas. Pourquoi ? Parce que la grossiereté est assimilée à une technique naturelle du discours, comme la guerre l'est à la diplomatie.
Non. Il n'y a pas d'avertissement car LinuxFr est un site de geeks pour des geeks, et que par conséquent on suppose que le lectuer est adulte, doté d'un sens critique plus ou moins certain, et qu'il prendra cela au second degré.
Il me semble que ce site n'est pas vraiment une bible en ce qui concerne les contenus ludo-éducatifs. Si ton fils a quatre ans, je te conseille plutôt www.tomlitoo.com
Cela devient écoeurant quand faute d'accepter le principe, on se fait traiter de casseur d'ambiance et exclure de la discussion par le vote négatif.
Là, si tu te fais moinsser, c'est vraiment parce que tu le vaut bien
La même technique est utilisée par le lobby de la cigarette : les "bons vivants", les "hommes libres", ce sont les fumeurs. Eux seuls savent ce qu'est vraiment le plaisir de la vie; et cela passe par l'emmerdement et l'ostracisme systématique de ceux qui ne sont pas d'accord et tentent de faire respecter leur espace vital (et leur droit). Bravo les valeurs.
Sauf que le lobby cigarettier est en pleine perte de vitesse, et qu'il n'est désormais plus rare de voir les fumeurs se faire demander poliment, mais fermemet, d'éteindre leur cigarette ou de se rendre dans un espace fumeur.
En ce qui concerne les "infos", si tu parles de la propagande télé et radio, Dieu merci on est encore libre de ne pas écouter et c'est ce que je fais. Mais lorsque mon gosse de 4 ans rentre de l'école en disant "Bande de pétasses", je fais quoi ? J'applique la mesure "faire attention" et je lui interdis l'école ?
A ton avis ?
C'est la vie en société qu'apprend l'école à ton enfant. Et nul autre que toi ne peut juger de ses méfaits. Maintenant, si tu apportes du poids, en le disputant, au fait qu'un gros mot, c'est mal, tu vas dans son sens.
Rien n'interdit de diffuser un roman audio gras dont la qualité humoristique repose sur la grossiereté. Mais ne comptez pas sur moi pour admettre la normalisation de la vulgarité qu'elle sous-tend.
Qui te parle de normalisation de la vulgarité ? Naheulbeuk doit être vu comme une outrance, un débordement. Et franchement, je trouve qu'il retrace bien le côté volontairement neuneu de la plupart des joueurs de JdR. Et cette vulgarité que tu fustige me semble bien au contraire tout à fait caractéristique du genre de partie que représente le Donjon.
N'oubliez pas de me noter -1.
Ce sera fait !
PS : J'ai fait du D&D il y a 10 ans ; je n'ai jamais rencontré le niveau de grossièreté du "donjon de Naheulbeuk"
Si tu jouais intelligement, ça ne m'étonne pas. Mais Naheulbeuk présente plus la partie de bourrins de base, qui abat tout le monde à vue.
Et ça t'arrive souvent de faire des "addListeners()" en boucle toi ? Bien sur que ça crée une instance de la classe, il faut bien qu'il y en ait une. Ou est le problème ?
Ca arrive lorsque, par exemple, les boutons ne sont pas recyclés, ou le code est généré, ou le développeur n'est pas très malin.
En gros, oui, ça arrive, et plus souvent qu'on ne croit.
Et pour parler d'autre chose que des listeners, on le fait souvent aussi lorsqu'on crée un FileFilter dans une méthode, et que cette méthode charge un ensemble de fichiers plusieurs fois dans l'application.
Enfin bref, il y a tout un tas de contextes où ça peut arriver, et surtout où ça risque d'arriver plusieurs fois dans la vie de l'application. Et si c'est à chaque fois qu'un bouton est affiché dans l'interface, ça peut monter très haut, et générer énormément d'instances, alors que l'utilisation d'un Listener codé dans une classe séparée est plus propre, et permet en outre de gérer ce pattern singleton.
Y'a aussi le problème des brevets et des copyrights détenus par Sun sur Java. MS et Jboss ont deja eu des problèmes avec Sun.
Tiens, un troll poilu qui remonte ?
Je te signale à tout hasard que le langage Java est libre, évolue suivant les désirs du JCP, une communauté ouverte, et qu'il existe aussi des JVM libres (certes un peu moins développées que les JVms commerciales).
Quant à MS et Java, je te laisse regarder les archives de LinuxFr pour y constater que les problèmes sont essentiellement dûs à la stratégie embrace and extend de Microsoft.
Enfin, pour JBoss et Java, la situation est beaucoup plus complexe. Il se trouve que la norme J2EE contient un certain nombre de limitations légales ou pseudo-légales qui restreignent les capacités de communication sur le code-source, et donc rend difficile la mise en place d'un serveur Open-Source J2EE. Ce qui n'a pas empêché JOnAS de passer avec succès cette certification. Le problème entre Sun et JBoss group est donc plus dû à des querelles politiques qu'à une réelle incompatibilité.
C'est d'ailleurs la même chose pour MS avec Mono .NET ...
Pas d'avis sur la question.
Mon pauvre ami. Et comment fais tu pour développer une application transactionnelle basée sur un système à échange de messages sans te faire chier comme un rat mort ? Parce qu'à part les J2EE et .Net, franchement, je ne vois pas.
Est-ce que j'ai dit que J2EE était merdique ? Non, je dis juste que les EJB, comme toute couche d'interface entre deux systèmes complètement différents, sont obligés d'utiliser le pire des deux systèmes.
Et puis, pour reprendre un argument d'un autre intervenant, tu connais beaucoup d'autres systèmes, à part effectivement les mainframes où l'usine à gaz est la règle, où ce soit le cas ?
C'est bien de défendre Java. C'est mieux de le faire bien.
Je défends Java comme j'aimerais le voir utilisé, c'est-à-dire en tant que vraie plateforme portable et transportable. Malheureusement, ce n'est pas encore assez le cas selon moi. Et J2EE ne fait rien pour ça.
Je suis d'accord qu'un programme basé sur une VM va forcément consommer plus de CPU/RAM. Mais ce dont on parle dans ce thread c'est bien des performances du langage, et pour cela il faut le comparer aux autres.
Et comment tu le compares aux autres sans utiliser la machine virtuelle ? Pour ma part, une comparaison de deux langages sous machine virtuelle serait une erreur, puisque ça correspond plus à une proof of concept qu'à une vraie utilisation. La seule comparaison qui vaille réellement est celle dans un environnement réel, en l'occurence ton OS préféré.
Que ce soit utile, cross-platform, facile à apprendre, souple et tout ce qu'on veut soit, je dis juste que c'est une belle pompe à RAM comparé à Perl par exemple (même si ce n'est pas tout à fait comparable
Donc tu compares avec la machine virtuelle, ce qui est normal puisqu'il s'agit d'un tout. Tu peux difficilement dissocier le langage de Java de sa plateforme et de ses bibliothèques.
Et au final, on est d'accord.
Oui, enfin, quand tu utilises une classe anonyme pour implémenter un listener, tu ne crèe qu'une seule instance, donc je ne vois pas où ça rame.
On parle bien de la même classe anonyme, là ?
Celle que tu définis avec un
addListener(new WindowListener() {
public void windowClosed() {
// je ne fais rien
}
// etc, ad nauseam
});
Celui-là, ?
Et bien dans ce cas, à chaque appel de la méthode où tu as ce code, tu crées une nouvelle instance de ta classe, par définition. Et donc, tu ralentis ton code.
Sinon, je suppose que tu décris un bug d'Eclipse, parce qu'une classe interne accède directement à tout le contenu de la classe englobante, même aux variables privées. C'est d'ailleurs un des intérêts des classes internes, par exemple pour implémenter des itérateurs.
Non, je décris le message d'information que peut te renvoyer Eclipse, avec une compilation un peu stricte, lors de l'utilisation de telles classes. Tout simplement parce que la création de l'accesseur synthétique est la seule méthode pour accéder à ces champs private.
Il y a d'autres métthodes que ces horreurs pour implémenter ces pointeurs sur fonctions, mais le débat n'est pas là. Ce n'est pas seulement le chargement de classes qui est long,c 'est aussi le fait qu'à chaque appel de la méthode définissant la classe, on crée une nouvelle instance. Et ça, c'est long.
Quant aux pointeurs sur fonctions, ils sont disponibles beaucoup plus facilement en utilisant correctement les interfaces. On appelle çàa du design by contract ;-)
Et pour les vrais porcs, il y a aussi l'objet Method qui, lui, est un vrai pointeur sur fonction, ou plutôt pointeur sur méthode.
Sans vouloir rentrer dans un méchant troll, il faut tout de même rappeler que y'a pas que le Java et la JVM... et sans vouloir polémiquer, il me semble qu'il y a des (au moins une) alternnatives qui propose les même avantages, sans les inconvénients et avec d'autres avantages... .NET pour ne pas citer d'exemple
C'est vrai que .NET est totallement portable sous Windows ;-)
La vraie portabilité de ce point de vue, c'est le C ANSI.
Tant qu'à avoir une indépendance vis-à-vis de la plateforme, autant l'avoir aussi vis-à-vis du langage... les coûts de conversion ou de formation s'en trouve diminuer, et on n'est plus limité par une grammaire... chacun choisi... (Csharp, C++, VB même sous nux, Python, Perl, Eiffel, CAML, j'en passe, et des meilleurs que Java sur bien des points).
Ce que tu oublies, c'est que Java est une machine virtuelle, il est donc possible d'utiliser d'autres langages que le Java sur une plateforme Java. La page http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html(...) liste les langages disponibles sous VM Java. on y trouve ainsi TCL, Lisp, BASIC, Logo, Prolog, Eiffel, Smalltalk, COBOL, ADA, Forth, Fortran, C (avec C2J), ...
L'argument me semble donc difficilement recevable ;-)
Sans parler de l'interopérabilité avec l'existant (COM, etc.)... encore du gain d'argent au développement pour un passage progressif...
Il existe également de nombreuses API d'interopérabilité COM/DCOM, dont notamment l'utilisation des EJB et de CORBA qui eprmet de dialogue r de manoière transparente avec DCOM.
Bref, même si c'est Microsoft qui a mis au point le premier environnement .NET digne de ce nom, je vois toujours pas pourquoi il n'est jamais mis en évidence face à Java... ou tout du moins face à la JVM (puisque on peut faire du Java sur une machine .NET, mais autant faire du Csharp :-p, clone plus évolué et moins limité )
Ah, j'avais pas vu que c'était un glorieux troll C#/Java, désolé.
Pour ce qui est des performances, il me semble qu'elle ne sont pas pire, tout du moins du même niveau.
Enfin bref, y'a des implentation libres de spécifications ouvertes qui existent, je vois toujours pas l'intérêt du Java face à ça...
Merci de ne pas me taper dessus :-)
Parce que java est lui aussi libre et ouvert, grâce aux langages déja cités, mais également grâce au JCP auqel tu peux participer pour faire évoluer Java.
L'idée de pouvoir développer des applications indépendantes de la plateforme est séduisante. Mais à quel prix ? Quand je vois le nombre de personnes qu'il est nécessaire de mettre sur un projet Java comparé à des environnements plus traditionnels (souvent un rapport 2 à 3), je m'interroge sur les gains in fine, en terme de gestion de projet, de conception, de développement et de maintenance.
J'aime bien ce genre de chiffres. Il faut mettre plus de personnes, mais tu ne nous dit pas que le projet est développé plus rapidement, ou que tes développeurs Java sont des mecs sous-payés.
Je trouve que l'on est arrivé à de sacrées usines à gaz - proprio ou pas.
Si tu me donnes l'exemple des serveurs d'application, je serais d'accord avec toi. C'est la plus mauvaise raison pour laquelle Java a perçé, alors qu'il est très fort dans bien d'autres domaines. Les EJB, c'est une espèce de merde noire où il faut, pour s'en sortir, faire appel à des vraies usines à gaz que sont les serveurs d'application. Mais sorti de là, Java marche très bien, se développe au moins aussi vite qu'un autre langage, et donne en plus un code largement plus clair que son équivalent C(++).
En outre, je constate (mais des exceptions peuvent exister, il faut l'espérer) que nombre de "spécialistes" Java sont malheureusement infoutus d'appréhender la notion de système d'information dans son entièreté et donc incapable de concevoir un projet ou ses modules.
Tu me parles du monde des SSII, et je te comprends. Les SSII sont la faillite de l'informatique moderne. On pense trop au salaire et pas assez à la technique. Si les gens se concentraient sur leur métier de technicien plutôt que sur celui de vendeur de patates chaudes, tu n'aurais sûrement pas ce discours.
J'ai pour ma part toujours travaillé chez des éditeurs de logiciel, et avec des gens compétents. A ceux-là, on ne demande pas de rendre le client heureux, mais d'implémenter telle fonctionnalité. Et dans ce cas, l'exigence technique rend le travail meilleur et personne n'est déçu.
Et une conception râtée, c'est un développement râté et donc un projet qui dérape et qui coûte la peau des fesses avant même la fin de la phase de recette.
Typique de la SSII.
Ma conclusion à moi, mais qui ne veut pas définitive, c'est qu'entre les nouvelles technos (pas si neuves que ça d'ailleurs), les envies de se faire plaisir/mousser, les incompétences et les coûts faramineux engendrés, tout ça ressemble à un air de pipot.
Les coûts faramineux ? En développement Java, qu'est-ce qui coûte de l'argent, hormis le salaire du développeur ? Rien.
Parce que le libre n'a pas de contrôloe sur l'évolution de Java ? Tu connais le JCP ? (http://www.jcp.org(...))
C'est un comité ouvert qui détermine les évolutions du langage. Et après, tu me parleras de la machine virtuelle, et je te répondrai qu'il en existe plusieurs pour chaque plateforme. Sun, IBM, Weblogic, et autres proposent des machines virtuelles, il n'y a donc pas trop de problèmes de ce côté-là.
J'ai bossé jusqu'au mois d'avril dans une boîte à Antony, qui s'appelle Ordinal technologies (http://www.ordinal.fr(...)), et qui produit un logiciel de supervision de chaînes de production entièrement codé en Java. Crois-moi, ça booste pas mal.
Je n'ai évidement pas de liens, pusique comme tu le dis, tous les tutoriels abusent de ces errements du langage.
Cependant, si tu essayes de coder sans, tu te rendras compte que le code est plus lisible, et donc plus maintenable et plus rapide (puisqu'il est plus facile d'optimiser quelque chose qu'on peut lire, et qu'en plus on ne crée pas une instance à chaque appel de méthode, la plaie de Swing).
C'est intéressant comme remarque car ça soulève un vrai point du Java. Ce qui est lourd en mémoire, c'est la machine virtuelle. Et personnellement, ça ne me surprend pas trop. En effet, cette machine virtuelle est un gros programme qui va transformer à la volée ton code. Tu t'attends vraiment à ce que ce soit léger comme code ?
Pas moi. Il est clair que si tu disposais d'un processeur Java, l'encombrement mémoire de tes programmes serait nettement moins lourd, puisque par exemple les classes System et compagnie ne seraient pas des émulations interrogeant la machine physique.
En l'occurence, ce n'est pas le cas, et il faut faire avec.
Cependant, la JVM 1.5 va apporter un début de réponse avec le mode serveur, qui permettra de lancer tous les programmes dans la même VM, plutôt que d'en lancer une par instance de JEdit ;-)
Elles le sont, par le simple fait que, à chaque passage dans la méthode qui crée l'instance, on recrée une nouvelle instance de cette classe alors qu'on aurait en général très bien pu utiliser l'ancienne instance. Ca, c'est pour les classes anonymes.
Pour les classes internes, écris-en une sous Eclipse qui accède aux données de la classe encapsulante et regarde le message d'erreur.
En clair, il dit qu'il doit créer une méthode accesseur, et passer de fait la visibilité de private à protected, juste pour ta pauvre classe interne. Tu aurais très bien pu coder toi-même une seconde classe, non interne, dans le fichier, qui fasse la même chose. Tu aurais alors nettement gagné en propreté des accès, et en évolutivité, puisque tu peux alors beaucoup plus facilement séparer tes deux classes.
[^] # Re: Futur flou pour IE ?
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Futur flou pour IE ?. Évalué à 4.
# Re: les chats c est tous des branleurs
Posté par Nicolas Delsaux (site web personnel) . En réponse au journal les chats c est tous des branleurs. Évalué à 0.
[^] # Re: MegaMek : un BattleTech en Java
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche MegaMek : un BattleTech en Java. Évalué à 3.
[^] # Re: « JOnAS » - un serveur d'application J2EE en Open Source
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche « JOnAS » - un serveur d'application J2EE en Open Source -. Évalué à 0.
Je ne critique pas tant la french-touch que la manière dont la news a été produite. Sur le fond, vous avez évidement raison, si ça aide à faire baisser le prix du support, c'est toujours bien pour le client et pour le fournisseur.
[^] # Re: « JOnAS » - un serveur d'application J2EE en Open Source -
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche « JOnAS » - un serveur d'application J2EE en Open Source -. Évalué à 6.
# Re: « JOnAS » - un serveur d'application J2EE en Open Source -
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche « JOnAS » - un serveur d'application J2EE en Open Source -. Évalué à 6.
[^] # Re: Red Hat préparerait une version Open Source de Java
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Red Hat préparerait une version Open Source de Java. Évalué à 2.
Donc déja, tu respectes une norme. Ensuite, cette norme est multi-plateforme, et donc s'exécute sur plusieurs OS. Personne dans le monde (pas ici, où les gens sont intelligents) ne semble se rendere compte que la vraie puissance de Java, c'est de prendre une application qui tourne sous Windows, genre un Word en java, et, simplement par un puissant copier/coller (SCP ou autres) être capable de la faire tourner avec tous les documents pour elsquels elle est faite sous Linux ou BeOS ou autres. C'est ça, la vraie puissance de Java. Le reste, c'est du pipeau marketting.
[^] # Re: Red Hat préparerait une version Open Source de Java
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Red Hat préparerait une version Open Source de Java. Évalué à 4.
Pourquoi ?
Il existe actuellement, dans le domaine Java, plusieurs environnements de développements Open-Source ou non, et ils coexistent tous "pacifiquement".
De la même manière, dans de nombreux contextes, on trouve des logiciels open-source et d'autres closed pour la même fonctionnalité, et chacun arrive à exister. Je ne vois pas pourquoi une machine virtuelle Open-Source tuerait celle de Sun (alors qu'il en existe déja plusieurs, ainsi que de nombreuses machines commerciales).
[^] # Re: Red Hat préparerait une version Open Source de Java
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Red Hat préparerait une version Open Source de Java. Évalué à 2.
En théorie, toutes. Mais puisque tu sembles vouloir nous faire penser que la portabilité n'est pas atteinte, rajoutes-en une couche : sur combien d'OS tournera-t-il ?
En fait, il n'y a pas de problèmes entres différentes JVM de la même version du langage. C'est-à-dire différentes JVM 1.3, 1.4 ou bientôt 1.5.
Et si on ajoutes les versions, ca donne quoi ?
Les versions de quoi ? De ton programme ? De la JVM ? La portabilité est assurée entre différentes versions de la JVM Sun. Pour les autres, je ne m'avancerais pas.
# Re: Dernières nouvelles du front Java
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Dernières nouvelles du front Java. Évalué à 2.
Plus sérieusement,
littlewing nous tuyaute sur java.net
D'après ce que j'ai pu en voir, ce site est une tentative à la fois vers les développeurs et les utilisateurs, pour favoriser un peu Java qui souffre sur le bureau de l'utilsiateur.
Cyrille Morvan suit Zend et Sun au plus près :
Franchement ? C'est n'importe quoi ! Quand j'ai essayé le langage de compteurs, l'année dernière, la doc indiquait déja la possibilité d'utiliser du Java dans PHP. Mais j'imagine que ce genre d'annonces est là pour aider les décideurs pressés à créer leur site PHP avec un back-end J2EE, pour cumuler les avnatages.
Cependant, il est bon de rappeller que Java supporte déjà plusieurs langages de scripts (entre autre grâce à des projets opensource) : Python (Jython), JavaScript (Rhino), ColdFusion (macromédia), ...
Et aussi Java en tant que langage de script !
Et aussi le Scheme, et encore plein d'autres, mais il est toujours difficile de tous les lister.
Jerome Herman est notre envoyé spécial sur l'affaire Sun/Dell/HP :
Il ne faut pas se leurrer, cette annonce est essentiellement destinée à faire passer aux applets le saut conceptuel au-delà du JDK 1.1, et donc permettre les applets Swing, avec un peu de Java Web start, et toutes les vraies choses agréables. Bref, une autre preuve de la stratégie actuelle de Sun vers le poste de travail.
parasitid, développeur Java averti, se dévoue :
C'est vrai que cette version de NetBeans est la première développée hors du giron bienveillant de Sun, mais NetBeans est-il enfin agréable à utiliser ? Mystère !!!
leahpar nous colporte l'annonce du Club Java d'une discussion sur le LL :
Ayant été contacté par le sympathique organisateur pour y participer, je me permets de diffuser ici la partie signifiante du programme
9 H Accueil des participants, Petit Déjeuner,
9H 15 INTRODUCTION
L?évolution des relations entre JAVA et le logiciel libre.
9H30 La stratégie de SUN dans le logiciel libre au travers du JCP et des projets auxquels SUN contribue.
10H Une communauté française OPEN SOURCE : OBJECTWEB
10H 30 Pause Café
10H45 Une implémentation libre de J2EE : le serveur d?application JONAS
11H15 Une participation d?IBM au logiciel libre : ECLIPSE
11H45 Les développements de JDO pour ECLIPSE en logiciel libre par VERSANT
12H15 déjeuner
13H00 Les développements à l?aide de librairies libres d?ECLIPSE-UML
13H30 Un exemple de développement libre pour une Collectivité : LUTECE
13H40 Un exemple de développement libre pour une Collectivité : Conseil général du vald?oise
14H10 La compétitivité des Sociétés de Service en Logiciel Libre grâce à la réutilisation de composants libres
14H40 La problématique de l?utilisation de l?OPEN SOURCE
15H10 Le futur du logiciel libre et la modification des rapports entre éditeurs et clients finaux
15H30 Pause Café
[^] # Re: Les aventures en mp3 continuent
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Les aventures en mp3 continuent. Évalué à 1.
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 0.
Ca arrive lorsque, par exemple, les boutons ne sont pas recyclés, ou le code est généré, ou le développeur n'est pas très malin.
En gros, oui, ça arrive, et plus souvent qu'on ne croit.
Et pour parler d'autre chose que des listeners, on le fait souvent aussi lorsqu'on crée un FileFilter dans une méthode, et que cette méthode charge un ensemble de fichiers plusieurs fois dans l'application.
Enfin bref, il y a tout un tas de contextes où ça peut arriver, et surtout où ça risque d'arriver plusieurs fois dans la vie de l'application. Et si c'est à chaque fois qu'un bouton est affiché dans l'interface, ça peut monter très haut, et générer énormément d'instances, alors que l'utilisation d'un Listener codé dans une classe séparée est plus propre, et permet en outre de gérer ce pattern singleton.
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 0.
Tiens, un troll poilu qui remonte ?
Je te signale à tout hasard que le langage Java est libre, évolue suivant les désirs du JCP, une communauté ouverte, et qu'il existe aussi des JVM libres (certes un peu moins développées que les JVms commerciales).
Quant à MS et Java, je te laisse regarder les archives de LinuxFr pour y constater que les problèmes sont essentiellement dûs à la stratégie embrace and extend de Microsoft.
Enfin, pour JBoss et Java, la situation est beaucoup plus complexe. Il se trouve que la norme J2EE contient un certain nombre de limitations légales ou pseudo-légales qui restreignent les capacités de communication sur le code-source, et donc rend difficile la mise en place d'un serveur Open-Source J2EE. Ce qui n'a pas empêché JOnAS de passer avec succès cette certification. Le problème entre Sun et JBoss group est donc plus dû à des querelles politiques qu'à une réelle incompatibilité.
C'est d'ailleurs la même chose pour MS avec Mono .NET ...
Pas d'avis sur la question.
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.
Est-ce que j'ai dit que J2EE était merdique ? Non, je dis juste que les EJB, comme toute couche d'interface entre deux systèmes complètement différents, sont obligés d'utiliser le pire des deux systèmes.
Et puis, pour reprendre un argument d'un autre intervenant, tu connais beaucoup d'autres systèmes, à part effectivement les mainframes où l'usine à gaz est la règle, où ce soit le cas ?
C'est bien de défendre Java. C'est mieux de le faire bien.
Je défends Java comme j'aimerais le voir utilisé, c'est-à-dire en tant que vraie plateforme portable et transportable. Malheureusement, ce n'est pas encore assez le cas selon moi. Et J2EE ne fait rien pour ça.
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.
http://java.sun.com/products/jfc/tsc/sightings/(...)
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.
Et comment tu le compares aux autres sans utiliser la machine virtuelle ? Pour ma part, une comparaison de deux langages sous machine virtuelle serait une erreur, puisque ça correspond plus à une proof of concept qu'à une vraie utilisation. La seule comparaison qui vaille réellement est celle dans un environnement réel, en l'occurence ton OS préféré.
Que ce soit utile, cross-platform, facile à apprendre, souple et tout ce qu'on veut soit, je dis juste que c'est une belle pompe à RAM comparé à Perl par exemple (même si ce n'est pas tout à fait comparable
Donc tu compares avec la machine virtuelle, ce qui est normal puisqu'il s'agit d'un tout. Tu peux difficilement dissocier le langage de Java de sa plateforme et de ses bibliothèques.
Et au final, on est d'accord.
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à -1.
On parle bien de la même classe anonyme, là ?
Celle que tu définis avec un
Celui-là, ?
Et bien dans ce cas, à chaque appel de la méthode où tu as ce code, tu crées une nouvelle instance de ta classe, par définition. Et donc, tu ralentis ton code.
Sinon, je suppose que tu décris un bug d'Eclipse, parce qu'une classe interne accède directement à tout le contenu de la classe englobante, même aux variables privées. C'est d'ailleurs un des intérêts des classes internes, par exemple pour implémenter des itérateurs.
Non, je décris le message d'information que peut te renvoyer Eclipse, avec une compilation un peu stricte, lors de l'utilisation de telles classes. Tout simplement parce que la création de l'accesseur synthétique est la seule méthode pour accéder à ces champs private.
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.
Quant aux pointeurs sur fonctions, ils sont disponibles beaucoup plus facilement en utilisant correctement les interfaces. On appelle çàa du design by contract ;-)
Et pour les vrais porcs, il y a aussi l'objet Method qui, lui, est un vrai pointeur sur fonction, ou plutôt pointeur sur méthode.
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 4.
C'est vrai que .NET est totallement portable sous Windows ;-)
La vraie portabilité de ce point de vue, c'est le C ANSI.
Tant qu'à avoir une indépendance vis-à-vis de la plateforme, autant l'avoir aussi vis-à-vis du langage... les coûts de conversion ou de formation s'en trouve diminuer, et on n'est plus limité par une grammaire... chacun choisi... (Csharp, C++, VB même sous nux, Python, Perl, Eiffel, CAML, j'en passe, et des meilleurs que Java sur bien des points).
Ce que tu oublies, c'est que Java est une machine virtuelle, il est donc possible d'utiliser d'autres langages que le Java sur une plateforme Java. La page http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html(...) liste les langages disponibles sous VM Java. on y trouve ainsi TCL, Lisp, BASIC, Logo, Prolog, Eiffel, Smalltalk, COBOL, ADA, Forth, Fortran, C (avec C2J), ...
L'argument me semble donc difficilement recevable ;-)
Sans parler de l'interopérabilité avec l'existant (COM, etc.)... encore du gain d'argent au développement pour un passage progressif...
Il existe également de nombreuses API d'interopérabilité COM/DCOM, dont notamment l'utilisation des EJB et de CORBA qui eprmet de dialogue r de manoière transparente avec DCOM.
Bref, même si c'est Microsoft qui a mis au point le premier environnement .NET digne de ce nom, je vois toujours pas pourquoi il n'est jamais mis en évidence face à Java... ou tout du moins face à la JVM (puisque on peut faire du Java sur une machine .NET, mais autant faire du Csharp :-p, clone plus évolué et moins limité )
Ah, j'avais pas vu que c'était un glorieux troll C#/Java, désolé.
Pour ce qui est des performances, il me semble qu'elle ne sont pas pire, tout du moins du même niveau.
Enfin bref, y'a des implentation libres de spécifications ouvertes qui existent, je vois toujours pas l'intérêt du Java face à ça...
Merci de ne pas me taper dessus :-)
Parce que java est lui aussi libre et ouvert, grâce aux langages déja cités, mais également grâce au JCP auqel tu peux participer pour faire évoluer Java.
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 2.
J'aime bien ce genre de chiffres. Il faut mettre plus de personnes, mais tu ne nous dit pas que le projet est développé plus rapidement, ou que tes développeurs Java sont des mecs sous-payés.
Je trouve que l'on est arrivé à de sacrées usines à gaz - proprio ou pas.
Si tu me donnes l'exemple des serveurs d'application, je serais d'accord avec toi. C'est la plus mauvaise raison pour laquelle Java a perçé, alors qu'il est très fort dans bien d'autres domaines. Les EJB, c'est une espèce de merde noire où il faut, pour s'en sortir, faire appel à des vraies usines à gaz que sont les serveurs d'application. Mais sorti de là, Java marche très bien, se développe au moins aussi vite qu'un autre langage, et donne en plus un code largement plus clair que son équivalent C(++).
En outre, je constate (mais des exceptions peuvent exister, il faut l'espérer) que nombre de "spécialistes" Java sont malheureusement infoutus d'appréhender la notion de système d'information dans son entièreté et donc incapable de concevoir un projet ou ses modules.
Tu me parles du monde des SSII, et je te comprends. Les SSII sont la faillite de l'informatique moderne. On pense trop au salaire et pas assez à la technique. Si les gens se concentraient sur leur métier de technicien plutôt que sur celui de vendeur de patates chaudes, tu n'aurais sûrement pas ce discours.
J'ai pour ma part toujours travaillé chez des éditeurs de logiciel, et avec des gens compétents. A ceux-là, on ne demande pas de rendre le client heureux, mais d'implémenter telle fonctionnalité. Et dans ce cas, l'exigence technique rend le travail meilleur et personne n'est déçu.
Et une conception râtée, c'est un développement râté et donc un projet qui dérape et qui coûte la peau des fesses avant même la fin de la phase de recette.
Typique de la SSII.
Ma conclusion à moi, mais qui ne veut pas définitive, c'est qu'entre les nouvelles technos (pas si neuves que ça d'ailleurs), les envies de se faire plaisir/mousser, les incompétences et les coûts faramineux engendrés, tout ça ressemble à un air de pipot.
Les coûts faramineux ? En développement Java, qu'est-ce qui coûte de l'argent, hormis le salaire du développeur ? Rien.
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.
C'est un comité ouvert qui détermine les évolutions du langage. Et après, tu me parleras de la machine virtuelle, et je te répondrai qu'il en existe plusieurs pour chaque plateforme. Sun, IBM, Weblogic, et autres proposent des machines virtuelles, il n'y a donc pas trop de problèmes de ce côté-là.
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.
Cependant, si tu essayes de coder sans, tu te rendras compte que le code est plus lisible, et donc plus maintenable et plus rapide (puisqu'il est plus facile d'optimiser quelque chose qu'on peut lire, et qu'en plus on ne crée pas une instance à chaque appel de méthode, la plaie de Swing).
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 2.
Pas moi. Il est clair que si tu disposais d'un processeur Java, l'encombrement mémoire de tes programmes serait nettement moins lourd, puisque par exemple les classes System et compagnie ne seraient pas des émulations interrogeant la machine physique.
En l'occurence, ce n'est pas le cas, et il faut faire avec.
Cependant, la JVM 1.5 va apporter un début de réponse avec le mode serveur, qui permettra de lancer tous les programmes dans la même VM, plutôt que d'en lancer une par instance de JEdit ;-)
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.
Pour les classes internes, écris-en une sous Eclipse qui accède aux données de la classe encapsulante et regarde le message d'erreur.
En clair, il dit qu'il doit créer une méthode accesseur, et passer de fait la visibilité de private à protected, juste pour ta pauvre classe interne. Tu aurais très bien pu coder toi-même une seconde classe, non interne, dans le fichier, qui fasse la même chose. Tu aurais alors nettement gagné en propreté des accès, et en évolutivité, puisque tu peux alors beaucoup plus facilement séparer tes deux classes.