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
Si le but du "sans filtre" est de faire rentrer le code dans une petite machine, le Java est mal barré...
Et bien dans ce cas tu fais 2 jar, dont l'un est dépendance de l'autre Mais je doute que quelques classes en plus te fasse exploser tes quotas. Et au pire comme je te l'ai dis, tu peux virer les classes à la fin ou ne pas les compiler du tout (profile Maven)
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Si le but du "sans filtre" est de faire rentrer le code
dans une petite machine, le Java est mal barré...
Et bien dans ce cas tu fais 2 jar, dont l'un est dépendance de l'autre
Mais je doute que quelques classes en plus te fasse exploser tes quotas.
Et au pire comme je te l'ai dis, tu peux virer les classes à la fin ou
ne pas les compiler du tout (profile Maven)
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Si le but du "sans filtre" est de faire rentrer le code dans une petite machine, le Java est mal barré...
Et bien dans ce cas tu fais 2 jar, dont l'un est dépendance de l'autre Mais je doute que quelques classes en plus te fasse exploser tes quotas. Et au pire comme je te l'ai dis, tu peux virer les classes à la fin ou ne pas les compiler du tout (profile Maven)
- -- 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 <4dfe744c$0$1425$, a écrit :
Non, la maintenance est très simple et totalement gérée par Maven.
Lire ça écrit sérieusement, ça fait vraiment peur.
JKB
Le Sun, 19 Jun 2011 22:35:26 +0200, Aéris écrivait :
Le 19/06/2011 21:59, Tonton Th a écrit :
Je parlais du cas où la machine cible est distante.
Ça change quoi ? Java étant (et devant) être portable,
Merci pour cette tranche de rigolade matinale. Java doit être portable... Ça, c'est la théorie parce qu'il faut porter la JVM. Tu me diras, ce n'est plus aux devs d'écrire des choses portables, mais ça ne fait que repousser le problème un peu plus loin.
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)
Et tu exécutes le tout sous J9 et ça se bauge lamentablement.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Sun, 19 Jun 2011 22:35:26 +0200,
Aéris <aeris@imirhil.fr> écrivait :
Le 19/06/2011 21:59, Tonton Th a écrit :
Je parlais du cas où la machine cible est distante.
Ça change quoi ?
Java étant (et devant) être portable,
Merci pour cette tranche de rigolade matinale. Java doit être
portable... Ça, c'est la théorie parce qu'il faut porter la JVM. Tu
me diras, ce n'est plus aux devs d'écrire des choses portables, mais
ça ne fait que repousser le problème un peu plus loin.
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)
Et tu exécutes le tout sous J9 et ça se bauge lamentablement.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Sun, 19 Jun 2011 22:35:26 +0200, Aéris écrivait :
Le 19/06/2011 21:59, Tonton Th a écrit :
Je parlais du cas où la machine cible est distante.
Ça change quoi ? Java étant (et devant) être portable,
Merci pour cette tranche de rigolade matinale. Java doit être portable... Ça, c'est la théorie parce qu'il faut porter la JVM. Tu me diras, ce n'est plus aux devs d'écrire des choses portables, mais ça ne fait que repousser le problème un peu plus loin.
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)
Et tu exécutes le tout sous J9 et ça se bauge lamentablement.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
JKB
Le Sun, 19 Jun 2011 23:10:44 +0200, Yliur écrivait :
>> 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.
Ça, c'est parce que tu n'en as rien à faire. Appelle un peu le GC à la main sur une application serveur écrite en Java, et tu vas voir qu'il est particulièrement inefficace.
>> 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.
Toi, il y a longtemps que tu n'as pas vu un vrai code qui doit être prêt pour la semaine dernière. Le dev java, quand il est à la bourre, il ne _fait_ pas ça. Il te colle d'emblée un gros gestionnaire d'exception bien sale qui récupère tout pour ne pas s'emmerder lors du développement.
>> à 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.
Écoute, tu peux être convaincu que les exceptions sont le meilleur traitement possible d'une erreur. C'est ton droit. Je pense pour ma part que ce truc est le pire des traitements d'erreur parce qu'il s'appuie sur tout un tas de choses y compris le GC. C'est une aberration totale parce qu'on n'a pas envie que le développe sache (faire) une gestion propre et efficace qui est un peu plus complexe. J'ai sous le coude une application Java, à peu près écrite correctement qui fonctionne sur une architecture trois tiers en réseau. À chaque fois qu'il y a un paquet qui passe à la trappe ou une session utilisateur qui se bauge, les erreurs sont récupérées, mais il faut un temps certain pour que le GC libère la mémoire associée et un appel à la main peu libérer plusieurs centaines de Mo ! Résultat des courses, toutes les erreurs sont gérés à la C, proprement, car la gestion par exception faisait juste planter la JVM sur un 'out of memory exception' ! Les exceptions, c'est bien lorsque tu as un petit programme dans un coin. Lorsque tu as un truc énorme, c'est une monumentale connerie.
> 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.
Tu n'as pas l'impression de te prendre les pieds dans le tapis ? Tu disais plus haut qu'on ne savait pas localement comment prendre une décision et qu'il fallait que ça remonte. Il y a une contradiction dans les termes.
et de façon totalement dégueulasse.
Tu peux définir techniquement "totalement dégueulasse" ?
Récupérer à l'endroit où on peut réellement traiter l'erreur (soit beaucoup plus haut dans la pile) une exception générique. C'est idiot et la syntaxe java consiste à mettre des gestionnaires d'exception un peu partout, renvoyer l'exception au père, grand'père ou arrière-grand'père voire pire par un throw. Le seul moyen de gérer correctement une erreur est de la remonter le long de la pile en la gérant à chaque appel de fonction.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Sun, 19 Jun 2011 23:10:44 +0200,
Yliur <yliur@free.fr> écrivait :
>> 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.
Ça, c'est parce que tu n'en as rien à faire. Appelle un peu le GC à
la main sur une application serveur écrite en Java, et tu vas voir
qu'il est particulièrement inefficace.
>> 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.
Toi, il y a longtemps que tu n'as pas vu un vrai code qui doit être
prêt pour la semaine dernière. Le dev java, quand il est à la
bourre, il ne _fait_ pas ça. Il te colle d'emblée un gros
gestionnaire d'exception bien sale qui récupère tout pour ne pas
s'emmerder lors du développement.
>> à 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.
Écoute, tu peux être convaincu que les exceptions sont le meilleur
traitement possible d'une erreur. C'est ton droit. Je pense pour ma
part que ce truc est le pire des traitements d'erreur parce qu'il
s'appuie sur tout un tas de choses y compris le GC. C'est une
aberration totale parce qu'on n'a pas envie que le développe sache
(faire) une gestion propre et efficace qui est un peu plus complexe.
J'ai sous le coude une application Java, à peu près écrite
correctement qui fonctionne sur une architecture trois tiers en
réseau. À chaque fois qu'il y a un paquet qui passe à la trappe ou
une session utilisateur qui se bauge, les erreurs sont récupérées,
mais il faut un temps certain pour que le GC libère la mémoire
associée et un appel à la main peu libérer plusieurs centaines de
Mo ! Résultat des courses, toutes les erreurs sont gérés à la C,
proprement, car la gestion par exception faisait juste planter la
JVM sur un 'out of memory exception' ! Les exceptions, c'est bien
lorsque tu as un petit programme dans un coin. Lorsque tu as un truc
énorme, c'est une monumentale connerie.
> 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.
Tu n'as pas l'impression de te prendre les pieds dans le tapis ?
Tu disais plus haut qu'on ne savait pas localement comment prendre
une décision et qu'il fallait que ça remonte. Il y a une
contradiction dans les termes.
et de façon totalement dégueulasse.
Tu peux définir techniquement "totalement dégueulasse" ?
Récupérer à l'endroit où on peut réellement traiter l'erreur (soit
beaucoup plus haut dans la pile) une exception générique. C'est
idiot et la syntaxe java consiste à mettre des gestionnaires
d'exception un peu partout, renvoyer l'exception au père, grand'père
ou arrière-grand'père voire pire par un throw. Le seul moyen de gérer
correctement une erreur est de la remonter le long de la pile en la
gérant à chaque appel de fonction.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Sun, 19 Jun 2011 23:10:44 +0200, Yliur écrivait :
>> 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.
Ça, c'est parce que tu n'en as rien à faire. Appelle un peu le GC à la main sur une application serveur écrite en Java, et tu vas voir qu'il est particulièrement inefficace.
>> 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.
Toi, il y a longtemps que tu n'as pas vu un vrai code qui doit être prêt pour la semaine dernière. Le dev java, quand il est à la bourre, il ne _fait_ pas ça. Il te colle d'emblée un gros gestionnaire d'exception bien sale qui récupère tout pour ne pas s'emmerder lors du développement.
>> à 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.
Écoute, tu peux être convaincu que les exceptions sont le meilleur traitement possible d'une erreur. C'est ton droit. Je pense pour ma part que ce truc est le pire des traitements d'erreur parce qu'il s'appuie sur tout un tas de choses y compris le GC. C'est une aberration totale parce qu'on n'a pas envie que le développe sache (faire) une gestion propre et efficace qui est un peu plus complexe. J'ai sous le coude une application Java, à peu près écrite correctement qui fonctionne sur une architecture trois tiers en réseau. À chaque fois qu'il y a un paquet qui passe à la trappe ou une session utilisateur qui se bauge, les erreurs sont récupérées, mais il faut un temps certain pour que le GC libère la mémoire associée et un appel à la main peu libérer plusieurs centaines de Mo ! Résultat des courses, toutes les erreurs sont gérés à la C, proprement, car la gestion par exception faisait juste planter la JVM sur un 'out of memory exception' ! Les exceptions, c'est bien lorsque tu as un petit programme dans un coin. Lorsque tu as un truc énorme, c'est une monumentale connerie.
> 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.
Tu n'as pas l'impression de te prendre les pieds dans le tapis ? Tu disais plus haut qu'on ne savait pas localement comment prendre une décision et qu'il fallait que ça remonte. Il y a une contradiction dans les termes.
et de façon totalement dégueulasse.
Tu peux définir techniquement "totalement dégueulasse" ?
Récupérer à l'endroit où on peut réellement traiter l'erreur (soit beaucoup plus haut dans la pile) une exception générique. C'est idiot et la syntaxe java consiste à mettre des gestionnaires d'exception un peu partout, renvoyer l'exception au père, grand'père ou arrière-grand'père voire pire par un throw. Le seul moyen de gérer correctement une erreur est de la remonter le long de la pile en la gérant à chaque appel de fonction.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
