Bon, a priori, c'est impossible. J'voudrais juste avoir confirmation qu'une solution indépendante de l'OS n'existe pas, avant d'utiliser du C via JNI.
Merci.
 
EDIT : parce que j'trouve ça un peu étonnant qu'on n'puisse pas avoir de numéro unique pour un matériel donné en Java...

http://onesearch.sun.com/search/de [...] +retrieval

...Merci, c'est déja fait!
Les quelques réponses qu'on y trouve disent que c'est impossible. Comme tout le monde peut se tromper, je demande ici aussi.

Même sans parler d'adresse MAC, un numéro issu du matériel composant la machine sur laquelle tourne un programme, non plus ?

Un dernier remontage avant la solution alternative qui me plait pas trop...

C'est pas supposé être indépendant du matériel le Java?

Ben, si!  ça n'empêche pas. Le matériel, il l'utilise quand même.
A un autre niveau par exemple, DirectX est indépendant du matériel aussi. Il est pourtant capable de savoir avec quel modèle il bosse (enfin j'imagine).

 
il y a une différence entre une virtual machine utilisant les resources de la machine physique, et une virtual machine exposant ces données à l'utilisateur. Ca introduit la notion de hardware et compagnie.
 
Et clairement dans le cas de Java on s'en branle de savoir sur quelle carte graphique on fonctionne, etc. Le but étant justement de pouvoir l'utiliser sans savoir ce qu'il y a derrière
 
Pour DirectX tu ne pouvais pas prendre pire. Va voir comment ça fonctionne avant de le prendre comme example

 
Ha... ça va me manquer pendant les fêtes ça. Ce ton tellement sympathique de mon ami Darklord.
DirectX je sais comment ça fonctionne (en gros, évidement), et c'est vrai qu'en fait je vois ce que tu veux dire. En gros, Java ne bosse pas avec le hardware, il délègue ça à l'OS, alors que l'intéret de DirectX, c'est justement de dialoguer avec le matériel. ok, ok, ça me va. J'passerai par du C.

miam une fonction native en vue

En fait la taille des entiers (32/64 bits) fait chier en java.
Je me souviens plus exactement pourquoi, peut-être des problèmes de performance.

voir, sans qu'il y ait de carte graphique

oui, mais là ça va pêter le HeadlessException dans les chaumières.

pas si t'utilises pas de classes graphique
 
et puis de toute façon tu les verras pas

Pendant que je te tiens, comment on fait pour debugger des exceptions qui ont lieu dans le thread de répartition des événement swing ?
 
Ce thread à la con a un "catchall" en haut de la pile, ce qui fait que les exceptions ne remontent pas dans le debuggeur, mais il affiche simplement la pile puis il continue son boulot peinard.
 
C'est lourd, car des conneries dans un listener quelconque, on en a des possibilités d'en faire (surtout moi j'ai remarqué en fait) !

ben tu mets des breakpoints dans les sources du jdk à l'endroit où l'exception est générée ...

heu oui, mais c'est lourd (passeke j'utilise assert), y'a pas un vrai truc de prévu ?
 
Au pire une petite bidouille style "convertir tous les assert en breakpoint conditionels" dans un sous-menu, mais j'ai pas trouvé (eclipse).

nan je pense pas ... mais il suffit que tu mettes un breakpoint sur le constructeur de AssertionException

java.lang.AssertionError
 
C'est une erreur, on continue pas sur une assertion
 
ok, ouais, sinon, ça va être breakpoint dans Trowable() en espérant qu'à peu près tout le monde l'appelle. Merci.

dans idea y'a une option du debugger pour breakpointer automatiquement sur toutes les exceptions je crois

bizarre ... ce serait plus logique que ce soit une RuntimeException. donc, dtc toit moi même