NetBeans est coder en Java avec Swing et je le trouve pas lent ...
Arceus02 a écrit:
J'ai dit impossible ? J'ai exagéré car souvent on parle de personnes indépendantes qui codent depuis 3 mois. Il y a bien sûr des gros jeux (Runescape je crois par exemple) mais essaie seulement de le faire comme ça pour le fun en Java. Du fun, tu en auras, car niveau opti c'est pas le must. Après je suis peut-être en retard, mais pour moi le C++ reste plus rapide que le Java quand on sait bien l'utiliser au niveau de la mémoire et autres. Un exemple : beaucoup de joueurs de Minecraft pleurent que Minecraft soit en Java. J'ai joué à la version Alpha qui présente un jeux similaire à Minecraft mais codé en C++, et la différence de fluidité est nette.
Mais j'encourage les développeur à démontrer que Java est plus puissant qu'il n'y parait si ils le peuvent, je ne souhaite que ça même.
Arrêter d'utiliser minecraft pour montrer l'efficacité de Java! Il a été codé avec les pieds avec aucune optimisations; vous trouverez des tonnes de minecraft-like en java qui ram pas...
Sinon pour l'utilisation de java j'ai pas assez de recul pour en juger mais il parait que le système de socket est plutôt foutu non ? Ce qui encouragerai une utilisation serveur..
Pour le mobile je suis même pas sur, pour certain cas oui, mais la mode est dans plus en plus d'utiliser du HTML5(Facebook par exemple) ça permet d'être portable sur tout les OS mobiles. Donc l'avenir n'est pas Java je pense
Malheureusement je ne peut montrer que ce que je connais. Merci d'agrandir mes connaissances. Mais malheureusement (toujours) les Minecraft-like ne gèrent pas autant d'informations et de processus. C'est en effet très mal optimisé (d'où par exemple optifine) mais il n'empêche que l'on est pas tous fous d'optimisation. Et les personnes lisant ce post ne seront pas des personnes expérimentés qui savent déjà pour quoi ils peuvent utiliser Java, et sûrement qu'ils n'optimisent pas bien (moi même d'ailleurs je me rend toujours compte que je peut optimiser mais j'ai la flemme de le faire).
Tu ça pour dire que java est au débutant plus difficile de faire quelque chose qui rame pas. C'est un peu absurde ce que je dis étant donné la simplicité de Java dû à son très haut niveau, mais c'est le ressenti de mon expérience personnel. Peut être que je suis un pingouin unijambiste tétraplégique, mais j'ai l'impression de ne pas avoir été le seul à me détourner vite de Swing par exemple, mais en même temps beaucoup ne savent pas qu'il existe des alternatives à Swing. Nabila par exemple a tenter de développé avec Swing, et cela lui à laissé des séquelles.
Trêve de plaisanterie, Java quand on débute c'est chiant par ce que c'est lent.
Java quand on débute, c'est surtout "lent" parce que personne ne t'apprends comment le gérer parce "c'est automatique y'a rien à gérer" (et aussi parce que énormément de profs de Java sont mauvais).
Oh et aussi il y a une vieille impression de lenteur soit à cause de Swing et consors, soit à parce que c'était vrai il y a 15-20 ans sur d'antiques JVM...
C'est aussi peut être lent parce que des personnes le disent
Pour mes utilisations il convient parfaitement et son haut niveau est très agréable et te permet parfois de te concentrer sur le côté algorithmique. Mais je ne me vois pas faire de MMORPG avec. Quoique ...
Arceus02, merci de faire un effort sur tes posts. Certaines phrases sont difficiles à comprendre.
"Parce que des personnes le disent" est l'une des pires justifications qui existent dans tous les domaines, en particulier en informatique où tout évolue très vite.
Si Java a réellement été très lent à ses débuts, il a fait d'énormes progrès depuis, surtout avec l'arrivée des JVM JIT (il y a environ 15 ans). Avec celles-ci, les portions critiques de codes sont compilées en langage machine, le programme dans son intégralité atteint donc des performances proches des langages compilés (pas identiques, parce qu'il y a toujours des portions non compilées, parce qu'on ne peut pas optimiser autant et parce que Java doit gérer ses automatismes).
A l'heure actuelle, les problèmes de performances avec Java ne viennent pas du langage lui-même mais :
D'une source extérieure : requête SQL, composants non-java, congestion matérielle indépendante du programme (I/O, réseau, etc), ...
D'une erreur de conception (mauvaise utilisation d'outils comme des pools de connexion ou de threads, mauvaise utilisation du langage en générale due à une incompréhension).
Le modèle mémoire, en particulier, est très spécifique, à peu près jamais correctement enseigné et mal compris. Ceci fait que beaucoup de programmes ont des problèmes dans la gestion de la mémoire, ce qui participe à cette légende qui dit que Java est très gourmand en mémoire. Il est bien sûr plus gourmand que du code natif (notamment à cause du système de garbage collector), mais bien géré il reste tout à fait raisonnable.
La raison, en gros : pour éviter de passer du temps dans le garbage collector, Java (ou plus exactement la JVM standard) va utiliser au maximum la RAM allouée - qui est par défaut assez imposante. Comme le développeur lambda pense que "garbage collector = pas besoin de gérer ses objets", il en crée beaucoup trop, donc la mémoire allouée est très vite remplie.
PS : Il faut arrêter de croire qu'un MMORPG c'est le summum en terme de puissance demandée. La plupart des clients sont en réalité assez légers par rapport à d'autre jeux (graphismes simples, ...) et les serveurs font un travail de serveur, dans lequel Java excelle. D'ailleurs, énormément de gros sites de vente en ligne (sans doute les sites publics les plus complexes) sont en Java, c'est sans doute pas par hasard.
Ce n'est pas le sujet, mais j'ai surtout moddé. Je connais les bases mais je ne saurai pas par exemple faire un rendu optimisé d'une scène en temps réel. Pour le réseau je connais les bases pour différentes communications. La physique, pas tellement non. Du tout même.
Mais ce qui est bien dans la programmation c'est que l'on peut toujours en savoir plus. Et avec des sites commes le site du zéro et les javadocs bien faites, et HOP !
D'ailleurs je trouve que Java est très bien documentée. Du moins pour les librairies et APIS que j'utilise.
Tout d'abord excuse moi mon manque de clarté. Fatigue, clavier mobile, toussa toussa.
Ensuite j'étais ironique quand je disait "parce que des personnes le disent." C'est justement un des arguments qui fait partie des non-arguments, pour beaucoup de sujet.
Et enfin je te remercie beaucoup, car tu as quand même pris la peine de m'expliquer des choses que je ne savais pas. Alors merci.
Quand je parle d'optimisation, je parle pas d'optimisation bas niveau, mais des choses plus simple, par exemple pour minecraft, il y a beaucoup de cube/texture/eclairage, qui sont calculé alors qu'il y en a pas besoin ....
Par contre je suis d'accord avec toi et la javadoc c'est très agréable d'avoir un système unifié pour la doc, et ca oblige à commenter son code !
A propos du sujet sur Java et les interfaces graphique :
Java possède un excellent projet qui permet de créer des interfaces graphiques: Eclipse RCP. Il est basé sur SWT mentionné dans les messages précedents.
Attention à ne pas confondre Eclipse-"l'environnement de développement" pour créer vos projet et Eclipse-"la plateforme". Le code d'Eclipse est un model d'exemplarité et il peut être utilisé pour créer d'autres applications graphiques que l'environnement de developpement du même nom. Si vous avez un peu de temps lisez ceci , le projet a beaucoup évolué (en bien) depuis 2006 mais cette introdution d'Eclipse RCP présente les grandes idées qui sont grosso modo restées les mêmes.
Eclipse a été créé par IBM pour construire tout plein d'applications. Une de ces applications fut l'environnement de développement mais pas que. Eclipse est devenu Open-Source, une Fondation s'en occupe. Aujourd'hui Eclipse est utilisé par de nombreuses entreprises ainsi que par de nombreux projets open-source pour créer des applications graphiques.
Il n'y a pas de tutoriel sur le site du zéro (du moins j'en ai pas trouvé) mais il faudrait! Je ne suis malheureusement pas à jour sur Eclipse4 et ne dispose pas du temps suffisant pour me lancer là dedant. Si vous lisez l'anglais la référence pour apprendre Eclipse RCP est l'oeuvre d'un allemand très actif sur le projet: Lars Vogel.
Il n'est pas hors de question de développer des jeux Java de nos jours. Tu n'as peut-être pas lu le débat ou tu as des convictions solides anti-java pour les jeux vidéos
Arceus02 : Deuxième réponse, j'ai de solides raison de penser que je ne suis pas près de voir un Call of Duty en Java. Voici, à mon humble avis la raison qui fait que, perso, j'aurai du mal a me lancer dans la création d'un jeu vidéo en Java : "Il y a beaucoup mieux !"
1 D'abord il faut faire avec l'existant: les moteurs physique, les moteurs de rendu, tout un tas de librairies, et d'outils pour développer des logiciels de jeux vidéo sont disponible en c++ mais pas en Java (il y a un raison à cela que j'essaye maladroitement d'expliqué dans le point 3)
2 Les languages et les compilo sont adapté à un usage. La JVM peut être vue comme un middleware dont le surcout a ses avantages pour faire tout un tas de choses: saviez vous qu'on peut même modifier le code alors le programme est lancé ! Tout plein de chose dont les jeux vidéo n'ont pas besoin .. quoique pour des MMO je sais pas.
3 Compiler c'est pas si trivial que ça, quand on s'interesse aux performances ... (je parle de java à la fin) Aujourd'hui le kernel Linux est compétitif avec le kernel windows au niveau consommation d'energie pour mon plus grand plaisir mais c'est le fruit de très longues années de travail. Le kernel linux est compilé avec gcc tandis que le kernel windows est compilé avec les compilateurs fournient pas ceux qui fabriquent les processeurs (Intel, AMD). Mais, mais .. le kernel Linux n'a pas trop besoin de faire des calculs impliquant des nombres réels (à virgules) tandis que dans le code des jeux vidéo .. comment dire : il n'y a que ça ! Donc si tu t'amusais a compiler un code de jeu vidéo avec gcc ou plutôt g++ et un compilo Intel tu verai une différence de performance de 1 à 10 minimum. Donc : même entre des compilateurs c++ il y a des différences qui impacte beaucoup les performances que tu peux obtenir pour ton jeu vidéo. Alors ... du bytecode Java avec sa vingtaine d'instructions ... est juste hors compétition => Il suffit de regarder les specifications minimals demandé par les jeux qui sortent sur le marché !
Si tu souhaites coder dans un truc qui ressemble beaucoup à du Java pour faire du jeux vidéo je conseil le D (trolololo) Ce language possède les qualités de base requisent pour développer du jeu vidéo.
Ouais enfin tout ça est hors sujet. Le jeu vidéo ça se passe dans le GPU, ça fait des années que le Java a des perfs algorithmiquement proches du natif et tout ça est un débat d'arrière-garde.
Arceus02 : Deuxième réponse, j'ai de solides raison de penser que je ne suis pas près de voir un Call of Duty en Java. Voici, à mon humble avis la raison qui fait que, perso, j'aurai du mal a me lancer dans la création d'un jeu vidéo en Java : "Il y a beaucoup mieux !"
C'est sensé être un argument? sans rire? tu aurais pu dire que comme le temps est doux, on boit pas trop de café donc exit java, tout aussi valable...
toujours la même question, "et sinon c'est quoi le problème d'utiliser JNI pour faire un jeu en java?"
Par contre comme argument ce serait bien que tu nous montre un jeu que tu as fait qui met le CPU à genoux(ou qui le mettrait si il était en java...).
Blague à part, aucun moteur de jeu sérieux ne propose une couche haute en C++, au profit de langages virtualisés voire interprétés (Que ça soit UnrealScript, C#, Lua, etc). Autant pour le jeu vidéo en natif...
J'ai écris un peu de CUDA il y a pas si longtemps que ça et j'ai rien vue d'autre que du c++ dans les softs de rendu (c'est vrai que c'est pas vraiment du jeu vidéo) :( Mais bon il semble que je raconte de la merde. Merci pour la leçon.
Non, tu racontes pas de la merde, juste une partie de la réalité. Tant qu'on reste dans les parties les plus bas niveau (rendu, physique, calculs en général) c'est très souvent du C++ qu'on retrouve, ou du C quand il n'y a pas d'API C++. Mais un jeu vidéo c'est beaucoup plus que simplement ça, et l'incroyable difficulté du C++ fait que personne dans l'industrie n'en fait si c'est possible de l'éviter.
Les raisons pour laquelle java est bien pour faire un jeu(remplacer java par c#, ou ce que tu veux avec des perfs acceptables, pas de gestion mémoire et pas de compilation)
-pas de compilation, le temps gagné est juste énorme, surtout lors des équilibrages de gameplay.
-pas de gestion de la mémoire, ça veut pas dire qu'il faut pas faire attention, mais ça reste nettement plus simple, et l'absence de manipulation directe évite bien des soucis.
-JNI(j'utilise ogre/bullet/openal sur mon jeu), si on manipule que les pointeur(adresse stockée coté java et reinterpret_cast<type>(adresse) coté c++), c'est plus qu'acceptable pour les perfs, et on a un système compatible avec toutes les lib c ou c++.
-les langages de script, avec la JSR 223, on a une abstraction du langage de script, on peut utiliser ce qu'on veut et inter-changer sans probleme.
-l'écosystème et l'api(facilités sur tout ce qui est réseau, threads...),outils dispos
-les perfs, java est plus lent que le c++, mais j'ai pas encore vu de jeu dont le cpu était le facteur limitant(sauf config absurde avec un celeron et une CG haut de gamme)
-portable: dans le sens ou pas besoin de recompilation, si on cible plusieurs systèmes, suffit de mettre à jour un .jar tant qu'on a pas modifié les composants natifs.
Les raisons pour laquelle java n'est pas bien:
-consommation de ram plus importante: faut charger la JVM(et démarrage plus lent).
-déploiement, la gestion des ressources est pénible dans le cas, par exemple, de l'utilisation d'un système de fichier virtuel.
-verbeux(pas de lambda, ni de surcharge d'opérateur, pas de RAII (meme si avec java7 et le try with resource ça s'améliore)).
-lire et relire les aprioris des gens sur les forums qui n'ont jamais essayé(ou même n'ont jamais fait de jeu) mais qui savent que java pour faire des jeux, c'est nul.
Les lambdas de Java8 sont juste épiques, j'ai assisté à une conférence d'un des développeurs de cette fonctionnalité (pendant un Chti JUG), c'est juste énorme.
Maintenant, c'est évident que "java n'est pas fait pour les jeux" c'est de l'a-priori, surtout quand on n'a pas l'expérience des jeux vidéos. Maintenant, je pense qu'en terme de qualité de développement il existe des langages plus modernes et moins verbeux (donc plus rapides à mettre en place) qui auront un résultat au moins aussi bon, voire plus si ce sont des langages qui ont une affinité particulière avec la plateforme utilisée (par exemple C# pour un jeu purement windows, ou bien visual C++).
Je n'aime pas coder en Java, c'est vrai, maintenant, à part les gros soucis d'utilisation en ce qui concerne Swing, le langage possède des particularités non négligeables du fait qu'il soit "interprété" (les guillemets ne sont pas là pour rien). Je cite souvent l'introspection, la résolution dynamique (et d'ici peu les lambdas, qui je le rappelles sont géniales).
C++ est un langage qui permet de bien meilleurs performances côté GPU, mais c'est clair qu'avec JNI/JNA on peut aller chercher des perfs casi équivalentes.
Maintenant, je pense qu'en terme de qualité de développement il existe des langages plus modernes et moins verbeux (donc plus rapides à mettre en place).
A noter toutefois que plus verbeux signifie dans le cas de Java plus simple a maintenir, ce qui contre balance assez fortement le temps supplementaire passé a ecrire le code, en comparaison a un code en langage peu verbeux mais difficilement dechiffrable. C'est d'autant plus vrai que les IDE Java sont geniaux et minimisent la perte de temps initiale.
(Pardon pour la forme et les accents, qwerty sur iPad...)
>A noter toutefois que plus verbeux signifie dans le cas de Java plus simple a maintenir, ce qui contre balance assez fortement le temps supplementaire passé a ecrire le code
Tu trouves? En quoi ajouter vingt mots clefs redondant et assez longs augmente-t-il la lisibilité face aux getteurs/setteurs de C#par exemple? Au contraire, c'est bien plus immédiat à voir en C# qu'en Java.
>C'est d'autant plus vrai que les IDE Java sont geniaux et minimisent la perte de temps initiale.
Tu trouves? En quoi ajouter vingt mots clefs redondant et assez longs augmente-t-il la lisibilité face aux getteurs/setteurs de C#par exemple? Au contraire, c'est bien plus immédiat à voir en C# qu'en Java.
Question d'habitude, je viens d'aller voir la doc de C# pour voir comment c'est écrit (j'ai fait presque 6 ans de Java) et bien c'est pas évidant au début, (je suis même pas sur d'avoir bien compris il faudrait que je code un peu pour voir).
Après redondant je dirais que non, tu peux avoir des getteur/setteur protected/default pakage juste pour limiter certain accès (dans le cas de classe abstraite en général).
Peut être que le modifieur par défaut n'est pas bien choisie c'est peut être ca.
>Après redondant je dirais que non, tu peux avoir des getteur/setteur protected/default pakage juste pour limiter certain accès (dans le cas de classe abstraite en général).
Donc tu dois définir un attribut + un getteur + un setteur. Avec à chaque fois les types, les noms de répétés, les accolades...
C'est ultra redondant :
public class essai{
private String attribut;
public String getAttribut(){
return this.attribut;
}
protected void setAttribut(String value){
this.attribut = value;
}
}
par rapport à
public class Essai{
public Attribut{
get;
protected set;
}
}
PS : je précise pour tous ceux qui me taxeraient de "troll" que je ne prends ici les attributs que comme exemple, comme il s'agit d'une notion basique dans les langages objets, cet exemple est accessible à tout le monde, même ceux qui n'ont fait que du Java.
Certes je n'aime pas le java, mais c'est un langage qui reste tout à fait utilisable. Je ne m'y retrouve juste pas.
ça fait un certain temps que j'ai pas codé en C# donc ça à peut-être évolué depuis mais de toute façon quand tu dois vérifier les invariants tu te retrouve quand même avec une construction verbeuse en C#
public class Essai{
private int _attribut;
public Attribut{
get { return _attribut};
set
{
if(value < 0)
{
throw new Exception("Negatif");
}
_attribut = value;
}
}
}
Pour les attributs "simple" c'est plus rapide c'est vrai mais si tu fais attention à la cohérence des données, en Java je trouve ça plus accessible :
public class Essai {
private int attribut;
public int getAttribut() {
return attribut;
}
public void setAttribut(int newAttribut) {
if(newAttribut < 0) {
throw new IllegalArgumentException("negatif");
}
attribut = newAttribut;
}
La force de java c'est les outils qui sont autour. La communauté de Java à mis en ligne nombre d'outils pour la qualimétrie du code. PMD, CheckStyle... Tous ces outils sont regroupé dans un serveur Sonar.
Quand on fait du code à plusieurs il faut avoir un système de contrôle continue pour être sur de pas tout casser à chaque fois. Ca passe par des versions du code (pour revenir en arrière au cas où) avec GIT ou SVN (ca c'est pour tous les projets de code), par les tests automatisé JUnit (ou les assert Java 1.5 dans le code), et par un serveur d'intégration continue comme Jenkins (ex hudson).
Donc pour pas se prendre la tête quand on est plusieurs à développer il faut trois serveurs, GIT/SVN, Sonar et Jenkins. Tu programme test tous les soirs (si des modifications on été faite sur le code via GIT/SVN) par Jenkins qui va envoyer les test de qualité du code à Sonar.
Je suppose que des outils existe dans les autres langages mais en java il sont bien développé et maintenu.
Il faudrait être plus précis : Java est bien pour des applications légères ou des jeux légers (notamment en terme de GUI), mais impossible pour des gros jeux style MMORPG 3D vue troisième personne avec pleins de fenêtres et de boutons (encore que, avec LWJGL et ses propres objets on peut créer des trucs sympas) ou le prochain toshop. De plus, même en Obfuscant le code il reste plus "exposé" au hack, pour les applications nécessitant plus de sécurité.
Ah oui ?? Et que penses-tu de Runescape ?? un Énorme MMORPG fait par JAGEX, 3eme personne, ce jeu est en fait une Applet en ligne multijoueurs qui ne bug presque jamais. Ce jeu évolue CONSTAMMENT !!! Surtout côté graphique ! Si seulement tu verrais leur ÉNORME site. Bref, je ne suis pas vraiment d'accord avec toi lorsque tu dit que Java est impossible pour les jeux comme tu le décrit. Moi j,ai déjà un peu (je dis bien un peu) codé en action-script, et je trouve pas vraiment d'avantages au java(à part la facilité), déja, dans les jeux en flash on ne peux pas integrer de clic droit , bref pour moi, je pense que tout ce que peuvent faire les autres langages sont faisables avec JAVA, il faut juste un peu de patience et de volonté.
+1
C'était effectivement mon opinion avant (celle que tu as cité) mais maintenant j'ai pris conscience que Java est un langage qui permet tout, même des gros jeux grâce aux nombreux arguments apportés au débat.
Des tutos surtout et gratuit|Déboguez php|Un cours sur ASP.NET MVC
Des tutos surtout et gratuit|Déboguez php|Un cours sur ASP.NET MVC
Des tutos surtout et gratuit|Déboguez php|Un cours sur ASP.NET MVC