trollons gaiment sur le java - Page 2

KillerX (./33) :
Je viens de terminer un projet de session où on devait coder en java sur un système embarqué (Debian sur ARM) et j'ai détesté mon expérience java. J'ai commencé à coder en C, puis C++, et je n'ai pas trouvé que java était beaucoup plus facile que C++; par contre, j'ai remarqué une bonne perte de performances.
De plus, nous sommes tombés sur un bug de la machine virtuelle java: la plupart des opérations sur des double ou des float retournaient des valeurs louches comme ":58.254:24::24" ou encore "0.0P". Nous avons perdu un bon trois heures avant de se rendre compte de ce bug, et on a finalement adopté une solution pas trop propre: on multiplie la valeur recue par 1000, puis on caste en int aussitot qu'on peut. On fait alors nos opérations en int, puis on recaste en double juste avant de retourner.
Bref, j'espère pouvoir me tenir aussi loin que possible de java à l'avenir...
On dit "Java: code once, run everywhere"... Je dirais plutôt "Java: code once, debug everywhere"
De plus, dire que java est meilleur parce qu'il marche sur toutes les plateformes c'est comme dire que le sexe anal est meilleur parce qu'il marche sur les deux sexes...

KillerX (./33) :
De plus, dire que java est meilleur parce qu'il marche sur toutes les plateformes c'est comme dire que le sexe anal est meilleur parce qu'il marche sur les deux sexes...

squalyl (./36) :
dire que java c'est mal a cause d'une VM toute pourrite c'est une mauvaise foi encore pire que de dire que linux c'est mal à cause de fedora

This reduction results in a JRE that is less than one-half the footprint of the full JRE - as low as 30MB for Java SE 5.0 and 24MB for Java SE 1.4.2.

damnvoid (./44) :
Par construction, en faisant l'hypothese du "meilleur codeur possible", les langages compiles sont forcement strictement plus rapides que les langages interpretes/bytecode/JIT. Tout simplement parce qu'on peut toujours coder un programme qui a le meme comportement qu'un interpreteur/une VM/un compilateur JIT avec un langage compile alors que l'inverse n'est pas vrai.

damnvoid (./46) :
bien sur qu'en pratique c'est pas realiste de faire ca. maintenant si on ne prend pas betement cette affirmation theorique au pied de la lettre et qu'on lit un peu entre les lignes, ce que ca veut dire, fondamentalement, c'est que si les compilateurs JIT utilisent des astuces pour rendre l'execution plus rapide, il n'y a aucune raison pour que les compilateurs normaux ne puissent pas adapter et integrer ces memes astuces.

N'empêche que pour moi, un gars qui décide de faire de l'embarqué en Java (je ne parle pas de KillerX) mérite un lynchage en place publique, pour l'exemple.

class IFoo {
  public:
    void foo(void) { foo_impl(); }
    int bar(int x) { return bar_impl(x); }
  protected:
    virtual void foo_impl(void) = 0;
    virtual int bar_impl(int) = 0;
};

class Foo : public IFoo {
  public:
    void foo(void) { qDebug("foo"); }
    int bar(int x) { return x+1; }
  protected:
    virtual void foo_impl(void) { foo(); }
    virtual int bar_impl(int x) { return bar(x); }
};