Java devient OPEN SOURCE !!!

Le Fri, 26 May 2006 22:33:10 +0200, SL a écrit :

C'est assez folklo le passage où le code source est passé aux regexp
pour retrouver le nom des classes publiques et enregistrer dans des
fichiers ".java" le code avant de le compiler...

Contrairement à Perl, Java est parfaitement parsable. Ce n'est pas a
priori dangereux...

--
"Dope will get you through times of no money better
than money will get you through times of no dope."
Freewheelin' Franklin

talon@lpthe.jussieu.fr (Michel Talon) wrote:

Et la souplesse, qu'en fais tu?

niobe% gcl
GCL (GNU Common Lisp) 2.6.7 ANSI Mar 17 2006 21:52:37

...

(+ 1 2)

3

(+ "Hello" "World!")

Error in + [or a callee]: "Hello" is not of type NUMBER.

Et c'est pour ça que le RPL est vraiment un bon langage, tout du moins
en mode interactif. C'est d'ailleurs ce qui a fait le succès des
calculatrices HP.

castor ~% rpl -i
+++RPL/2 version 4.00pre8 (samedi 26.02.2005 à 10:05:42 CEST)
+++Copyright (C) 1989 à 2003, 2004 BERTRAND Joël

+++Ce logiciel est un logiciel libre sans aucune garantie de
fonctionnement.
+++Pour plus de détails, utilisez la commande 'warranty'.

+++"Hello" " World" +

1: "Hello World"
+++

Prodejeu wrote:
Désolé de na pas avoir pu répondre plus tôt, j'étais parti en vacances.

Merci beaucoup, mais justement "reparlons-en", tout en ayant déjà
utilisé (peu c'est vrai) ces trois langages, je trouve quand même que
Java a une plus belle syntaxe.
La syntaxe du Java est héritée de celle du C et emprunte un peu de celle du

C++. Le problème, à mes yeux bien sûr, de cette syntaxe (comme celle
d'ailleurs d'Eiffel) est que c'est un langage à parenthèses ou plus
exactement un langage orienté verbe. Un langage orienté sujet (Smalltalk,
Lisaac, ...) est, à mon avis, pour avoir programmé avec des langages de ces
deux catégories, plus adapté à la conception objet et est, surtoût, plus
facile à relire.

Pour ce qui est de SmallTalk, le concept est intéressant mais c'est en
grande partie la syntaxe qui m'a génée.
C'est normal, venant de la famille C, la syntaxe Smalltalk impose de changer

ses habitudes (dans mon cas, j'ai eu un peu de mal aussi). Elle impose
aussi à penser /correctement/ objet, ce qui n'est pas vraiment le cas de
Java par exemple (c'est pourquoi un certain nombre de personnes conseillent
de savoir programmer correctement en Smalltalk avant de passer à un langage
de masse).
Toutefois, pour moi, le plus gros pb de Java vient des exceptions : son
implémentation de celles-ci fait que les exceptions ne sont plus vraiment
utilisées pour gérer des exceptions comme il devrait être, et sont
utilisées même pour manipuler des erreurs (qui sont, rappelons le, des cas
"normaux" d'un programme).

Idem pour Objective C, même si le concept de typage dyanmique est assez
pratique dans ce genre de langage.
Elle permet surtoût de garder la simplicité recharchée par Java à ses

débuts, tout en gardant flexibilité et expressivité, ce qu'a perdu Java en
privilégiant le typage statique sans support de la généricité contrainte
(ce que fait maintenant Java 5). Toutefois, il est vrai, la généricité
contrainte complexifie le langage, mais ceci est /obligatoire/ si on désire
faire correctement de l'objet avec un langage à typage statique. A moins
qu'une solution de type de l'attribut de type 'class d'Ada dans Java
pouvait permettre à celui-ci de garder à la fois simplicité et une certaine
flexibilité et expressivité.

Et toujours idem pour Eiffel même si c'est vrai que j'apprécie le fait
qu'il soit contrairement à Java, 100% objet.
Pourtant c'est un langage à parenthèses, mais il est vrai plus de la lignée

de Pascal que du C.

Un langage orienté sujet (Smalltalk,
Lisaac, ...) est, à mon avis, pour avoir programmé avec des langages de ces
deux catégories, plus adapté à la conception objet et est, surtoût, plus
facile à relire.

Je pense plutôt que c'est plus une question d'habitude.
J'avais quasiment pas fait de C++ avant de faire du java et pourtant je
m'y suis habitué très vite.
Par contre il m'arrive encore très souvent d'avoir du mal avec du
SmallTalk, et de me demander comment j'écrirais la même chose en Java.

Toutefois, pour moi, le plus gros pb de Java vient des exceptions : son
implémentation de celles-ci fait que les exceptions ne sont plus vraiment
utilisées pour gérer des exceptions comme il devrait être, et sont
utilisées même pour manipuler des erreurs (qui sont, rappelons le, des cas
"normaux" d'un programme).

Tout dépend de comment le développeur les utilisent.
Je trouve que les exceptions générées par les classes de l'API, sont
bien faite.
Si on se contente de les intercepter, je ne vois pas où est le problème.
Par contre, si on s'amuse à mettre des exceptions là où une méthode
aurait pu renvoyer une donnée, c'est sur que là c'est mauvais.
Maintenant il faut pas non plus exagérer et faire comme en C, où pour
chaque fonction il y a toute une liste de codes d'erreur.
Le côté "pratique" d'un langage est quand même attirant.

Idem pour Objective C, même si le concept de typage dyanmique est assez
pratique dans ce genre de langage.
Elle permet surtoût de garder la simplicité recharchée par Java à ses

débuts, tout en gardant flexibilité et expressivité, ce qu'a perdu Java en
privilégiant le typage statique sans support de la généricité contrainte
(ce que fait maintenant Java 5). Toutefois, il est vrai, la généricité
contrainte complexifie le langage, mais ceci est /obligatoire/ si on désire
faire correctement de l'objet avec un langage à typage statique. A moins
qu'une solution de type de l'attribut de type 'class d'Ada dans Java
pouvait permettre à celui-ci de garder à la fois simplicité et une certaine
flexibilité et expressivité.

Je me trompe peut-être, mais est-ce qu'un langage à typage dynamique
(surtout dans le cas de langages interprétés ou pseudo-compilé) n'est
pas plus gourmand en ressources qu'un langage à typage statique ?

De plus, je trouve les langages à typage assez dangereux, surtout pour
les débutants et même encore un peu plus tard (l'erreur est humaine ;-) ).
Il m'est souvent arrivé d'avoir quelques soucis avec PHP à ce sujet, et
de chercher le type et le contenu de certaines variables.

Prodejeu wrote:

Toutefois, pour moi, le plus gros pb de Java vient des exceptions : son
implémentation de celles-ci fait que les exceptions ne sont plus vraiment
utilisées pour gérer des exceptions comme il devrait être, et sont
utilisées même pour manipuler des erreurs (qui sont, rappelons le, des
cas "normaux" d'un programme).

Tout dépend de comment le développeur les utilisent.
Je trouve que les exceptions générées par les classes de l'API, sont
bien faite.
Je dirais non. En général, les exceptions relèvent de l'application et non

d'une API. Exemple de FileInputStream. Dans le cas d'une application qui
souhaite lire un fichier de conf placé dans /etc. Ceci signifie que ce
fichier peut-être modifié par l'utilisateur. Si ce fichier n'est pas trouvé
ou ne peut être lu, ceci est une erreur et pas une exception parce que, en
le mettant à disposition du tout à chacun, le cas que ce produit ce genre
d'erreur ne peut être considéré comme une excéption. Donc, la déclaration
de l'exception FileNotFoundException est conceptuellement fausse car ceci
relève de l'erreur (cas "normal") et non de l'exception. Maintenant, si le
fichier de conf est mis dans un lieu caché (par exemple un jar) et qu'il
n'est pas trouvé ou ne peut être lu par l'application relève lui de
l'exception et non de l'erreur car ce cas ne devrait pas se produire si
l'application est correctement construite et déployée.
Nous avons donc un exemple où une exception est mal utilisée. Et ceci
conduit finalement avec le temps aux développeurs à ne plus penser
correctement les exceptions, ce qui amène souvent à alourdir la conception
d'un programme. N'oublions pas que notre façon de percevoir les choses et
conditionné par les outils que l'on utilise, et plus particulièrement par
le langage.

Je me trompe peut-être, mais est-ce qu'un langage à typage dynamique
(surtout dans le cas de langages interprétés ou pseudo-compilé) n'est
pas plus gourmand en ressources qu'un langage à typage statique ?
Non, tu ne te trompes pas. Mais ce qui est vraiment gourmand, ce sont les

VM, et plus particulièrement les JVM (ce sont les VM les plus lourdes que
j'ai rencontré).

De plus, je trouve les langages à typage assez dangereux, surtout pour
les débutants et même encore un peu plus tard (l'erreur est humaine ;-) ).
Il m'est souvent arrivé d'avoir quelques soucis avec PHP à ce sujet, et
de chercher le type et le contenu de certaines variables.
PHP est un autre pb. Dans ce langage, tout est global ce qui amène souvent à

de désagréables surprises (je n'ai pas touché à PHP 5).
Avec des langages comme Smalltalk par exmple, tu n'as pas ce genre de pb.
Par exemple, en cours de codage, lorsque tu écris un envoi de message à un
objet qui n'y répond pas, l'environnement de dév. te le signale.

Miguel Moquillon , dans le message
<447c4710$0$19575$636a55ce@news.free.fr>, a écrit :

Ceci signifie que ce
fichier peut-être modifié par l'utilisateur. Si ce fichier n'est pas trouvé
ou ne peut être lu, ceci est une erreur et pas une exception parce que, en
le mettant à disposition du tout à chacun, le cas que ce produit ce genre
d'erreur ne peut être considéré comme une excéption.

Là, c'est toi qui a des idées préconçues sur ce que doivent être les
exceptions, probablement orienté par un des cens que peut avoir ce mot en
français courant.

Nicolas George wrote:

Miguel Moquillon , dans le message
<447c4710$0$19575$636a55ce@news.free.fr>, a écrit :

Ceci signifie que ce
fichier peut-être modifié par l'utilisateur. Si ce fichier n'est pas
trouvé ou ne peut être lu, ceci est une erreur et pas une exception parce
que, en le mettant à disposition du tout à chacun, le cas que ce produit
ce genre d'erreur ne peut être considéré comme une excéption.

Là, c'est toi qui a des idées préconçues sur ce que doivent être les
exceptions, probablement orienté par un des cens que peut avoir ce mot en
français courant.
Non, je ne crois pas. C'est ce que l'on apprend en Génie Logiciel.

Je suis concepteur et effectivement j'ai appris à bien faire attention au
sens des mots car ceci peut avoir un impact important aussi bien en
architecture qu'en conception.

Miguel Moquillon , dans le message
<447c4c67$0$21196$626a54ce@news.free.fr>, a écrit :

Non, je ne crois pas. C'est ce que l'on apprend en Génie Logiciel.

J'ai vu des gens apprendre à mettre des underscores au début des
identificateurs en C, alors ce qu'on apprend...

Le « génie logiciel », c'est fait pour que des gens médiocres arrivent à
pondre des programmes pas trop buggés pour répondre à des besoins simples.
Ce n'est pas vraiment une référence pour ce qui est de la qualité du code.

Je suis concepteur et effectivement j'ai appris à bien faire attention au
sens des mots car ceci peut avoir un impact important aussi bien en
architecture qu'en conception.

Le sens des mots dans un jargon technique ne coïncide que rarement avec le
sens commun des mêmes mots. Si on n'a pas compris ça, ça va mal se passer.

En général, les exceptions relèvent de l'application et non
d'une API. Exemple de FileInputStream. Dans le cas d'une application qui
souhaite lire un fichier de conf placé dans /etc. Ceci signifie que ce
fichier peut-être modifié par l'utilisateur. Si ce fichier n'est pas trouvé
ou ne peut être lu, ceci est une erreur et pas une exception parce que, en
le mettant à disposition du tout à chacun, le cas que ce produit ce genre
d'erreur ne peut être considéré comme une excéption. Donc, la déclaration
de l'exception FileNotFoundException est conceptuellement fausse car ceci
relève de l'erreur (cas "normal") et non de l'exception. Maintenant, si le
fichier de conf est mis dans un lieu caché (par exemple un jar) et qu'il
n'est pas trouvé ou ne peut être lu par l'application relève lui de
l'exception et non de l'erreur car ce cas ne devrait pas se produire si
l'application est correctement construite et déployée.
Nous avons donc un exemple où une exception est mal utilisée. Et ceci
conduit finalement avec le temps aux développeurs à ne plus penser
correctement les exceptions, ce qui amène souvent à alourdir la conception
d'un programme. N'oublions pas que notre façon de percevoir les choses et
conditionné par les outils que l'on utilise, et plus particulièrement par
le langage.

Je suis d'accord avec toi, néanmoins dans notre cas si on essaye de
faire la même chose en C (lecture d'un fichier inexistant), cela va
conduire sur un plantage de l'application.
En Java l'application ne plantera pas, parce que cette exception doit
obligatoirement être gérée.
Je t'accorde que tout développeur digne de ce nom va tester l'existence
des données avant d'essayer de les manipuler, mais grâce à ce genre de
système on dispose d'une "sécurité supplémentaire", qu'il faut utiliser
à bon escient.
De plus, je lis pas mal de bouquins et de tutoriels sur Java et la
plupart conseillent vraiment de prendre garde à bien utiliser les
exceptions, c'est à dire de ne pas s'appuyer dessus pour gérer des
erreurs, mais bien pour prévoir les éventuelles exceptions, donc si les
débutant en Java savent lire, il ne devrait pas y avoir de problème ;-).

Je me trompe peut-être, mais est-ce qu'un langage à typage dynamique
(surtout dans le cas de langages interprétés ou pseudo-compilé) n'est
pas plus gourmand en ressources qu'un langage à typage statique ?
Non, tu ne te trompes pas. Mais ce qui est vraiment gourmand, ce sont les

VM, et plus particulièrement les JVM (ce sont les VM les plus lourdes que
j'ai rencontré).

Ils en sont conscient chez Sun, et c'est d'ailleurs un de leurs cheval
de bataille.
Les performances ont pas mal évoluées dans les dernières versions
majeures de la JRE.


Le typage dynamique ne devrait pas avoir de conséquences majeures sur
les perfs d'un langage pseudo-compilé (voire pas du tout sur un langage
compilé), au contraire d'un langage interprété ?
Si mon allégation est juste, une version de Java utilisant le typage
dynamique ne devrait pas être beaucoup plus lente que l'originale,
néanmoins je ne vois toujours pas l'intérêt pour Java.

De plus, je trouve les langages à typage assez dangereux, surtout pour
les débutants et même encore un peu plus tard (l'erreur est humaine ;-) ).
Il m'est souvent arrivé d'avoir quelques soucis avec PHP à ce sujet, et
de chercher le type et le contenu de certaines variables.
PHP est un autre pb. Dans ce langage, tout est global ce qui amène souvent à

de désagréables surprises (je n'ai pas touché à PHP 5).
Avec des langages comme Smalltalk par exmple, tu n'as pas ce genre de pb.
Par exemple, en cours de codage, lorsque tu écris un envoi de message à un
objet qui n'y répond pas, l'environnement de dév. te le signale.

Quand tu dis "un envoi de message à un objet qui n'y répond pas", tu
entends :
-Référence inexistante
ou
-Objet du mauvais type
ou
-Les deux ?

Malgré cela il peut toujours exister des messages identique (même nom,
même paramètres) pour deux objets différents, l'environnement peut pas
grand chose en cas d'erreur dans ce cas de figure, non ?

J'ai vu des gens apprendre à mettre des underscores au début des
identificateurs en C, alors ce qu'on apprend...

Ce n'est parce qu'on apprend que l'on comprend.
Il faut parfois un petit laps de temps entre les deux, la pratique aide
beaucoup aussi.
Je ne connais personne capable de réussir parfaitement du premier coup
surtout en programmation (sauf quelques prétentieux, mais d'après eux...
;-) ).

Le « génie logiciel », c'est fait pour que des gens médiocres arrivent à
pondre des programmes pas trop buggés pour répondre à des besoins simples.
Ce n'est pas vraiment une référence pour ce qui est de la qualité du code.

Tu devrais donc reprendre quelques cours de "Génie Logiciel", et
"d'ouverture d'esprit" tant que tu y est.
Il me semble que beaucoup de grands Noms dans le domaine prêchent les
"bonnes pratiques" en programmation ; le Génie Logiciel sert justement à
nous inculquer ces bonnes pratiques qu'il est très difficile (voire
impossible sans) d'appréhender sans.

Je suis concepteur et effectivement j'ai appris à bien faire attention au
sens des mots car ceci peut avoir un impact important aussi bien en
architecture qu'en conception.

Le sens des mots dans un jargon technique ne coïncide que rarement avec le
sens commun des mêmes mots. Si on n'a pas compris ça, ça va mal se passer.

C'est pour cela qu'il faut d'autant plus faire attention au sens des
mots. ;-)