Nicolas a écrit 4 commentaires

  • [^] # Re: \ô/ Vive le Québec Libre \ô/

    Posté par  . En réponse à la dépêche La semaine québécoise de l'informatique libre. Évalué à 1.

    L'objectif de la semaine est de souligner l'importance de l'informatique libre, donc de faire connaître les enjeux et les solutions. C'est la première fois qu'elle a lieu, mais elle risque de revenir encore plus forte l'an prochain. Les dates ne sont pas encore déterminées.
  • [^] # Re: IBM demande à Sun de "libérer" Java

    Posté par  . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 1.

    > l'utilisateur s'en fout que la version OSX ressemble à la version
    > Win32, ce qu'il veut, avant tout, c'est qu'elle soit cohérente avec
    > les autres applis de son système)

    C'est pour ça que Sun a sorti SWT. Ce n'est pas aussi multi-plateforme que Java lui-même, mais c'est supporté sur quelques unes.
  • [^] # Re: IBM demande à Sun de "libérer" Java

    Posté par  . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 1.

    C'est très rare que c'est nécessaire de passer un Integer par valeur (clôné). Un Integer ne se modifie pas, une fois qu'il est instancié, alors tu ne devrais pas avoir peur qu'il soit changé par un autre thread.

    La seule situation où clôner un Integer peut être souhaitable, est si tu synchronises dessus. Mais encore là, ça dépend beaucoup du contexte, et je ne crois pas que ça arrive souvent.
  • [^] # Re: IBM demande à Sun de "libérer" Java

    Posté par  . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 1.

    > Mais dans un fonctionnement multi-thread, ca peut etre un peu plus
    > sur... Non?

    Oui, mais un bon programmeur s'en charge lui-même et synchronise à un niveau supérieur, là où c'est nécessaire pour son application. C'est plus rapide de synchroniser un bloc dans ta classe, où tu accèdes à la liste, que de synchroniser deux fois - dans ton bloc ET dans la liste.

    Un Vector, oui, c'est plus sûr, mais tu ne devrais pratiquement pas avoir besoin de sa synchronisation. Si tu ne veux pas prendre de chances, ok, mais un Collections.synchronizedList(new ArrayList(...)) fait tout aussi bien l'affaire.