Voila je compte apprendre le jeva j´ai des tuto et tout mais je ne sait pas si il y a un logiciel comme dev c++ pour compilé, si il n´y en a pas j´ecrit le code ou?

dsl pour la faute au titre

alors, java comment ca marche.
tout d´abors un article de demystification de java: http://www.mandragor.org/article.php?id=3

donc si tu l´a lu tu sais que java ca utilise un SDK le SDK de java que l´on appele JDK.
c´est la seul chose neccaissaire pour compiler/executer du java.
dans l´idee tu tapes ton code dans notepad ( pour les windowsien, les autres trouverons) et tu compile ton fichier toto.java en executant en ligne de commande dans le repertoire " javac toto.java" ca te cree un fichier toto.class que tu execute en fait " java toto".

Bon, tu n´est pas obliger d´utiliser la ligne de commande il y a des IDEs plus ou moins bienf ait, je citerai netbean et eclipse sur lesquel tu peux te documenter en un coup de google.

Sur le site de sun, tu devrait trouvé tout ce qui va bien pour developper en java.
Le java ne se compile pas. C´est un langage " compiler en temp reel" en quelque sort ( d´ou sa lenteur). Tu peux le compiler ensuite pour aller plus vite, mais c´est plus multiplateforme.

lapintade: ce n´est pas formcent si lent que ca java.
Le fait que ce soit compilé en temps réel est meme un facteur d´acceleration...
en effet puisque tu sais au runtime ce qui t´arrive cela te permet d´optimiser ton code en " direct live"

Ben la JVM, c´est une couche logicielle par dessus le processeur, donc ca bouffe des ressources, donc ca ralentit tout non?!

Un langage interpretté est forcement plus lent. Je vois pas du tout comment ca peut etre un facteur d´accelleration.
Sinon par experience, les logiciels en java sont toujours trés gourmand en ressource et souvent plus lent.
Aprés pour les jeux, j´en sais rien.

non et non.
generalement ceux qui font du java le font mal.
mais il est tout a fait possible d´obtenir du java rapide, aussi rapide voir plus rapide que du C.

comme le dit fenix la JVM est une couche logicielle, mais ca ne veut pas dire que ce soit plus lent.
Basiquement c´est plus lent. Mais regardons un peu plus loin et faisons une correspondance avec le C++.

template < int x>
int carre()
{ return x*x;}

et int carre ( int x){return x*x;}

Ici l´exemple est simple mais sur un exemple plus complexe, on voit tout de suite, que le premier sera plus rapide que le second.
Mais le premier prends plus de place en memoire, et ca ca peut faire perdre du temps.

maintenant, imaginons que nous soyons au runtime et plus au compile time en java tu ecris:
public static int carre(int x){return x*x;}

si la JVM s´apercois que tu fais toujours un carre ( 2), il est possible que la JVM cree deux fonction
int carre(int x) et int carre2()
et d´un seul coup, le temps d´execution en moyenne chutte. ( orth: un ou deux t ? )

vous comprenez le principe ?
Pour info, c´est encore assez peu ( mais ca existe utilise dans le JVM 1.5.0 de sun, mais MS utilise cette technique de faon bine mieux adapter dans sa plateforme . NET

re reponses, parceque j´ai oublié quelque chose...
lapintade ecrit: " pour les jeux j´en sais rien"

la tu n´as pas completement tord, pour les jeux on constate souvent des performances pourri en java.
pourquoi, parceque les developeur java, n´utilise pas les caracteristique hardware de la machine et se limitent au couches logicielle.
alors forcement entre un blit de carte graphique et une boucle for de copi, ya pas photo sur les perfs...
( les developeurs GBA comprendront vite ce que je veux dire)

ensuite, sur les performances globale de java.
Generalement tout ce qui touche au graphisme est assez lent, parceque les couches graphique sont assez compliqué plein d´option dans tout les sens, et on a vite fait de ne pas utiliser la bonne option, de mal liberer une ressource ce qui fait que le thread AWT continue a travailler sur un objet graphique que l´on pense mort etc...
Si on utilisait ( et meme moi, je l´utilise mal, voir tres mal) bien les APIs swing, java serait bien plus rapide. La encore les APIs swing n´utilise pas les accelerations materielle et pose donc probleme.
mais d´autre APIs de graphisme " amateur" ont ete propose: les API swt ( de memoire, un coup de google nous fixera.) qui semble etre assez rapide.

finalement, on ne le dira jamais assez.
Rappelons que la rapidite d´un programme vient principalement des structures de données utilise et des algorithmes sous jacent, et PAS du langage utilisé!

Pour confirmer mes dires, ecrivez un tri a bulle en C et un tri par tas en java.
ensuite, vous optimisez a mort les deux codes.
je prends le pari, que java est rapidement ( c´est a dire vers des tableaux de 10000 elements) plus rapide ( hors temps de chargement/dechargement de la JVM).

un langage interprete ne peut PAS etre plus rapide qu´un langage compile, tout simplement parce que tout ce que fait la JVM pour optimiser, tu peux le faire nativement dans le langage compile.. Donc c´est p-e un peu plus contraignantm, mais au moins on sait ce qu´on fait. Reste donc le temps d´interpretation du byte-code en defaveur du langage compile.

dans ton exemple, un programmeur C/C++ qui sait que sa fonction sera appelees de nombreuses peut facilement mettre en place un cache des resultats interessants, faire bosser le precompilo, etc.

" le temps d´interpretation du byte-code en defaveur du langage INTERPRETE"

bien sur.. sinon ca n´a plus de sens

Le langage compilé doit parfois se contenter d´une compilation ´Worst - Case´, comme l´explique si bien godrik...

Et si l´interpreteur generait du code natif au lieu de directement l´interpreter ? On shunterait donc la bete partie interpretation des opcodes...

Enfin bref, lisez ça :
http://www.research.ibm.com/journal/sj/391/suganuma.html

Ca vous fera du bien

LGV:
tu pose le probleme du offline/online qui est bien connu des gens de l´ordonnancement.
un compilateur, fait un travail a priori, tu ne sais pas quelles sotn les données que tu vas avoir. tu ne le saura qu´au run-time.
Quand tu ecris ton code, tu ne sais pas vraiment dans quel condition il sera utilisé ( c´est de plus en plus vrai avec les outils libre). D´ou l´interet d´avoir un " moteur d´optimisation".
Apres bien sur ta JVM a été fait en C ( probablement, en fait, je ne sais pas). et donc fondamentalement tu pourrais refaire la meme chose.
En outre, cela te prendrais longtemps et tu le ferai probablement ( moins de temps) moins bien qu´eux...

ce n´est pas une idee nouvelle, mais ce que je dis c´est que rien n´empeche de mettre en place les memes mechanismes que ceux supportes par une VM dans ton code compiles.
On sera tous d´accord que dans le langage interprete, le programmeur se repose sur la VM, tandis que dans un langage compile il doit lui meme mettre en place tout ce dont il a besoin. C´est plus complique, et explique pourquoi un code " naif" peut etre plus rapide en version interprete que compile ; mais a ce moment la ce n´est pas le langage qu´il faut mettre en cause, mais le programmeur.

Et pour recentrer le debat, si on veut faire du java, il existe des outils tels que vim, Eclipse ou netbeans.

^^^ oui voila on est d´accord sur le fond, en lisant ton dernier commentaire :D

vim ? et pourquoi pas cat et echo aussi !

quitte a faire dans le console, autant utiliser emacs!

lgv: vivi, on est bien d´accord!
Mais je pense que ca valait le coup de souligne le fait que du java peut etre rapide en vertu de technique d´optimisation on-line

mais bon, qui n´as jamais fait de :
float cosinus[360];
ou de truc du meme genre!

mais bon, qui n´as jamais fait de :

float cosinus[360]; ou de truc du meme genre!

moi

Bon j´ai mon propre avis sur la question pour en faire souvent, et programmer des arbres binaires, des map, des hash table simple et double et avoir deja fais des jeux, vois sur notre site...
Je trouve le java bien plus lent que le C++, du point de vu jeu, c´est tout simplement horrible ^^.

Sinon pour comparer la vitesse de calcule des deux langages il faudrait que j´implemente les meme programme en C++, ensuite je comparerais.

" Un langage interpretté est forcement plus lent. Je vois pas du tout comment ca peut etre un facteur d´accelleration."

Pour JYY et LGV :

Pendant le prologin, on parlait avec les orga d´une étude publié par HP ( faudrait que je la retrouve) où il ont montré ( et réalisé en parti) qu´un programme interprété pouvait s´éxécuter plus vite que le même programme compilé si la machine virtuelle " analysait" correctement le code et le déroulement en temps réel, pour savoir quel optimisation y apporter. Des optimisation qui ne sont pas possible à la compilation car on ne sait pas dans quel conditions va s´exécuté le programme.
Tout ça c´était très théorique, mais ça montrait " bien" qu´on pourrait réussir à inverser la croyance ( et pour l´instant réalité) qu´un programme compilé peut être plus lent que le même programme interprété.