Sun a finalement annoncé le passage prochain de son langage Java, en
Open Source.
L'hésitation porte à l'heure actuelle sur le type exact de licence, Sun
voulant garder la main sur le langage.
Quoiqu'il en soit le code de Java sera ouvert.
Cela va t-il sonner le glas pour les techno .NET ?
Je cherche sur CPAN, je ne trouve qu'un module pour les catalog "John Cowan", ("XML::Catalog"),
Je voulais dire : ce format n'est plus à jour, il y a maintenant un format Oasis (pour lequel il y a une libraire dans xml-commons de Apache), je ne vois rien pour ce format sur CPAN. En fait je ne trouve pas que ça ait beaucoup changé depuis la dernière fois que j'ai regardée, il y a quatre ou cinq ans.
Surtout ce qui est très utile dans les API XML de java c'est le degré d'intégration de tous les composants : ils partagent tous des interfaces et sont véritablement interchangeable. Par exemple les factory de javax.xml.parsers retournent le premier parseur DOM ou SAX trouvé sur le système (que ce soit Xerces, Saxon, ou un autre) ; idem pour javax.xml.transform.dom et javax.xml.transform.sax qui retournent le premier processeur XSLT trouvé pour un objet DOM ou pour un flux SAX, etc. Avec Java 5 il y a la même chose pour obtenir un processeur XPath (javax.xml.xpath) ou un parseur validant (javax.xml.validation) ; les API sont toujours les mêmes (SAX et DOM), on peut donc facilement brancher un flux SAX sur un handler qui fait une transformation XSLT (qui construit la collection d'objets, la transforme, et la reconvertie en flux SAX), etc. etc.
Dans java 5 xerces et Xalan sont intégrés à la JRE (ce qui n'est pas vraiment un cadeau, Xalan est proche du record de la lenteur avec XSLT).
Je cherche sur CPAN, je ne trouve qu'un module pour les catalog
"John Cowan", ("XML::Catalog"),
Je voulais dire : ce format n'est plus à jour, il y a maintenant un
format Oasis (pour lequel il y a une libraire dans xml-commons de
Apache), je ne vois rien pour ce format sur CPAN. En fait je ne trouve
pas que ça ait beaucoup changé depuis la dernière fois que j'ai
regardée, il y a quatre ou cinq ans.
Surtout ce qui est très utile dans les API XML de java c'est le degré
d'intégration de tous les composants : ils partagent tous des
interfaces et sont véritablement interchangeable. Par exemple les
factory de javax.xml.parsers retournent le premier parseur DOM ou SAX
trouvé sur le système (que ce soit Xerces, Saxon, ou un autre) ; idem
pour javax.xml.transform.dom et javax.xml.transform.sax qui retournent
le premier processeur XSLT trouvé pour un objet DOM ou pour un flux
SAX, etc. Avec Java 5 il y a la même chose pour obtenir un processeur
XPath (javax.xml.xpath) ou un parseur validant (javax.xml.validation)
; les API sont toujours les mêmes (SAX et DOM), on peut donc
facilement brancher un flux SAX sur un handler qui fait une
transformation XSLT (qui construit la collection d'objets, la
transforme, et la reconvertie en flux SAX), etc. etc.
Dans java 5 xerces et Xalan sont intégrés à la JRE (ce qui n'est pas
vraiment un cadeau, Xalan est proche du record de la lenteur avec
XSLT).
Je cherche sur CPAN, je ne trouve qu'un module pour les catalog "John Cowan", ("XML::Catalog"),
Je voulais dire : ce format n'est plus à jour, il y a maintenant un format Oasis (pour lequel il y a une libraire dans xml-commons de Apache), je ne vois rien pour ce format sur CPAN. En fait je ne trouve pas que ça ait beaucoup changé depuis la dernière fois que j'ai regardée, il y a quatre ou cinq ans.
Surtout ce qui est très utile dans les API XML de java c'est le degré d'intégration de tous les composants : ils partagent tous des interfaces et sont véritablement interchangeable. Par exemple les factory de javax.xml.parsers retournent le premier parseur DOM ou SAX trouvé sur le système (que ce soit Xerces, Saxon, ou un autre) ; idem pour javax.xml.transform.dom et javax.xml.transform.sax qui retournent le premier processeur XSLT trouvé pour un objet DOM ou pour un flux SAX, etc. Avec Java 5 il y a la même chose pour obtenir un processeur XPath (javax.xml.xpath) ou un parseur validant (javax.xml.validation) ; les API sont toujours les mêmes (SAX et DOM), on peut donc facilement brancher un flux SAX sur un handler qui fait une transformation XSLT (qui construit la collection d'objets, la transforme, et la reconvertie en flux SAX), etc. etc.
Dans java 5 xerces et Xalan sont intégrés à la JRE (ce qui n'est pas vraiment un cadeau, Xalan est proche du record de la lenteur avec XSLT).
Emmanuel Florac
Le Tue, 23 May 2006 14:13:50 +0200, SL a écrit :
Surtout ce qui est très utile dans les API XML de java c'est le degré d'intégration de tous les composants
Heureusement dans Perl on peut utiliser les API Java grâce à Inline::Java.
-- Je suis riche des biens dont je sais me passer. Louis-Jean-Baptiste Etienne Vigée.
Le Tue, 23 May 2006 14:13:50 +0200, SL a écrit :
Surtout ce qui est très utile dans les API XML de java c'est le degré
d'intégration de tous les composants
Heureusement dans Perl on peut utiliser les API Java grâce à
Inline::Java.
--
Je suis riche des biens dont je sais me passer.
Louis-Jean-Baptiste Etienne Vigée.
Surtout ce qui est très utile dans les API XML de java c'est le degré d'intégration de tous les composants
Heureusement dans Perl on peut utiliser les API Java grâce à Inline::Java.
Marrant, mais c'est typiquement le genre de truc bon pour alimenter les discussions sur les forums mais dont je me demande l'utilité pratique.
Emmanuel Florac
Le Wed, 24 May 2006 00:13:04 +0200, SL a écrit :
Marrant, mais c'est typiquement le genre de truc bon pour alimenter les discussions sur les forums mais dont je me demande l'utilité pratique.
Tu l'as dit toi-même : certaines API Java ne sont pas dispo en perl. Avec Inline::Java, je peux facilement mapper les fonctions d'une API java quelconque pour les utiliser dans mon code Perl. J'ai un exemple en cours: j'ai une grosse application de gestion de données en Perl. On veut pouvoir piloter depuis cette application un système fourni avec une API Java. J'ai deux options : je peux écrire un serveur java qui utilise l'API, et un client Perl, et communiquer via TCP/IP. Je peux aussi utiliser Inline::Java pour connecter mon application directement au système de façon transparente, et économiser ainsi des montagnes de code.
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Le Wed, 24 May 2006 00:13:04 +0200, SL a écrit :
Marrant, mais c'est typiquement le genre de truc bon pour alimenter
les discussions sur les forums mais dont je me demande l'utilité
pratique.
Tu l'as dit toi-même : certaines API Java ne sont pas dispo en perl. Avec
Inline::Java, je peux facilement mapper les fonctions d'une API java
quelconque pour les utiliser dans mon code Perl. J'ai un exemple en cours:
j'ai une grosse application de gestion de données en Perl. On veut
pouvoir piloter depuis cette application un système fourni avec une API
Java. J'ai deux options : je peux écrire un serveur java qui utilise
l'API, et un client Perl, et communiquer via TCP/IP. Je peux aussi
utiliser Inline::Java pour connecter mon application directement au
système de façon transparente, et économiser ainsi des montagnes de
code.
--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.
Marrant, mais c'est typiquement le genre de truc bon pour alimenter les discussions sur les forums mais dont je me demande l'utilité pratique.
Tu l'as dit toi-même : certaines API Java ne sont pas dispo en perl. Avec Inline::Java, je peux facilement mapper les fonctions d'une API java quelconque pour les utiliser dans mon code Perl. J'ai un exemple en cours: j'ai une grosse application de gestion de données en Perl. On veut pouvoir piloter depuis cette application un système fourni avec une API Java. J'ai deux options : je peux écrire un serveur java qui utilise l'API, et un client Perl, et communiquer via TCP/IP. Je peux aussi utiliser Inline::Java pour connecter mon application directement au système de façon transparente, et économiser ainsi des montagnes de code.
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
SL
Le Wed, 24 May 2006 00:13:04 +0200, SL a écrit :
Marrant, mais c'est typiquement le genre de truc bon pour alimenter les discussions sur les forums mais dont je me demande l'utilité pratique.
Tu l'as dit toi-même : certaines API Java ne sont pas dispo en perl. Avec Inline::Java, je peux facilement mapper les fonctions d'une API java quelconque pour les utiliser dans mon code Perl. J'ai un exemple en cours: j'ai une grosse application de gestion de données en Perl. On veut pouvoir piloter depuis cette application un système fourni avec une API Java. J'ai deux options : je peux écrire un serveur java qui utilise l'API, et un client Perl, et communiquer via TCP/IP. Je peux aussi utiliser Inline::Java pour connecter mon application directement au système de façon transparente, et économiser ainsi des montagnes de code.
Oui, je trouve ça un peu curieux quand même (ça ne pénalise pas terriblement l'application de devoir compiler le code java avant chaque exécution ?), mais dans le cas où on veut utiliser intensivement une API tout au long d'un programme, je ne m'y lancerais pas.
Le Wed, 24 May 2006 00:13:04 +0200, SL a écrit :
Marrant, mais c'est typiquement le genre de truc bon pour alimenter
les discussions sur les forums mais dont je me demande l'utilité
pratique.
Tu l'as dit toi-même : certaines API Java ne sont pas dispo en
perl. Avec Inline::Java, je peux facilement mapper les fonctions
d'une API java quelconque pour les utiliser dans mon code Perl. J'ai
un exemple en cours: j'ai une grosse application de gestion de
données en Perl. On veut pouvoir piloter depuis cette application un
système fourni avec une API Java. J'ai deux options : je peux écrire
un serveur java qui utilise l'API, et un client Perl, et communiquer
via TCP/IP. Je peux aussi utiliser Inline::Java pour connecter mon
application directement au système de façon transparente, et
économiser ainsi des montagnes de code.
Oui, je trouve ça un peu curieux quand même (ça ne pénalise pas
terriblement l'application de devoir compiler le code java avant
chaque exécution ?), mais dans le cas où on veut utiliser
intensivement une API tout au long d'un programme, je ne m'y lancerais
pas.
Marrant, mais c'est typiquement le genre de truc bon pour alimenter les discussions sur les forums mais dont je me demande l'utilité pratique.
Tu l'as dit toi-même : certaines API Java ne sont pas dispo en perl. Avec Inline::Java, je peux facilement mapper les fonctions d'une API java quelconque pour les utiliser dans mon code Perl. J'ai un exemple en cours: j'ai une grosse application de gestion de données en Perl. On veut pouvoir piloter depuis cette application un système fourni avec une API Java. J'ai deux options : je peux écrire un serveur java qui utilise l'API, et un client Perl, et communiquer via TCP/IP. Je peux aussi utiliser Inline::Java pour connecter mon application directement au système de façon transparente, et économiser ainsi des montagnes de code.
Oui, je trouve ça un peu curieux quand même (ça ne pénalise pas terriblement l'application de devoir compiler le code java avant chaque exécution ?), mais dans le cas où on veut utiliser intensivement une API tout au long d'un programme, je ne m'y lancerais pas.
Emmanuel Florac
Le Wed, 24 May 2006 13:31:59 +0200, SL a écrit :
Oui, je trouve ça un peu curieux quand même (ça ne pénalise pas terriblement l'application de devoir compiler le code java avant chaque exécution ?),
Ça dépend de l'application. Dans mon cas précis c'est un démon, donc on le lance une fois pour toute :)
mais dans le cas où on veut utiliser intensivement une API tout au long d'un programme, je ne m'y lancerais pas.
Et pourquoi ? On fait ça de façon très habituelle depuis des années avec du C ou du C++ ( y compris en Java, d'ailleurs) et personne ne s'en plaint outre mesure.
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Le Wed, 24 May 2006 13:31:59 +0200, SL a écrit :
Oui, je trouve ça un peu curieux quand même (ça ne pénalise pas
terriblement l'application de devoir compiler le code java avant
chaque exécution ?),
Ça dépend de l'application. Dans mon cas précis c'est un démon, donc
on le lance une fois pour toute :)
mais dans le cas où on veut utiliser
intensivement une API tout au long d'un programme, je ne m'y lancerais
pas.
Et pourquoi ? On fait ça de façon très habituelle depuis des années
avec du C ou du C++ ( y compris en Java, d'ailleurs) et personne ne s'en
plaint outre mesure.
--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.
Oui, je trouve ça un peu curieux quand même (ça ne pénalise pas terriblement l'application de devoir compiler le code java avant chaque exécution ?),
Ça dépend de l'application. Dans mon cas précis c'est un démon, donc on le lance une fois pour toute :)
mais dans le cas où on veut utiliser intensivement une API tout au long d'un programme, je ne m'y lancerais pas.
Et pourquoi ? On fait ça de façon très habituelle depuis des années avec du C ou du C++ ( y compris en Java, d'ailleurs) et personne ne s'en plaint outre mesure.
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Stéphane Zuckerman
On Wed, 24 May 2006, Emmanuel Florac wrote:
Le Wed, 24 May 2006 13:31:59 +0200, SL a écrit :
Oui, je trouve ça un peu curieux quand même (ça ne pénalise pas terriblement l'application de devoir compiler le code java avant chaque exécution ?),
Ça dépend de l'application. Dans mon cas précis c'est un démon, donc on le lance une fois pour toute :)
mais dans le cas où on veut utiliser intensivement une API tout au long d'un programme, je ne m'y lancerais pas.
Et pourquoi ? On fait ça de façon très habituelle depuis des années avec du C ou du C++ ( y compris en Java, d'ailleurs) et personne ne s'en plaint outre mesure.
Mais en C ou C++, le programme est compilé une fois pour toutes. En Java, le bytecode n'est pas totalement compilé en JIT, si ?
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
On Wed, 24 May 2006, Emmanuel Florac wrote:
Le Wed, 24 May 2006 13:31:59 +0200, SL a écrit :
Oui, je trouve ça un peu curieux quand même (ça ne pénalise pas
terriblement l'application de devoir compiler le code java avant
chaque exécution ?),
Ça dépend de l'application. Dans mon cas précis c'est un démon, donc
on le lance une fois pour toute :)
mais dans le cas où on veut utiliser
intensivement une API tout au long d'un programme, je ne m'y lancerais
pas.
Et pourquoi ? On fait ça de façon très habituelle depuis des années
avec du C ou du C++ ( y compris en Java, d'ailleurs) et personne ne s'en
plaint outre mesure.
Mais en C ou C++, le programme est compilé une fois pour toutes. En Java,
le bytecode n'est pas totalement compilé en JIT, si ?
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
Oui, je trouve ça un peu curieux quand même (ça ne pénalise pas terriblement l'application de devoir compiler le code java avant chaque exécution ?),
Ça dépend de l'application. Dans mon cas précis c'est un démon, donc on le lance une fois pour toute :)
mais dans le cas où on veut utiliser intensivement une API tout au long d'un programme, je ne m'y lancerais pas.
Et pourquoi ? On fait ça de façon très habituelle depuis des années avec du C ou du C++ ( y compris en Java, d'ailleurs) et personne ne s'en plaint outre mesure.
Mais en C ou C++, le programme est compilé une fois pour toutes. En Java, le bytecode n'est pas totalement compilé en JIT, si ?
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
SL
mais dans le cas où on veut utiliser intensivement une API tout au long d'un programme, je ne m'y lancerais pas.
Et pourquoi ?
Je n'ai pas essayé inline::java, mais j'imagine qu'il y a des limitations ; par exemple j'ai vu au passage qu'on n'avait accès qu'aux méthodes publiques des classes définies, on ne peut donc pas modéliser de packages ? enfin de toute façon soit on fait une intervention ponctuelle sur java, et pourquoi pas, soit on utilise en permanance une API en java, et vous aurez du mal à m'enlever le préjugé que mettre du code à compiler et exécuter depuis un langage interprété est un peu tordu :-) C'est peut être qu'une question de goût, mais j'aime bien utiliser la technologie la plus adaptée, et l'utiliser de la façon la plus orthodoxe possible, là où elle est le plus robuste, plutôt que de faire des échafaudages branlants et des contorsions.
On fait ça de façon très habituelle depuis des années avec du C ou du C++ ( y compris en Java, d'ailleurs) et personne ne s'en plaint outre mesure.
Connais pas. S'il s'agit de JNI, c'est une interface avec le code compilé, pas avec le code source, n'est-ce pas ?
mais dans le cas où on veut utiliser intensivement une API tout au
long d'un programme, je ne m'y lancerais pas.
Et pourquoi ?
Je n'ai pas essayé inline::java, mais j'imagine qu'il y a des
limitations ; par exemple j'ai vu au passage qu'on n'avait accès
qu'aux méthodes publiques des classes définies, on ne peut donc pas
modéliser de packages ? enfin de toute façon soit on fait une
intervention ponctuelle sur java, et pourquoi pas, soit on utilise en
permanance une API en java, et vous aurez du mal à m'enlever le
préjugé que mettre du code à compiler et exécuter depuis un langage
interprété est un peu tordu :-) C'est peut être qu'une question de
goût, mais j'aime bien utiliser la technologie la plus adaptée, et
l'utiliser de la façon la plus orthodoxe possible, là où elle est le
plus robuste, plutôt que de faire des échafaudages branlants et des
contorsions.
On fait ça de façon très habituelle depuis des années avec du C ou
du C++ ( y compris en Java, d'ailleurs) et personne ne s'en plaint
outre mesure.
Connais pas. S'il s'agit de JNI, c'est une interface avec le code
compilé, pas avec le code source, n'est-ce pas ?
mais dans le cas où on veut utiliser intensivement une API tout au long d'un programme, je ne m'y lancerais pas.
Et pourquoi ?
Je n'ai pas essayé inline::java, mais j'imagine qu'il y a des limitations ; par exemple j'ai vu au passage qu'on n'avait accès qu'aux méthodes publiques des classes définies, on ne peut donc pas modéliser de packages ? enfin de toute façon soit on fait une intervention ponctuelle sur java, et pourquoi pas, soit on utilise en permanance une API en java, et vous aurez du mal à m'enlever le préjugé que mettre du code à compiler et exécuter depuis un langage interprété est un peu tordu :-) C'est peut être qu'une question de goût, mais j'aime bien utiliser la technologie la plus adaptée, et l'utiliser de la façon la plus orthodoxe possible, là où elle est le plus robuste, plutôt que de faire des échafaudages branlants et des contorsions.
On fait ça de façon très habituelle depuis des années avec du C ou du C++ ( y compris en Java, d'ailleurs) et personne ne s'en plaint outre mesure.
Connais pas. S'il s'agit de JNI, c'est une interface avec le code compilé, pas avec le code source, n'est-ce pas ?
Prodejeu
S'il s'agit de JNI, c'est une interface avec le code compilé, pas avec le code source, n'est-ce pas ?
Exact. Ce qui pose quelques problèmes au niveau de la portabilité, mais on a rien sans rien...
S'il s'agit de JNI, c'est une interface avec le code
compilé, pas avec le code source, n'est-ce pas ?
Exact.
Ce qui pose quelques problèmes au niveau de la portabilité, mais on a
rien sans rien...
