BreizFenrir a écrit :



C’est pas tout à fait faux mais j’ai l’impression en te lisant que tu les mets exactement dans le même panier que des langages comme Javascript, ce qui n’est pas non plus tout à fait vrai. Indépendamment des optimisations comme la compilation JIT, aussi bien Java que .Net utilisent des langages intermédiaires qui sans être du code machine restent bien moins coûteux à évaluer que l’interprétation en live du code tel que tapé par le développeur.



Mais effectivement, contrairement à du code compilé en langage machine, on est obligé de disposer d’une couche logicielle chargée de traduire les instructions.







je “vulgarise” sûrement trop mais non y’a clairement une grosse différence entre JS, java, etc… mais bon je vais pas taper 500 lignes histoire d’être ultra précis, en général, je tranche dans le vif, et ‘a ceux qui ont l’habitude voir qui font pareil et comprennent de suite et les autres qui demande des précisions " />

liukahr a écrit :



Attention, je vais pinailler :

GCJ ne permet-il pas de compiler du code java en code machine ?

Est-ce du natif dans ce cas ?



:-)





en fait Java est un peu batard, il est l’un ou l’autre selon le cas, mais est la plupart du temps utilisé en tant que langage interprété.

Alucard63 a écrit :



Non Java a été conçu comme un langage interprété par une VM( le bytecode n’est pas du code natif ).



Ensuite comme pour tous les langages on peut( et on a ) créer un compilateur en natif…" />





non, tu as des puces qui permettent de ce passer de VM et donc de bytecode, qui compile directement du picojava (instruction similaire à l’asm.



et GCJ, si tu prend 10secondes et lit la description“It can compile Java source code to Java bytecode (class files) or directly to native machine code” peut compiler vers du bytecode comme il peut compiler vers du code machine directement.



Java n’a pas été conçu que comme un langage interprété, mais Sun pensait à l’époque que tout le monde voudrait s’équiper de leurs puce maison, qui permettait de ce passer de VM, ce qui ne fût le cas, et la parti interprétée est plus restée au fil des évolutions, mais tu peux très bien compiler directement en code machine avec du Java, théoriquement, pourvu que tu es le bon matos.

L3G0 a écrit :



C’était une vraie question innocente de novice. Parce qu’à un moment HTML5 c’était la panacée (surtout quand ça permettait de taper sur flash) mais on en revient un peu ?





ben l’html5 c’est pas encore complètement standardisé etc… donc avant de réellement le voir en marche etc… y va se passer quelques années, vu la lenteur du W3C à faire quoique ce soit.



Après l’HTML5 doit effectivement permettre de ne pas être dépendant de la plateforme etc… mais pour moi, dèv web à contre coeur, c’est pas le flash qui pose le plus de problème, bien qu’il y ai des problème de ressource avec flash, le problème, c’est qu’internet à la base c’est un système de présentation d’information formatée, donc desp ages statiques avec 3 pauvre truc pour t’indiquer la couleur, la font etc…



mais ça a tellement bien fonctionner qu’ils ont tous voulu aller plus loin, dans des périmètres qui n’étaient absolument pas ceux pour lesquelles l’HTML avait été conçu, et donc on à commencer à faire des pages statique avec des liens dans tout les sens, puis des pages dynamiques, et la depuis c’est le drame, le réel problème, pour moi reste javascritp, le cycle de vie des pages (et du coup le cycle de vie des données) dans des technos comme asp.net, qui est très différent du cycle de vie des données d’une applies desktop …



de plus, perso je trouve qu’avec le web, le boulot sur l’interface est tellement plus lourd que je suis pas sur qu’on soit si gagnant que cela, mais il reste quand même des avantages.

satandierbis a écrit :



Explique moi pourquoi les gens de mozilla parlent de NativeUI pour des interfaces (et pas que) codées en java.







nativeUI, cela veut dire, je pense (car je suis pas expert dans cette techno) que cela utilise des éléments graphique de langage natifs justement, de la même façon qu’en java tu as JNI et JNA, qui permettent d’utiliser du code natif (C/C++), elles ont bien le mot native dans leur nom mais ce n’est pas du langage natif pour autant.





Native ça prends le sens qu’on veut mon petit " />





non, absolument pas, un langage natif est un langage qui n’est pas interprété, il passe cirect par le compilo et c’est fait, ça n’a pas un sens dans un contexte et un autre dans un autre contexte…

satandierbis a écrit :



La seule définition claire de natif c’est x86, ppc, arm… tout le reste c’est déjà du flou artistique.



T’as le droit d’être obtus et de n’accepter que ta définition, mais quand mozilla (et probablement facebook) parlent de natif, comprends que C’EST PAS DU C++





ben en même temps aujourd’hui tu n’en as pas des dizaines d’autres … surtout dans le contexte des smartphone, je doute qu’on code en pascal, basic, cobol ou fortran sur smartphone, donc dans ce domaine quand on parle de natif c’est du C/C++, car le seul cas ou java est un langage natif c’est quand le device est équipé d’une puce spéciale et qu’il ne s’exécute pas sur un VM, chose assez rare, et qui a ma connaissance ne se voit pas sur les smartphones.



d’ailleurs vu la popularité décroissante de la plupart des langages compilés, aujourd’hui assimilé langage natif à C/C++ n’est pas une énorme erreur non plus.



Donc tu as raisons en disant que langage natif != de C/C++, mais tu as tords dans notre cas, qui ce concentre sur le domaine des smartphones, où le C/C++ sont, à ma connaissance, les seuls langages natifs à pouvoir s’exécuter.

Alucard63 a écrit :



Je savais que ça venait de l’embarqué au début mais je crois que le prof avait surtout insisté sur le fait que ça avait été pensé comme interopérable dès le début grâce à la VM( c’est surtout ça que les élèves doivent mal comprendre je pense )." />





Oui en effet, les deux côtés étaient dans leurs pensés au début je pense, la réalité les a rattraper par la suite " />



Disons que le java a été conçu avec 2 objectifs distincts dès le début, l’embarqué et l’interopérabilité, l’un n’allant pas avec l’autre en général, sauf grosse erreur de ma part, l’embarqué en général c’est quand même des cibles bien précises et plus ou moins sur mesure donc l’interopérabilité … " />



mais bon java n’a jamais réellement percer dans l’embarqué, bien qu’il y ai eu quelques projets par-ci par-la. Après, android … j’aime pas trop donc je n’ai jamais regarder de très près, mais faut que j’avoue que je serais curieux de savoir ce qui s’exécute vraiment au final derrière, par exemple le java, il passe par une VM du coup, non ? au final, les micro-instructions c’est quoi sur android ?? de l’asm ?? mais bon la flemme de chercher, la plateforme m’intéresse tellement peu " />