Microsoft semble reconnaître que Java permet de développer plus
rapidement que C# et qu'il y a moins de failles de sécurité dans Java
que dans .net :
http://dsi.silicon.fr/nouveautes/microsoft-java-forever%E2%80%A6-1366
Aéris , dans le message <4dfe5202$0$29533$, a écrit :
Les 2 libs t'offrent strictement la même chose.
Non. Comme plein de fois dans ce thread, tu affirmes sans savoir.
Aéris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 19/06/2011 22:09, Nicolas George a écrit :
Non. Comme plein de fois dans ce thread, tu affirmes sans savoir.
Si, ou alors la lib est mal gaulée.
Pour moi, foo.so doit fournir exactement la même interface et les mêmes fonctions que foo.dll. Elles les implémentent peut-être (sûrement) différemment, mais le service rendu est strictement le même.
J'imagine assez mal comment openssl pourrait s'invoquer différement sous Linux ou sous Windows? D'autant plus que l'upstream est le même source? Mais c'est vrai qu'avec vos compilations conditionnelles, vous n'êtes plus à une saloperie vraiment dégeu près.
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Non. Comme plein de fois dans ce thread, tu affirmes sans savoir.
Si, ou alors la lib est mal gaulée.
Pour moi, foo.so doit fournir exactement la même interface et les mêmes
fonctions que foo.dll. Elles les implémentent peut-être (sûrement)
différemment, mais le service rendu est strictement le même.
J'imagine assez mal comment openssl pourrait s'invoquer différement sous
Linux ou sous Windows? D'autant plus que l'upstream est le même source?
Mais c'est vrai qu'avec vos compilations conditionnelles, vous n'êtes
plus à une saloperie vraiment dégeu près.
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Non. Comme plein de fois dans ce thread, tu affirmes sans savoir.
Si, ou alors la lib est mal gaulée.
Pour moi, foo.so doit fournir exactement la même interface et les mêmes fonctions que foo.dll. Elles les implémentent peut-être (sûrement) différemment, mais le service rendu est strictement le même.
J'imagine assez mal comment openssl pourrait s'invoquer différement sous Linux ou sous Windows? D'autant plus que l'upstream est le même source? Mais c'est vrai qu'avec vos compilations conditionnelles, vous n'êtes plus à une saloperie vraiment dégeu près.
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Je parlais du cas où la machine cible est distante.
Ça change quoi ? Java étant (et devant) être portable, tu peux très bien compiler sur ta machine et transférer le jar obtenu uniquement. Et même si l'appli embarque du natif (cas de SWT par exemple) et donc est plate-forme dépendante, un coup de profil Maven et tu «cross-compile» en local (en réalité tu inclus juste des jar win32 au lieu de x86 par exemple)
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Je parlais du cas où la machine cible est distante.
Ça change quoi ?
Java étant (et devant) être portable, tu peux très bien compiler sur ta
machine et transférer le jar obtenu uniquement.
Et même si l'appli embarque du natif (cas de SWT par exemple) et donc
est plate-forme dépendante, un coup de profil Maven et tu
«cross-compile» en local (en réalité tu inclus juste des jar win32 au
lieu de x86 par exemple)
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Je parlais du cas où la machine cible est distante.
Ça change quoi ? Java étant (et devant) être portable, tu peux très bien compiler sur ta machine et transférer le jar obtenu uniquement. Et même si l'appli embarque du natif (cas de SWT par exemple) et donc est plate-forme dépendante, un coup de profil Maven et tu «cross-compile» en local (en réalité tu inclus juste des jar win32 au lieu de x86 par exemple)
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Aéris , dans le message <4dfe5979$0$27974$, a écrit :
Si, ou alors la lib est mal gaulée.
Ce n'est pas la même, gros malin.
Yliur
>> Non. Va jusqu'au bout de ton raisonnement. Cela implique de >> récupérer le code d'erreur localement, puis de traiter ce >> qu'il faut localement, > > En général on ne sait pas quoi faire localement.
Si, libérer les ressources utilisées dans la fonction dans laquelle la fonction fautive a été appelée. Et il faut le faire récursivement jusqu'à la fonction dans laquelle on peut traiter l'erreur. Si tu ne fais pas ça, tu risques fort d'avoir des fuites de mémoire un peu partout (voire pire).
Et donc en général en Java ça se résume à rien, parce qu'on ne libère pas la mémoire explicitement. La plupart des fonctions n'ont pas d'autres ressources à libérer (connexions, fichiers, ...), et donc on ne fait quelque chose que dans ces fonctions.
>> puis de remonter l'erreur (soit avec un code >> d'erreur, soit avec une exception et un magnifique throw) > > S'il n'y a pas de catch mais seulement un finally, il n'y a même pas > besoin de propager l'exception : le code de nettoyage dans le bloc > finally est exécuté puis l'exception est automatiquement propagée.
Impossible à faire dans le cas général.
Pourquoi ? Si l'exception doit être traitée explicitement (IOException par exemple), c'est vrai, mais on l'emballe dans une exception propre à l'appli qui n'est pas vérifiée par exemple, qui remontera facilement la pile d'appels.
>> à la >> fonction appelante, et ainsi récursivement jusqu'à un point où tu >> peux prendre ta décision sur le traitement à apporter. Je n'ai >> _jamais_ vu un code Java (ou C++ d'ailleurs) fonctionner comme ça. >> Je ne dis pas que ça n'existe pas, simplement que je n'en ai >> jamais vu. La plupart du temps, tu as un try/catch avec un gros >> machin pas net dedans qui récupère toutes les exceptions qui >> passent, se contrefichant éperdument de tout ce qu'il faudrait >> récupérer correctement. > > En Java, la plupart du temps il n'y a rien à récupérer > "correctement".
Ah ? Enfin, tout est dans le 'la plupart du temps'...
Et donc ? C'est juste beaucoup plus simple et ça explique pourquoi il n'y a pas besoin de coller des traitements partout, donc de traiter l'erreur dans toute la pile d'appels. On met juste un try/finally là où il y a des ressources qui ont vraiment besoin d'être libérées.
> Seulement de la mémoire, mais tout ce qui a été alloué dans la > fonction et stocké dans des variables locales n'a pas besoin d'être > récupéré (comme dans le cas d'une fin normale de la fonction, c'est > le collecteur de mémoire qui s'en occupe). > > Dans le cas où il a des choses à récupérer (fichiers, ...), en > général il y a une exception à gérer explicitement > (IOException, ...). Donc l'obligation de réfléchir à ce qu'il faut > en faire (moins facile à oublier qu'un code d'erreur).
Sauf que c'est très con. Parce que ton exception peut être récupérée tout à fait ailleurs
Comment ça ? La méthode qui fait l'appel concerné est obligée de traiter l'exception localement ou de la laisser passer explicitement. L'exception n'apparaît pas miraculeusement ailleurs.
et de façon totalement dégueulasse.
Tu peux définir techniquement "totalement dégueulasse" ?
>> Non. Va jusqu'au bout de ton raisonnement. Cela implique de
>> récupérer le code d'erreur localement, puis de traiter ce
>> qu'il faut localement,
>
> En général on ne sait pas quoi faire localement.
Si, libérer les ressources utilisées dans la fonction dans
laquelle la fonction fautive a été appelée. Et il faut le faire
récursivement jusqu'à la fonction dans laquelle on peut traiter
l'erreur. Si tu ne fais pas ça, tu risques fort d'avoir des fuites de
mémoire un peu partout (voire pire).
Et donc en général en Java ça se résume à rien, parce qu'on ne libère
pas la mémoire explicitement. La plupart des fonctions n'ont pas
d'autres ressources à libérer (connexions, fichiers, ...), et donc on ne
fait quelque chose que dans ces fonctions.
>> puis de remonter l'erreur (soit avec un code
>> d'erreur, soit avec une exception et un magnifique throw)
>
> S'il n'y a pas de catch mais seulement un finally, il n'y a même pas
> besoin de propager l'exception : le code de nettoyage dans le bloc
> finally est exécuté puis l'exception est automatiquement propagée.
Impossible à faire dans le cas général.
Pourquoi ? Si l'exception doit être traitée explicitement (IOException
par exemple), c'est vrai, mais on l'emballe dans une exception propre à
l'appli qui n'est pas vérifiée par exemple, qui remontera facilement la
pile d'appels.
>> à la
>> fonction appelante, et ainsi récursivement jusqu'à un point où tu
>> peux prendre ta décision sur le traitement à apporter. Je n'ai
>> _jamais_ vu un code Java (ou C++ d'ailleurs) fonctionner comme ça.
>> Je ne dis pas que ça n'existe pas, simplement que je n'en ai
>> jamais vu. La plupart du temps, tu as un try/catch avec un gros
>> machin pas net dedans qui récupère toutes les exceptions qui
>> passent, se contrefichant éperdument de tout ce qu'il faudrait
>> récupérer correctement.
>
> En Java, la plupart du temps il n'y a rien à récupérer
> "correctement".
Ah ? Enfin, tout est dans le 'la plupart du temps'...
Et donc ? C'est juste beaucoup plus simple et ça explique pourquoi il
n'y a pas besoin de coller des traitements partout, donc de traiter
l'erreur dans toute la pile d'appels. On met juste un try/finally là où
il y a des ressources qui ont vraiment besoin d'être libérées.
> Seulement de la mémoire, mais tout ce qui a été alloué dans la
> fonction et stocké dans des variables locales n'a pas besoin d'être
> récupéré (comme dans le cas d'une fin normale de la fonction, c'est
> le collecteur de mémoire qui s'en occupe).
>
> Dans le cas où il a des choses à récupérer (fichiers, ...), en
> général il y a une exception à gérer explicitement
> (IOException, ...). Donc l'obligation de réfléchir à ce qu'il faut
> en faire (moins facile à oublier qu'un code d'erreur).
Sauf que c'est très con. Parce que ton exception peut être
récupérée tout à fait ailleurs
Comment ça ? La méthode qui fait l'appel concerné est obligée de
traiter l'exception localement ou de la laisser passer explicitement.
L'exception n'apparaît pas miraculeusement ailleurs.
et de façon totalement dégueulasse.
Tu peux définir techniquement "totalement dégueulasse" ?
>> Non. Va jusqu'au bout de ton raisonnement. Cela implique de >> récupérer le code d'erreur localement, puis de traiter ce >> qu'il faut localement, > > En général on ne sait pas quoi faire localement.
Si, libérer les ressources utilisées dans la fonction dans laquelle la fonction fautive a été appelée. Et il faut le faire récursivement jusqu'à la fonction dans laquelle on peut traiter l'erreur. Si tu ne fais pas ça, tu risques fort d'avoir des fuites de mémoire un peu partout (voire pire).
Et donc en général en Java ça se résume à rien, parce qu'on ne libère pas la mémoire explicitement. La plupart des fonctions n'ont pas d'autres ressources à libérer (connexions, fichiers, ...), et donc on ne fait quelque chose que dans ces fonctions.
>> puis de remonter l'erreur (soit avec un code >> d'erreur, soit avec une exception et un magnifique throw) > > S'il n'y a pas de catch mais seulement un finally, il n'y a même pas > besoin de propager l'exception : le code de nettoyage dans le bloc > finally est exécuté puis l'exception est automatiquement propagée.
Impossible à faire dans le cas général.
Pourquoi ? Si l'exception doit être traitée explicitement (IOException par exemple), c'est vrai, mais on l'emballe dans une exception propre à l'appli qui n'est pas vérifiée par exemple, qui remontera facilement la pile d'appels.
>> à la >> fonction appelante, et ainsi récursivement jusqu'à un point où tu >> peux prendre ta décision sur le traitement à apporter. Je n'ai >> _jamais_ vu un code Java (ou C++ d'ailleurs) fonctionner comme ça. >> Je ne dis pas que ça n'existe pas, simplement que je n'en ai >> jamais vu. La plupart du temps, tu as un try/catch avec un gros >> machin pas net dedans qui récupère toutes les exceptions qui >> passent, se contrefichant éperdument de tout ce qu'il faudrait >> récupérer correctement. > > En Java, la plupart du temps il n'y a rien à récupérer > "correctement".
Ah ? Enfin, tout est dans le 'la plupart du temps'...
Et donc ? C'est juste beaucoup plus simple et ça explique pourquoi il n'y a pas besoin de coller des traitements partout, donc de traiter l'erreur dans toute la pile d'appels. On met juste un try/finally là où il y a des ressources qui ont vraiment besoin d'être libérées.
> Seulement de la mémoire, mais tout ce qui a été alloué dans la > fonction et stocké dans des variables locales n'a pas besoin d'être > récupéré (comme dans le cas d'une fin normale de la fonction, c'est > le collecteur de mémoire qui s'en occupe). > > Dans le cas où il a des choses à récupérer (fichiers, ...), en > général il y a une exception à gérer explicitement > (IOException, ...). Donc l'obligation de réfléchir à ce qu'il faut > en faire (moins facile à oublier qu'un code d'erreur).
Sauf que c'est très con. Parce que ton exception peut être récupérée tout à fait ailleurs
Comment ça ? La méthode qui fait l'appel concerné est obligée de traiter l'exception localement ou de la laisser passer explicitement. L'exception n'apparaît pas miraculeusement ailleurs.
et de façon totalement dégueulasse.
Tu peux définir techniquement "totalement dégueulasse" ?
Aéris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 19/06/2011 23:07, Nicolas George a écrit :
Ce n'est pas la même, gros malin.
Alors ce n'est pas le même problème. Et on a 2 projets à mener, un pour intégrer la lib win, l'autre la lib linux. Et on centralise les parties communes dans un 3ème projet générique
Avec Maven, c'est l'histoire de 30s ! C'est sûr qu'avec Make, ça va prendre un poil plus de temps?
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Alors ce n'est pas le même problème.
Et on a 2 projets à mener, un pour intégrer la lib win, l'autre la lib
linux.
Et on centralise les parties communes dans un 3ème projet générique
Avec Maven, c'est l'histoire de 30s !
C'est sûr qu'avec Make, ça va prendre un poil plus de temps?
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Alors ce n'est pas le même problème. Et on a 2 projets à mener, un pour intégrer la lib win, l'autre la lib linux. Et on centralise les parties communes dans un 3ème projet générique
Avec Maven, c'est l'histoire de 30s ! C'est sûr qu'avec Make, ça va prendre un poil plus de temps?
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Aéris , dans le message <4dfe6c88$0$31779$, a écrit :
Et on centralise les parties communes dans un 3ème projet générique
Trois projets, avec chacun ses déclaration, sa maintenance, etc., juste pour simuler ce que le C fait en quatre lignes de #ifdef. C'est beau le java...
Aéris , dans le message <4dfe6c88$0$31779$426a74cc@news.free.fr>, a
écrit :
Et on centralise les parties communes dans un 3ème projet générique
Trois projets, avec chacun ses déclaration, sa maintenance, etc., juste pour
simuler ce que le C fait en quatre lignes de #ifdef. C'est beau le java...
Aéris , dans le message <4dfe6c88$0$31779$, a écrit :
Et on centralise les parties communes dans un 3ème projet générique
Trois projets, avec chacun ses déclaration, sa maintenance, etc., juste pour simuler ce que le C fait en quatre lignes de #ifdef. C'est beau le java...
Tonton Th
On 06/18/2011 03:22 PM, Aéris wrote:
En Java, cela ne peut pas arrivé puisque c'est une convention d'avoir un package de la forme « dns inverse » . « projet » Chaque namespace est donc garanti unique à travers le monde.
On fait comment quand on a pas de "dns inverse" ?
-- Je cherche un nouveau travail... http://tboudet.free.fr/cv-thierry-boudet.pdf http://sigfood.dinorama.fr/
On 06/18/2011 03:22 PM, Aéris wrote:
En Java, cela ne peut pas arrivé puisque c'est une convention d'avoir un
package de la forme « dns inverse » . « projet »
Chaque namespace est donc garanti unique à travers le monde.
On fait comment quand on a pas de "dns inverse" ?
--
Je cherche un nouveau travail...
http://tboudet.free.fr/cv-thierry-boudet.pdf
http://sigfood.dinorama.fr/
En Java, cela ne peut pas arrivé puisque c'est une convention d'avoir un package de la forme « dns inverse » . « projet » Chaque namespace est donc garanti unique à travers le monde.
On fait comment quand on a pas de "dns inverse" ?
-- Je cherche un nouveau travail... http://tboudet.free.fr/cv-thierry-boudet.pdf http://sigfood.dinorama.fr/
Aéris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 19/06/2011 23:53, Nicolas George a écrit :
Trois projets, avec chacun ses déclaration, sa maintenance, etc., juste pour simuler ce que le C fait en quatre lignes de #ifdef. C'est beau le java...
Non, la maintenance est très simple et totalement gérée par Maven. Maven permet l'héritage et l'aggrégation de projets, un peu à la mode POO.
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Trois projets, avec chacun ses déclaration, sa maintenance, etc., juste pour
simuler ce que le C fait en quatre lignes de #ifdef. C'est beau le java...
Non, la maintenance est très simple et totalement gérée par Maven.
Maven permet l'héritage et l'aggrégation de projets, un peu à la mode POO.
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Trois projets, avec chacun ses déclaration, sa maintenance, etc., juste pour simuler ce que le C fait en quatre lignes de #ifdef. C'est beau le java...
Non, la maintenance est très simple et totalement gérée par Maven. Maven permet l'héritage et l'aggrégation de projets, un peu à la mode POO.
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
