Aide Java pour débutant - Page 2

PS :

iwannabeamaki (./27) :
Puisque squalyl n'a pas l'air convaincu, histoire d'apporter quelques justifications à ce que je disais en ./17 :

- Les exceptions en Java sont lentes : http://blog.developpez.com/adiguba/p1075/java/perfs/exception-et-performances/

conclusion de ton article :

Donc il serait vraiment dommage de se passer de la gestion des exceptions... surtout que cette dernière apporte de nombreux avantages :

* Elles contiennent de nombreuses informations sur l'erreur (message d'erreur et 'Stack Trace'),
* Elles permettent d'obliger le développeur à les traiter, alors que rien ne l'empêche d'ignorer un code de retour,
* On peut facilement sortir proprement de la méthode en utilisant le mot-clef finally (pour fermer des connections ou fichiers par exemples), * On peut rajouter de nouveaux types d' exceptions sans impacter le code des méthodes appelantes (grâce au principe du polymorphisme)

Je pense que squalyl est convaincu, désormais

Et à part ça si ça se trouve Java est tellement mauvais qu'il serait foutu d'être plus rapide de faire un try/catch à la squalyl qu'un check propre que le nombre est un entier. En C++ tu fais ça et c'est réglé ET rapide ET propre:

bool isInteger(const char *s) {
  if (*s == '+' || *s == '-')
    s++;
  while (*s >= '0' && *s <= '9')
    s++;
  return *s != '\0';
}

ça me dit surtout que le CLR a codé les exceptions avec les pieds pour aller au contre-courant de java, et comme c'est pourri chez eux, ils préconisent de les éviter.

je pourrais arguer que TryParse est débile niveau performances, vu qu'il va être quasiment toujours suivi d'un Parse et que donc, chaque nombre va se retrouver parsé deux fois. Par rapport à un lancer d'exception, ha ha ha.

PS: dans l'article ils proposent de tester:

public void methodThrowsException (String param) throws Exception {
if (param==null) {
throw new Exception("La valeur 'null' n'est pas acceptée");
}
// traitement
}

on peut faire encore mieux en passant pas de string à l'exception, parce que le type de l'objet contient déja l'info sur l'erreur.

Brunni (./32) :
Et à part ça si ça se trouve Java est tellement mauvais qu'il serait foutu d'être plus rapide de faire un try/catch à la squalyl qu'un check propre que le nombre est un entier. En C++ tu fais ça et c'est réglé ET rapide ET propre:

bool isInteger(const char *s) {
  if (*s == '+' || *s == '-')
    s++;
  while (*s >= '0' && *s <= '9')
    s++;
  return *s != '\0';
}

Ben, qu'est ce qui t'empêche d'écrire exactement la même chose en JAVA ?

En même temps, mon pote n'est vraiment pas partisan Java, plus C++, C# je crois.
Après je ne sais pas s'il prendra en compte le débat

Merci pour votre aide en tout cas, je pense que ça devrait lui être utile d'avoir des exemples concrets sur ses questions.

./32 & ./34 > Oui, c'est "(mal)heureusement" de Java dont il est question, sinon je serais venu poser la question du meilleur choix pour telle ou telle problématique... et dans une autre branche du forum.

pour le problème de performances soulevé par l'article, si on veut vraiment lancer 50 watmille exceptions comme eux, on utilise un singleton. Exception.throwIt() comme en javacard.

Pen^2 (./34) :
Ben, qu'est ce qui t'empêche d'écrire exactement la même chose en JAVA ?

Ben essaie de compiler ça avec javac et tu verras

?

ben tu verras, quoi. que ça marche parfaitement

buffer.length(); }

pour montreuillois:boolean isInteger(String buffer) { 
  int idx=0;
  if (buffer.charAt(idx) == '+' || buffer.charAt(idx) == '-') 
    idx++; 
  while (buffer.charAt(idx) >= '0' && buffer.charAt(idx) <= '9') 
    idx++; 
  return idx!=

Ben la syntaxe n'aurait rien à voir en java, et appeler 40 fois une méthode (charAt) sera bcp plus lent, peut être même plus encore que laisser java le faire en natif et catcher l'exception (ce qui serait )

heu, forcément, pas le même langage => syntaxe différente
Pour le charAt au lieu du pointeur, certes, mais c'est vraiment le dernier truc à optimiser. Et pourquoi ne pas inliner ta fonction dans ce cas ? Bref, je ne crois pas que ce soit un problème majeur.

PS : au passage, il me semble que ta fonction ne... fonctionne pas.
Déjà, tu as inversé le test final.
Et même en corrigeant ça,
isInteger("+") ; renvoie true
isInteger("-") ; aussi
isInteger("") ; aussi

#modtop# donc a coder comme un pied, autant laisser faire java.

je sinon je vois pas comment charat pourrait ramer vu que ça se réduit à un range check + retour d'un élément de tableau.

(ben, appel de fonction, toussa.... et surtout le throws IndexOutOfBoundException )

c'est vrai qu'il va être appelé souvent lui

Quand il y en a un ça va. C'est quand il y en a plus de 9000 qu'il y a des problèmes

squalyl (./43) :
#modtop# donc a coder comme un pied, autant laisser faire java.

Pauvre chou.

squalyl (./43) :
je sinon je vois pas comment charat pourrait ramer vu que ça se réduit à un range check + retour d'un élément de tableau.

A moins que tu aies la preuve que le JIT l'inline toujours ce sera lent.

Franchement, en pratique, il y a toutes les chances que la différence ne soit jamais sensible (et si tu y tiens vraiment tu peux aussi utiliser des char[] à la place des String )

montreuillois (./35) :
Merci pour votre aide en tout cas, je pense que ça devrait lui être utile d'avoir des exemples concrets sur ses questions.

Bon, sinon, quel est le contexte de son exo ? C'est vraiment les expressions régulières ?

Pen^2 (./28) :
C'est vrai que c'est super courant de lancer quelques millions (ou même milliers (ou même centaines)) d'exceptions dans une boucle

Ben c'est pas tellement une question de boucler sur des exceptions (forcément, pour faire son test il va pas comparer les temps sur 3 itérations...), mais de comparaison relative entre la méthode "avec exceptions" et la méthode "sans exceptions". Si y'en a une qui prend quasiment 1000 fois plus de temps, même si c'est négligeable sur une itération, dès que tu construits un système conséquent l'impact est loin d'être négligeable. Là où je suis on fait du C# et certaines applis se prennent des dizaines de milliers de requêtes par seconde, et pour le coup les exceptions sont à oublier, même si dans l'absolu ça ne coute qu'une poignée de ms.

Pen^2 (./31) :
Je pense que squalyl est convaincu, désormais

J'ai jamais dit que les exceptions étaient inutiles hein, juste que quand les performances sont un critère important, il vaut mieux éviter de les utiliser.

squalyl (./33) :
je pourrais arguer que TryParse est débile niveau performances, vu qu'il va être quasiment toujours suivi d'un Parse et que donc, chaque nombre va se retrouver parsé deux fois. Par rapport à un lancer d'exception, ha ha ha.

Non, TryParse effectue le parsing, c'est juste qu'il retourne "false" quand il a échoué au lieu de lancer une exception.

Pen^2 (./48) :
Bon, sinon, quel est le contexte de son exo ? C'est vraiment les expressions régulières ?

Leur prof voulait leur faire faire un crawler (mono-page) à la base, histoire d'extraire les <h1>, <title>,... d'une page web à la base.

Mais certains comme mon pote n'ont jamais eu plus de 10h de cours de Java et leur cursus n'est pas informatique.

Alors il s'est rabattu sur un exo plus "simple" avec de la validation d'inputs.

Pour ce qui est de la verif mail et SQL, vous avez une idée ? (je lis un peu mais je pige que dalle)

Question... si j'avais été un gros n00b sur ce forum, vous m'auriez bashé ?

oui, surtout que t'as demandé une réponse urgente, alors là, c'est le fouet à clous

Si c'est ça... je lui dois déjà des clopes. Je vais me retrouver sur la paille et pas mal d'égratignures.

iwannabeamaki (./49) :

Pen^2 (./28) :
C'est vrai que c'est super courant de lancer quelques millions (ou même milliers (ou même centaines)) d'exceptions dans une boucle

Ben c'est pas tellement une question de boucler sur des exceptions (forcément, pour faire son test il va pas comparer les temps sur 3 itérations...), mais de comparaison relative entre la méthode "avec exceptions" et la méthode "sans exceptions". Si y'en a une qui prend quasiment 1000 fois plus de temps, même si c'est négligeable sur une itération, dès que tu construits un système conséquent l'impact est loin d'être négligeable. Là où je suis on fait du C# et certaines applis se prennent des dizaines de milliers de requêtes par seconde, et pour le coup les exceptions sont à oublier, même si dans l'absolu ça ne coute qu'une poignée de ms.

Bien sûr qu'il faut optimiser quand il y a besoin () mais c'est loin d'être souvent le cas. Et d'ailleurs, je pense que ce qui rame est plus le new que le throw. Ça reste à tester en tout cas.
Qq chose du genre de :

class Huhu {
Exception e= new Exception("boum") ;
void huhu()
throws Exception()
{
if ( test ) throw e ;
}
}
}

Pen^2 (./31) :
Je pense que squalyl est convaincu, désormais

J'ai jamais dit que les exceptions étaient inutiles hein, juste que quand les performances sont un critère important, il vaut mieux éviter de les utiliser.

Pkoi pas, mais bon, ça reste quand même à tester correctement (rapport au new/throw. Enfin, vous savez peut-être, mais pas moi)

Pen^2 (./54) :
Bien sûr qu'il faut optimiser quand il y a besoin () mais c'est loin d'être souvent le cas. Et d'ailleurs, je pense que ce qui rame est plus le new que le throw. Ça reste à tester en tout cas.

En C# tu es obligé de créer l'objet que tu throw, donc de mettre un new. En Java je sais pas, mais j'aurais tendance à penser que oui. À mon avis dans ces langages, où tous les objets sont de toutes façons instanciés avec un "new" (contrairement au C++ où tu peux choisir si tu veux mettre ton objet sur la pile ou sur le tas), ce n'est pas le new qui coute le plus cher. Mais ça peut être intéressant à tester, si tu arrives à dissocier les deux ^^

d'après l'article c'est surtout le fillinstacktrace() qui alloue plein d'objets. L'overrider permet de diviser le temps du "throw+new" par 10.

montreuillois (./50) :
verif mail

Le plus simple est d'utiliser les expressions régulières.
Google donne par exemple ça pour "email validator" : http://www.regular-expressions.info/email.html
Ensuite en java, ça donne quelque chose dans le genre de

class Huhu
{
   static final Pattern p= Pattern.compile("le pattern qui va bien, typiquement l'un de ceux présentés sur la page dont je file l'url") ;

   boolean isEmail( String emailToCheck )
   {
      return emailToCheck != null
         && p.matcher(emailToCheck).matches() ;
   }
}

iwannabeamaki (./55) :

Pen^2 (./54) :
Bien sûr qu'il faut optimiser quand il y a besoin () mais c'est loin d'être souvent le cas. Et d'ailleurs, je pense que ce qui rame est plus le new que le throw. Ça reste à tester en tout cas.

En C# tu es obligé de créer l'objet que tu throw, donc de mettre un new. En Java je sais pas, mais j'aurais tendance à penser que oui. À mon avis dans ces langages, où tous les objets sont de toutes façons instanciés avec un "new" (contrairement au C++ où tu peux choisir si tu veux mettre ton objet sur la pile ou sur le tas), ce n'est pas le new qui coute le plus cher. Mais ça peut être intéressant à tester, si tu arrives à dissocier les deux ^^

Je suis tout à fait certain que tu peux dissocier les deux, je le fais très souvent.
Et l'instanciation en boucle coûte cher, ne serait-ce que parce que ça pourrit le tas et que ça déclenche le GC.

Ca me fait rire ces guéguerres d'optimisation très poussées alors qu'il s'agit d'un devoir Java. Le prof n'aura (à juste titre) rien à foutre de ces considérations tout comme d'ailleurs 99.9% des programmeurs Java.

Si on veux faire du code Java ultra optimisé(j'ai été contraint d'en faire et je n'en suis pas fier) il faut en effet éviter toutes les exceptions, il faut aussi éviter au maximum les new et quasiment tout mettre en static.
Au final on a un code moche pas du tout OO. Bref mieux vaut faire du C, au moins c'est fait pour.

Uther (./59) :
Ca me fait rire ces guéguerres d'optimisation très poussées alors qu'il s'agit d'un devoir Java. Le prof n'aura à juste titre rien a foutre de ces considérations tout comme d'ailleurs 99.9% de programmeurs Java.

, sauf que -Java