Nicolas Delsaux a écrit 279 commentaires

Et je pense qu'il n'y a personne derrière, pas d'êtres humains, pas de conscience humaine, pas de vie au sens où nous l'entendons actuelleme
Tu lis trop l'ivresse des providers !

Mais "de bons présages" ("good omens" en vo), c'est encore plus terrible. C'est un quatre mains avec Neil Gaiman et là, le délire est à son comble. Comme si chacun voulait surpasser l'autre.

Disons que l'avantage, c'ests urtout que ce soit un 4 mains avec Terry Pratchett, dieu vivant du nonsense. D'un autre côté, c'est un peu normal pour un ancien attaché de presse de centrale nucléaire amateur de plantes carnivores.

Et puis, il faut voir l'informatique druidique du Disque-Monde !

Vous auriez pas des cassettes de best of queen dans vos voitures :))

Pas besoin, c'est automatique.

Il était temps que quelqu'un en parle !
N'étant pas lecteur d'Adams, je ne l'achèterais pas. En revanche, en tant que fan de Gaiman, je suis toujours très content de le voir écrire quoi que ce soit, surtout après avoir dévoré son recueil Miroirs et fumées (http://nicolas.delsaux.free.fr/web/Science-fiction/miroirs_et_fumee(...) ) qui vaut autant le coup d'oeil par les nouvelles qui y sont présentées que par les commentaires qu'en fait Gaiman.

si, mais il faut réfléchir un tout petit peu.
Oui, réfléchissons ensemble, encore une fois, sur le fait que le langage Java peut être utilisé dans un environnement libre.

allez, au pif : les classes java de base, ce qui fait le fichier rt.jar, tout ce qui rentre dans java.* et ceci inclut java2d aka Swing, les JFC, c'est libre ?

C'est défini intégralement par le Java Community Process (JCP) qui est une instance distincte de Sun. Celui-ci définit pour les versions à venir du langage et de la plateforme Java le contenu et la manière dont ce sera réalisé. N'importe qui peut se présenter pour participer à des JSR (Java specif... je-sais-plus-quoi). Ces JSR définissent chacune une fonctionnalité qui sera intégrée dans la prochaine version de la JVM. Par exemple, les JSR de Java 1.5 (que j'appelerais personnellement Java3) définissent la généricité (argl), les annotations (un truc formidablement génial) l'autoboxing des types primitifs (on se demande pourquoi ça arrive seulement maintenant), j'en passe et des meilleures.
Une fois les JSR adoptées, les fournisseurs de JVM divers (dont fait partie Sun) doivent implémenter celles-ci pour se voir reconnus fabricants de JVM.

c'est utilisable sans avoir à installer la JVM de Sun et en avoir accepté la licence et les conditions d'emploi ?

Oui, grâce aux JVM libres, ou en utilisant une JVM d'un autre fabricant de Logiciel (BEA, IBM)

oui, des implémentations compatibles au niveau de l'API existent ou sont en projet. mais ce n'est même pas sûr qu'on ait le droit de faire une implémentation libre de Swing/JFC

Bien sûr que si, ces classes sont une partie des APIs Java. En tant que telles, si les implémentations fournies dans la JVM sont la propriété de Sun, on est toutefois libre d'en faire d'autres.

sans devoir respecter certains points comme ne pas fournir de look&feel Windows ou Mac sous *nix, ou de look Apple depuis Windows.

Tu dis quand même un peu n'importe quoi. Les restrictions de look'n'feel ne sont pas le fait de Sun, mais de Microsoft et d'Apple qui ne souhaitent pas (ce que je peux comprendre) voir leur travail utilisé sans leur accord sur un système d'exploitation concurrent.
De la même manière, le fait que le look'n'feel Metal ne soit pas utilisable ne me dérange plas plus que ça.

je ne dis pas ici que Java c'est mal, je dis juste qu'il y aura les mêmes contraintes, légales sinon techniques, qu'avec .NET et Mono.

Pas du tout.

Ca me rappelle une fameuse idée noire de Franquin, ça :
tout homme en ayant volontairement tué un autre aura la tête tranchée.

Les deux derniers sortis en "papier" te pousse a te poser la question "comment va t il faire pour mettre la fille dans une position ou on voit la culotte les jambe ecartées?" plus que des question meta physique... enfin c'est plus ce que j'ai trouvé ;)

Oui, bon, effectivement, c'est un peu poussser mémé dans les orties pour mieux voir sa culotte. Mais je trouve quand même que les deux premiers tomes (ainsi, j'insiste, que tous ceux d'Apple Seed) sont très intéressants en terme de réflexion sur ce que peut être l'avenir de l'Humain.

Ne confondons pas le côté impressionant de la décapitation et sa sauvagerie réelle pour la victime.

En tout état de cause, je me demande bien quel est le but de cette polémique : il n'y a pas de bonnes peines de mort, car dans chaque cas, condamner un homme à mort revient, pour la justice qui le condamne, à s'abaisser au niveau d'un banal meurtrier.

Bref, nul n'en sort grandi.

Ghost in the shell est une oeuvre géniale qui pose des interrogation sur les interfaces homme-machines (bionique, cyborg...) et l'intelligence voir la conscience artificielle.

C'est vrai que je vois vachement le lien avec un système d'exploitation.

Plus sérieusement, une bonne partie de l'oeuvre de Masamune Shirow (Ghost in the shell, évidement, mais également, et au même niveau de complexité, Apple Seed) pose de très nombreuses questions sur l'avenir de l'humain, qui ne peuvent qu'intéresser tous les cyberpunks en puissance qui lurkent dans le coin.

Toutefois, d'une manière assez typique, j'aurais tendance à privilégier la version papier, qui permet plus aux interrogations de se manifester, vis-à-vis de la version filmée, qui offre peutêtre un plus beau spectacle, mais avec une profondeur moindre, tant il est vrai que la forme définit le fond.

J'avais posté il y a quelques temps un journal sur le même sujet, où j'expliquais que, grâce à Cygwin et XDMCP, j'arrivais depuis un Windows à ouvrir dans une fenêtre une session sur une machine Linux distante, le tout grâce au serveur X installé dans Cygwin.
Je ne vois donc pas où est le problème dans le lancement dans une fenêtre de cette connexion graphique...

C'est trop de l'hyperballe en boîte ce truc !
J'utilisais TextPad (payant, mais sans limite d'utilisation) et là, il vient de gicler pour ce merveilleux outil, d'une puissance incroyable, même si son ergonomie est un peu rustique.

D'ailleurs, je te plussoye tant que je peux.

A la base, Eclipse, c'est une plateforme de développement codée en Java. Je veux donc bien comprendre que le Java soit un peu mieux géré que les langages concurrents.
Et puis rien ne t'empêche de contribuer aux plugins pour PHP ...

J'ai developpé des petites applis J2EE avec XDoclet et Eclipse. Et franchement c'est de la balle, ca te ramène a un seul fichier pour un entity bean ou un session bean. Ca te développe des classes utilitaires autour de ce bean toujours pour le meme fichier. Et le must du must, ca gere automatiquement les CMR.

Et ça, c'est qu'un aspect de XDoclet. J'ai pour maa part essayé la partie génération de struts-config, qui est aussi pas mal. En fait, XDoclet n'a qu'un seul inconvénient : la doc est vraiment en retard de plusieurs versions, ce qui oblige l'utilisateur à aller faire un tour dans la javadoc pour se fixer les idées.

Ce qui manque maintenant, c'est une extension complete qui pilote le serveur EJB en mode debug et une meilleure integration des sources generés.
T'es sûr de ce que tu avances ?
Tu places tes sources générés dans generated_src, que tu places dans tes "source folders" d'Eclipse, ce qui va provoquer le compilation par Eclipse au même titre que les sources normaux.
Enfin, pour l'accès en mode debug, JPDA est ton ami. C'est très facile (par exemple avec Tomcat) de debugger à distance en utilisant cette infrastructure.

Je suis obligé de faire un rebuild all pour qu'il prenne en compte les changements dans les classes generées.

Et, euh, refresh ?

j'ai tout faux ?
OPui. il suffit de ne plus utiliser ni Outlook ni Outlook Express. C'est d'autant plus facile qu'un site comme www.arboase.org propose des dizaines de clients mails tous plus conviviaux et ergonomiques les uns que les autres (en tout cas nettement plus que les usines à gaz Crosoft).

Moi qui vous parle, j'utilise Opera pour le mail, et MyDoom me passe dessus, me repasse dessus, et essaye encore. Je ne sens absolument rien, et sais ne pas être infecté. le bonheur quoi : se balader au milieu d'un champ de batailles le nez en l'air ...

Ca fait quand même plaisir, des posts comme ça, où on comprend qu'apprendre l'anglais dispense de connaître sa langue maternelle.

J'aimerais bien que tu détaille.
Pour moi, ancien étudiant un informatique, SWING est le bidule qui permet à Java de proposer les interfaces graphiques les plus poussives depuis l'invention de l'interface graphique.

Ah bon ? peut-être est-ce dû au fait que tu effectues des opérations lourdes dans un thread dédié à l'affichage, thread déja un peu ralenti par l'utilisation d'un vrai MVC.

Dis tu que SWT est encore plus lent que SWING ?

Je dirais plutôt d'une vitesse comparable, mais avec des goulots d'étranglement différents.

Ou qu'il existe des pratiques mystérieuses permettant de rendre SWING utilisable ?
Aussi, oui : ne pas utilsier le thread d'affichage pour effectuer les traitements sur le modèle, par exemple (grâce au SwingWorkerThread, c'est possible et facile), utiliser des événements adaptés aux traitements à effectuer (typiquement, éviter les mouseListener et keyListener), bref, coder intelligement.

Comment mesures-tu la performance et l'utilisabilité des deux toolkits ?

L'utilisabilité, c'est facile : essaye de développer une application avec Swing, puis avec SWT, et compares tes difficultés : avec Swing, elles viendront la plupart du temps d'une mauvaise compréhension des événements et du modèle utilisé. Avec SWT elles viendront surtout du fait que l'API est pauvrement documentée, difficilement extensible, et assez peu portable.

Tu oublies Swing sightings : http://java.sun.com/products/jfc/tsc/sightings/(...)

On voit bien que tu ne t'en es jamais servi ! Idea est l'un des meilleurs IDE existants en Java, et justement son interface est très pratique et utilisable.

L'IDE Java open-source est un peu trop sous l'emprise d'IBM au goût de Sun.

Pas forcément que du goût de Sun. IBM est au coeur du consortium Eclipse et, comme je l'ai déja dit dans un commentaire précédent, la participation de Sun à Eclipse ne faisait pas partie des choses intelligentes, ni même politiquement pertinentes.

Le rapprochement prévu de NetBeans (IDE Sun maison) avec Eclipse est par la même annulé.

Ce rapprochement, rêve de geek, est un truc à plusieurs année/homme de travail, juste pour avoir deux IDEs ressemblants. Il n'a rien d'utile, ni de raisonnable.

Encore une fois Sun se crispe et résiste en allant à l'encontre de l'intérêt général et de celui de Java.

Ben voyons ! Parce qu'Eclipse est l'avantage de Java, tu crois ? Eclipse (et surtout sa base, SWT) est une tentative d'IBM de prendre la main sur les interfaces Java. Ca n'a rien de philantrope, c'est un jeu politique pour favoriser le développement d'applications Java à partir de leur API (pas plus OS que celle de Sun).
Donc, dans ce contexte, dire que Sun va a l'encontre de l'intérêt de Java est peut-être le pire contresens à faire. L'intérêt de Java est exactement que Sun ne participe pas à Eclipse, pour la bonne et simple raison que Swing est de loin plus performant et utilisable que SWT, et qu'un des axiomes de base du monde du libre est ainsi respecté : le choix est possible entre Swing et SWT.

Tu devrais aller poster ta question sur news:fr.comp.lang.java, tu aurais plus de réponses.
Mais en bref :
- Java peut être très réactif, pour peu que tu saches coder (ce qui n'est générallement pas le cas, d'où la lenteur des applis).
- Le manque d'exécutable n'est pas un problème sous Windws. Ce qui l'est, c'est le manque d'un raccourci dans le menu démarrer.
- Et puis, vas donc t'amuser avec les toolkits super-portables à la Linux, qui vont te faire de garanties moches applications sous Windows.

Mais je n'arrive pas à comprendre comment ça fonctionne... d'un coté vous avez le CD, de l'autre vous avez la RAM qui est trop petite pour contenir l'application et normalement, y'a pas de HD pour swapper...

Normallement ?
Pourquoi n'imaginerait-on pas que Knoppix est capable, à un moment ou un autre, de voir si il y a un disque dur, puisque d'ailleurs on peut y lister le contenu des disques, de lire la table d'allocation, et d'utiliser comme un swap une partie vierge d'un disque dur ?

Faudrait quand même parfois éviter de raconter des conneries grosses comme ça.
Il est évident que Sun ne pouvait pas adhérer au consortium Eclipse, car celui-ci base tout son travail sur SWT qui est, de la part de tous els acteurs de ce consortium, un désaveu de Swing et un moyen de prendre la main sur Java.
D'autre part, la fusion entre Eclipse et NetBeans me semble être plus un rêve d'un béotien qu'autre chose : ils ne s'appuient pas sur les mêmes plateformes (SWT/Swing) n'utilisent pas les mêmes concepts et n'ont pas les mêmes objectifs.

Quant à renforcer la résistance blablabla, arrête de me faire rire ! .Net doit sûrement être déja plus utilisé pour les applications desktop que Java (même si personnellement, ça me fait vraiment mal).

Euh? Une page JSP est dans tous les cas transformée
en une classe java étendant Servlet, puis compilé
pour l'execution.

Oui, tout à fait.

A ma connaissance c'est toujours précompilé, ou par
tomcat , ou par javac manuellement dans le cas du déploiement
d'un .war, c'est bien des binaires java qui sont manipulés ...
C'est Tomcat (ou un quelconque serveur de jsp) qui va les compiler. Ce que je comprend de cette phrase, c'est qu'il est possible d'invoquer séparément (par exemple dans un IDE) la classe qui fait cette précompilation pour pouvoir vérifier les erreurs d'écriture qui peuvent se glisser dans la jsp. Et ça, c'est un avantage significatif !

Quelques infos : http://www.open-j2ee.org/opencms/opencms/fr/articles/j2ee/j2ee_jmx.(...)

Pour faire ultra-simple, c'est une API de téléadministration apparement compatible avec SNMP

(En gros) Je veux faire une implementation DOM qui au lieu d'etre sauvée sur disques est stockée dans la une bdd.

Je ne vois pas du tout l'intérêt. pourquoi ne pas, par exemple, stocker ton document XML dans un annuaire Ldap, par exemple, qui offre une plus grande ressemblance de format ?
Et pourquoi ne pas décomposer ton fichier XML en fragments ? il me semble qu'il existe pour cela une spécification du W3C, mais je n'en suis pas si sûr.

Pas mal d'avantages : on peut avoir une notion de trasaction (modifier plusieurs section de documents et faire un commit par exemple),

La transaction est la béquille de l'informatique.

gerer certaine zone d'un document (et ne pas charger tout le fichier en mémoire) à l'aide des requete XPath/Xquery (pour lire certaine zone du document, ou faire des recherche dans les documents).

Il me semble que XQuery devrait pouvoir faire ça d'emblée, non ?

De plus cela permet de s'interfacer en transparence avec des outils existant de gestion de flux XML

Gni ?

fallait le dire, que c'était du Java ! Tu veux faire quoi, en vrai (parce que la persistance, c'est le concept haut-niveau) ?
- Sauver tes objets Java en XML ? Utilises les XMLEncoder et XMLDecoder fournis avec ton JDK.
- Parser un fichier de config écrit en XML ? Utilises le digester Apache.
- Obtenir une bijection entre tes objets Java et tes fichiers XML ? Effectivement, dans ce cas-là, Hibernate est une bonne solution, mais tu vas devoir te plonger dans les arcanes de ces mécanismes, de la modification à chaud de bytecode, et du mapping Objet/Data. Bon courage ;-)