Une application Native en JAVA, j'en aurais lu des connerie sur ce site ...

Et pourtant une application native pour Android est belle et bien dans un dérivé de Java...

Je vais peut-être dire une bêtise, mais ça n'existe pas les processeurs exécutant directement le code JAVA ?

PicoJava, Majc (quoi que c’est du code compilé JIT là), Cjip, aJ-100/aJ-102, JStar (dans une certaine mesure, vu que c’est plutôt un « accélérateur JAVA » à incorporer à un CPU existant)…

Si tu connaissais ton sujet, t'insulterais pas : y a pas mal d'appareils mobiles qui sont capables de travailler directement sur du bytecode java, notamment ce qui est basé sur du ARM (il y a une extension du jeu d'instruction adaptée à ça)

Je crois qu'on lui a fait peur, il va plus vouloir revenir

Java = ByteCode = Language Interpreté != de code natif.

Là on est pas d'accord, il existe bel et bien des processeurs câblés pour les instructions JAVA, ils n'ont pas besoin de machine virtuelles, ils interprètent directement le ByteCode... ces processeurs n'existent pas encore pour les téléphones portables, mais les processeurs sur architecture ARM peuvent le faire, s'ils sont équipé de la technologie JAZELLE, voir avec la société ATMEL par exemple à Nantes

En me basant sur mes connaissances peut-être dépassées puisque ça fait un bail que je ne me suis pas intéressé à ce sujet, je suis un peu d'accord avec Zymoth. Comme vous le dîtes, il y a des processeurs "interprêtant" le ByteCode. Ils ne l'exécutent pas "vraiment" directement. Ils le convertissent en ensemble de commandes simples. C'est sûr que ça va plus vite qu'une couche logicielle qui traduit le ByteCode. C'est comme sur les bonnes vielles machines avec le BASIC intégré en ROM. Si on fait un programme en langage machine (tant qu'à y être, passons nous de l'assembleur intermédiaire et ses mnémoniques) qui appelle l'adresse où est stockée la commande "PRINT" du BASIC, je ne sais pas si on peut appeler ça du code "natif" (même si ça reste du langage machine donc natif ...).
Donc après, je ne crois pas qu'il existe une réelle définition de code natif .... A la limite tant que le processeur comprend directement une commande on pourrait dire que c'est natif (et du coup Zymoth a tord - j'ai dit que j'étais seulement "un peu" d'accord). Mais après si même exécuté directement par le processeur, le code est "lent" dû à un assemblage de commandes pas toutes nécessaires (c'est le problème d'utiliser des fonctions génériques), alors je ne sais pas si ça correspond à ce que la plupart des développeurs entendent par code natif ....
Voilà, tout ça pour apporter un peu d'eau au moulin de Zymoth même si je pense que le terme "natif" est mal défini.

Non, mais en suivant ton raisonnement, les CPU x86 récents sont pas x86 en natif... Ils interpretent tous le code et le transforme en RISC en interne.

JAZELLE (et d'autres), c'est du java en natif, en l'occurence sans passer par une machine virtuelle logicielle, donc.

Non, mais on te dit que les CPU lisent le ByteCode directement.

oui c'est vrai ... encore une couche en plus comme depuis le 80286 avec le mode protégé qui est encore utilisé (même si avec les x86-64 il y a moins de limitation).
On a l'impression que les couches logicielles sont passées dans les processeurs. Du coup ils sont moins rapides qu'en théorie sur le papier ... et le code natif d'antan n'est plus forcément le même aujourd'hui.
Enfin, en intégrant les langages de haut niveau dans les processeurs on facilite la vie des programmeurs. C'est marrant comme on revient aux machines qui avaient un langage de haut niveau en ROM (sauf que là c'est au niveau processeur).

non, mais l'intérprétation du code x86 en interne, c'est pour aller plus vite, hein (et c'est le cas). C'est un passage peu visible au RISC, même si la bataille CISC/RISC n'a plus lieu d'être.

C'est pas une couche en plus, c'est le fonctionnement du CPU, prévu pour fonctionner en RISC et adapté pour accepter du CISC en entrée, mais c'est dans le design, ça accélère, ça ralentit pas.