Android Studio disponible pour Linux, OS X et Windows

Android Studio disponible pour Linux, OS X et Windows

Let's code

Avatar de l'auteur
David Legrand

Publié dans

Logiciel

16/05/2013 2 minutes
83

Android Studio disponible pour Linux, OS X et Windows

Suite à l'annonce de son nouvel IDE, Android Studio, l'équipe de Google vient de mettre en ligne une première version. Celle-ci est présentée comme une « early preview » et peut être installée sous Linux, OS X ou Windows.

L'utilisation d'Eclipse et du plugin ADT pour le développement d'applications Android était souvent critiquée par les développeurs. Les outils mis à leur disposition n'étaient en effet pas toujours à la hauteur de leurs attentes, sans parler de la comparaison avec des outils concurrents tels que Visual Studio ou XCode.

 

Google IO 2013

 

Google a donc décidé de se baser désormais sur IntelliJ IDEA Community Edition de Jetbrains, bien connu des adeptes de Java. Ainsi est né Android Studio qui se veut bien plus complet, réactif et bien pensé. Celui-ci pèse un peu plus de 300 Mo et pourra être utilisé sous Linux, OS X ou Windows.

 

Google a déjà mis en ligne un guide de migration des projets depuis Eclipse, ainsi que des trucs et astuces. Une documentation sur le nouveau système de build basé sur Gradle est aussi disponible. Le code du projet est ouvert, et tout devrait être mis en place d'ici la semaine prochaine pour permettre à chacun de contribuer. Un dépôt Git a d'ailleurs été mis en place pour l'occasion au sein du projet AOSP. Un outil de déclaration de bug est aussi présent.

 

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Fermer

Commentaires (83)


Code ouvert en plus, bien ça, je soutien l’initiative si ça permet enfin à terme d’avoir quelque chose de comparable et aussi “accessible” que Visual Studio, sur n’importe quel OS.


Il n’y a pas eu d’annonce sur Android 4.3 ou 5.0 alors ?








abitbool a écrit :



Il n’y a pas eu d’annonce sur Android 4.3 ou 5.0 alors ?





non









syfer972 a écrit :



non







Merci <img data-src=" />



Bug : ne marche pas sous Windows 7 x64


Pour l’instant il est peut être plus complet mais il n’est pas spécialement plus facile d’accès. Je trouve l’IHM trop chargée.

Maintenant faut voir sur la durée, Eclipse est quand même bien buggué et lent et IntelliJ a une meilleure réputation…


en espérant qu’il ne faille pas une demi journée pour tout installer comme sous eclipse …








monpci a écrit :



en espérant qu’il ne faille pas une demi journée pour tout installer comme sous eclipse …







J’ai mis 15 secondes sous OSX hier (juste installation hein, j’ai pas regardé le paramétrage encore)









monpci a écrit :



en espérant qu’il ne faille pas une demi journée pour tout installer comme sous eclipse …





?

Eclipse est peut-être lourd à DL, mais l’installation est ultra rapide.

Bon après c’est une usine à gaz, mais bon …



Le 16/05/2013 à 08h 41

code source ouvert bravo <img data-src=" />


Au passage, quelqu’un connait un bon site pour apprendre à programmer sur Android ?


Etape1: dl eclipse;

Etape2: dl le sdk;

Etape3: installer le sdk;

Etape4: mettre à jour le sdk;

….

je parle de tout installer pour développer pour android depuis une machine vierge …

après ça à peut-être changer depuis que je l’ai fait …








ArchLord a écrit :



Au passage, quelqu’un connait un bon site pour apprendre à programmer sur Android ?







http://developer.android.com/training/basics/firstapp/index.html



J’ai tout appris sur le site web d’Android. C’est en anglais, mais c’est franchement bien foutu <img data-src=" />



hummm Android “studio” ? Quelle audace dans les noms de produits ! plus que Google Office et le compte y sera…








rsegismont a écrit :



Bug : ne marche pas sous Windows 7 x64







Effectivement, mais j’ai réussi à le faire marcher.



J’ai vu que dans le répertoire bin il y avait un joli “studio.bat” . En le lançant dans la console, cela nous jette une belle erreur :



ERROR: cannot start Android Studio.

No JDK found. Please validate either ANDROID_STUDIO_JDK, JDK_HOME or JAVA_HOME p

oints to valid JDK installation.

Commande ECHO désactivée.

Appuyez sur une touche pour continuer…



Alors j’ai fait, toujours dans la console un



set JDK_HOME=C:\Program Files (x86)\Java\jdk1.7.0_04



Puis j’ai relancé le studio.bat et ça marche :)









monpci a écrit :



Etape1: dl eclipse;

Etape2: dl le sdk;

Etape3: installer le sdk;

Etape4: mettre à jour le sdk;

….

je parle de tout installer pour développer pour android depuis une machine vierge …

après ça à peut-être changer depuis que je l’ai fait …







Non <img data-src=" />



Ah, une bonne nouvelle. Il faut que j’essaye ça.



Je n’ai jamais aimé leurs plugins pour Eclipse








wookie sans fil a écrit :



hummm Android “studio” ? Quelle audace dans les noms de produits ! plus que Google Office et le compte y sera…





C’est vrai qu’appeler un traitement de texte ‘Word’, ça a quand même une autre gueule niveau audace, et l’appeler Marie Henriette, c’est tellement plus pratique pour voir immédiatement de quoi il s’agit <img data-src=" />



J’y ai passé la matinée, et c’est honnêtement une douche froide.

Rien n’a changé dans le SDK, le simulateur n’a pas bougé.

Les plugins propre au dev Android (interface graphique pour créer les layouts en XML, etc) n’ont pas été changées d’un iota…



Bref, cela n’apporte rien de plus au dev Android qu’un changement d’IDE.

Je n’ai rien contre Intellij, mais je n’avais pas grand chose conte éclipse non plus…

Surtout, les deux souffrent du même manque de réactivité, et pâtissent du fait qu’ils sont développés en java.



Bref, cette migration n’apporte pas grand chose. Juste un changement d’IDE, pour un autre franchement similaire.

Je ne comprends pas les commentaires qui applaudissent ce changement : ça n’a rien d’une avancée ! C’est tout juste une pirouette et un atterrissage au même endroit…



Porter quelques librairies Java d’un programme à un autre n’est pas franchement compliqué… C’est sympa de l’avoir fait, mais ça ne mérite pas tout ce battage.

Google changera la vie des devs en portant ses outils sur Xcode, VisualStudio… Voire en créant son propre IDE. Et pas en Java.








Glubglub a écrit :



J’y ai passé la matinée, et c’est honnêtement une douche froide.

Rien n’a changé dans le SDK, le simulateur n’a pas bougé.

Les plugins propre au dev Android (interface graphique pour créer les layouts en XML,….érite pas tout ce battage.

Google changera la vie des devs en portant ses outils sur Xcode, VisualStudio… Voire en créant son propre IDE. Et pas en Java.







De la poudre aux yeux, juste pour occuper la place… il faudra attendre &gt;1 ans pour avoir quelque chose de correcte.





Surtout, les deux souffrent du même manque de réactivité, et pâtissent du fait qu’ils sont développés en java.



Ce troll. <img data-src=" />


Microsoft devrait leur envoyer un lettre de demande de retrait car ils utilisent des API Windows pour faire tourner leur SDK.








Glubglub a écrit :



J’y ai passé la matinée, et c’est honnêtement une douche froide.

Rien n’a changé dans le SDK, le simulateur n’a pas bougé.

Les plugins propre au dev Android (interface graphique pour créer les layouts en XML, etc) n’ont pas été changées d’un iota…



Bref, cela n’apporte rien de plus au dev Android qu’un changement d’IDE.

Je n’ai rien contre Intellij, mais je n’avais pas grand chose conte éclipse non plus…

Surtout, les deux souffrent du même manque de réactivité, et pâtissent du fait qu’ils sont développés en java.



Bref, cette migration n’apporte pas grand chose. Juste un changement d’IDE, pour un autre franchement similaire.

Je ne comprends pas les commentaires qui applaudissent ce changement : ça n’a rien d’une avancée ! C’est tout juste une pirouette et un atterrissage au même endroit…



Porter quelques librairies Java d’un programme à un autre n’est pas franchement compliqué… C’est sympa de l’avoir fait, mais ça ne mérite pas tout ce battage.

Google changera la vie des devs en portant ses outils sur Xcode, VisualStudio… Voire en créant son propre IDE. Et pas en Java.







Est-ce que l’installation est plus simple qu’Eclipse et ses plugins ?

Si oui, c’est toujours ça de gagné.

Je développe occasionnellement pour Android et je ne garde pas forcément Eclipse sur ma machine en permanence. A chaque fois je rêve d’un setup qui me donnerait un environnement de travail opérationnel (ce qui n’est pas le cas avec Eclipse, cela à été décrit un peu plus haut).










lordzeon a écrit :



Est-ce que l’installation est plus simple qu’Eclipse et ses plugins ?

Si oui, c’est toujours ça de gagné.







Je viens de l’installer. Téléchargement, lancement du bon fichier, et voila. Il te propose de créer un nouveau projet.

Par contre ça fait 30 minutes que je mets à jour les plugins eclipse pour pouvoir exporter mes projets existants <img data-src=" />



Ah ben c’est pas trop tôt! ça c’est une bonne nouvelle! Parce qu’avant c’était un peu la crois et la bannière! J’espère qu’ils amélioreront surtout la conception de fenêtre graphique! Ce point là c’est un peu galère, surtout pour gérer les résolutions etc!



EDIT: je viens de lire le commentaire plus haut, visiblement ça ne change rien. :/








HarmattanBlow a écrit :



Ce troll. <img data-src=" />





Je ne voit pas en quoi c’est trollesque : exécuter un programme dans une machine virtuelle est forcément plus lent qu’un programme compilé en assembleur.

10 fois plus lent, selont quelques profs de mon ancienne fac.







lordzeon a écrit :



Est-ce que l’installation est plus simple qu’Eclipse et ses plugins ?

Si oui, c’est toujours ça de gagné.

Je développe occasionnellement pour Android et je ne garde pas forcément Eclipse sur ma machine en permanence. A chaque fois je rêve d’un setup qui me donnerait un environnement de travail opérationnel (ce qui n’est pas le cas avec Eclipse, cela à été décrit un peu plus haut).









C’est exactement pareil ! Ce sont les mêmes plugins.

L’installation est simple si l’on prends le Bundle avec IDE+Android préconfiguré…



Mais le même bundle existait avec Éclipse depuis plus d’un an.

Rien n’a vraiment changé !



merci trifus.



Perso je viens d’installer android studio ras à l’installation,mais à l’exécution il me dit jdk not found même avec la variable JDK_HOME défini <img data-src=" />



Edit: ah si c’est bon après une fermeture de session

<img data-src=" />








Glubglub a écrit :



J’y ai passé la matinée, et c’est honnêtement une douche froide.





Y’en a certain qui ont pas compris le sens de la première phrase de l’article: “mettre en ligne une première version. Celle-ci est présentée comme une early preview”



<img data-src=" />







Glubglub a écrit :



Je ne voit pas en quoi c’est trollesque : exécuter un programme dans une machine virtuelle est forcément plus lent qu’un programme compilé en assembleur.

10 fois plus lent, selont quelques profs de mon ancienne fac.





C’est encore au delà du troll: il est convaincu de ce qu’il raconte en plus <img data-src=" />



Ca marche par sur windows 7 64 :(








Glubglub a écrit :



Je ne voit pas en quoi c’est trollesque : exécuter un programme dans une machine virtuelle est forcément plus lent qu’un programme compilé en assembleur.

10 fois plus lent, selont quelques profs de mon ancienne fac.





Alors d’abord le dix fois plus lent à de quoi me faire rire. Machine virtuelle ou pas le code se retrouve in fine compilé (simplement moins optimisé qu’avec une compilation ordinaire) et ce n’est pas la surcouche pour ouvrir les fichiers ou afficher l’UI qui fera ramer le bousin vu le faible poids de ces appels. En pratique je vois des surcoûts globaux de 30% du fait du manque d’optimisation de la compilation JIT. Même si dans le cas de Java le surcroût est sans doute plus élevé. Quant aux coûts inhérents aux langages managés (comptage de références, etc), de nos jours les mêmes problèmes se posent avec un code C++ s’appuyant sur Boost et compagnie.



Ensuite avec les CPU qu’on a aujourd’hui il y a largement de quoi faire tout ce que fait un IDE dans le plus lent des langages qui soit et sans forcer. Si ça rame, c’est que quelqu’un a merdé. Il n’y a guère que pour une ou deux étapes longues par essence (compilation de gros projet, etc) qu’une différence se fera nécessairement sentir (et encore : les réductions de coût engendrées peuvent servir à mieux paralléliser).



Crois-moi, j’ai conçu des tonnes d’applis dans des langages managés (même si dotnet n’a pas à proprement parler une machine virtuelle), dont certaines bien exigeantes, et je n’ai eu aucun pb de performances au final alors que je n’hésite pas à y aller à la truelle. Je me contente d’éviter les erreurs stupides et les machins sur-architecturés. Et ce sont ces derniers qui doivent plutôt être en cause.



L’algo fait la vitesse, pas le langage. Dit comme ça c’est un peu simpliste mais c’est essentiellement vrai.









bornbanane a écrit :



Effectivement, mais j’ai réussi à le faire marcher.



J’ai vu que dans le répertoire bin il y avait un joli “studio.bat” . En le lançant dans la console, cela nous jette une belle erreur :



Puis j’ai relancé le studio.bat et ça marche :)







Pas encore essayé mais merci pour l’info !



C’est vrai que les outils de développement Android ne marchent qu’avec le JDK 32 bits ; j’avais eu un problème similaire avec l’environnement Eclipse+ADT ; j’avais simplement désinstallé le JDK 64 bits et réinstallé le 32 bits, et ça s’est mis à marcher.









brazomyna a écrit :



C’est encore au delà du troll: il est convaincu de ce qu’il raconte en plus <img data-src=" />







???

La je ne comprends pas ta remarque.



Java a fait d’énorme progrès depuis ses débuts et le rapport de 1 à 10 est sans doute exagéré.

Mais il est évident que la VM ne peut pas être aussi rapide qu’un code natif (à qualité égale).

Il a donc techniquement raison.










bingo.crepuscule a écrit :



je soutien l’initiative si ça permet enfin à terme d’avoir quelque chose de comparable et aussi “accessible” que Visual Studio, sur n’importe quel OS.







C’est une blague, hein ?

Tu codes pas vraiment, juste de temps en temps ?

Nan parce que les raccourcis de Visual, ça va deux minutes, hein…




  • Bonjour, je voudrais commenter trois lignes s’il vous plait

  • Pas de problème, mon bon monsieur, faites donc un CTRL+ALT+E puis C. Notez que pour décommenter, comme on est des p’tits marrants, c’est pas le même, c’est CTRL+ALT+E puis U. Mais c’est très utile cette différence de raccourci, comme ça vous pouvez commenter des lignes déjà commenté \o/

  • euh…



    Eclipse a de nombreux défauts, les plugins Android sont vraiment pénibles à configurer et pas pratique à utiliser, c’est un fait. Mais de là à vouloir du Visual -_-’









amnesyc a écrit :



Ca marche par sur windows 7 64 :(







touche windows+r -&gt; cmd



cd DOSSIER_BIN_ANDROID_STUDIO

exemple

cd C:\Users\monom\AppData\Local\Android\android-studio\bin



ensuite



set JDK_HOME=DOSSIER_JDK

exemple

set JDK_HOME=C:\Program Files (x86)\Java\jdk1.7.0_21



et enfin



studio.bat





par contre je sais pas si ca fonctionne avec une version x64 du jdk









lordzeon a écrit :



est évident que la VM ne peut pas être aussi rapide qu’un code natif (à qualité égale).

Il a donc techniquement raison.





La VM peut faire des optimisations du fait de méta information disponible en Java que n’aura pas un compilo en C/C++ par exemple. Et une fois compilé le code n’en sera que meilleur (d’autant plus que la compilation se fait en runtime, donc pour une archi bien déterminée, plus qu’au compil’ time où on va plutôt utiliser des archis plus générique: x86, x64, …).



Surtout: le langage influence la productivité dans l’écriture de code, et un langage plus ‘productif’ permettra, à effort égal de passer plus de temps à mieux penser/implémenter ses algos. Au passage, un langage comme Java permet également une meilleure gestion d’erreurs et donc d’améliorer la stabilité globale du code (par exemple qu’un segfault).



Et c’est un amoureux du C++ qui te parle.



Je ne vais pas m’étendre sur le truc qui n’est qu’un troll des années 8090.

Il y a des millions de pages web sur le sujet, qui montrent au moins autant que 1) Java s’en plutôt très bien dans la plupart des situations à quelques % près de langages compilés, mieux dans quelques rares cas et beaucoup moins bien dans d’autres cas spécifiques et 2) vouloir mettre un chiffre global sur un comparatif de perf est juste idiot tellement d’un algo à l’autre les perfs relatives peuvent varier.









HarmattanBlow a écrit :



Alors d’abord le dix fois plus lent à de quoi me faire rire. Machine virtuelle ou pas le code se retrouve in fine compilé (simplement moins optimisé qu’avec une compilation ordinaire) et ce n’est pas la surcouche pour ouvrir les fichiers ou afficher l’UI qui fera ramer le bousin vu le faible poids de ces appels. En pratique je vois des surcoûts globaux de 30% du fait du manque d’optimisation de la compilation JIT. Même si dans le cas de Java le surcroût est sans doute plus élevé.







Compilé oui … mais pour la VM.

Le code n’est pas natif pour le processeur.



Si le code était natif, ça ne tournerait pas sur différents processeurs.







HarmattanBlow a écrit :



Ensuite avec les CPU qu’on a aujourd’hui il y a largement de quoi faire tout ce que fait un IDE dans le plus lent des langages qui soit et sans forcer. Si ça rame, c’est que quelqu’un a merdé. Il n’y a guère que pour une ou deux étapes longues par essence (compilation de gros projet, etc) qu’une différence se fera nécessairement sentir (et encore : les réductions de coût engendrées peuvent servir à mieux paralléliser).







C’est vrai … mais il faut avouer que les IDE en java ne sont pas vraiment rapide.

Est-ce lié à la technologie, ou est-ce lié au code … je ne sais pas mais c’est une évidence.












HarmattanBlow a écrit :



Crois-moi, j’ai conçu des tonnes d’applis dans des langages managés (même si dotnet n’a pas à proprement parler une machine virtuelle), dont certaines bien exigeantes, et je n’ai eu aucun pb de performances au final alors que je n’hésite pas à y aller à la truelle. Je me contente d’éviter les erreurs stupides et les machins sur-architecturés. Et ce sont ces derniers qui doivent plutôt être en cause.







Très vrai, et pourtant j’ai parfois dû “passer outre” le garbage collector. J’avais une application qui allouait beaucoup de petits objets à la durée de vie faible. Hé bien, en maintenant manuellement un petit pool d’objets “libérés” j’ai multiplié les performances par 3. Bon, c’est vrai que j’avais pas beaucoup de mémoire (app Java ME sous Wndows Mobile 6) et le GC avait fort à faire…









lordzeon a écrit :



Compilé oui … mais pour la VM.

Le code n’est pas natif pour le processeur.





Faux: relis quelques articles sur le JIT. On parle de compilation à la volée qui compile le bytecode pendant l’exécution.





C’est vrai … mais il faut avouer que les IDE en java ne sont pas vraiment rapide.

Est-ce lié à la technologie, ou est-ce lié au code … je ne sais pas mais c’est une évidence.



C’est sûrement beaucoup lié à l’architecture: un IDE ultra généraliste, générique et extensible comme Eclipse ne peut pas se comporter de façon aussi optimisée qu’un IDE ultra spécialisé dans une techno précise.









brazomyna a écrit :



La VM peut faire des optimisations du fait de méta information disponible en Java que n’aura pas un compilo en C/C++ par exemple. Et une fois compilé le code n’en sera que meilleur (d’autant plus que la compilation se fait en runtime, donc pour une archi bien déterminée, plus qu’au compil’ time où on va plutôt utiliser des archis plus générique: x86, x64, …).



Surtout: le langage influence la productivité dans l’écriture de code, et un langage plus ‘productif’ permettra, à effort égal de passer plus de temps à mieux penser/implémenter ses algos. Au passage, un langage comme Java permet également une meilleure gestion d’erreurs et donc d’améliorer la stabilité globale du code (par exemple qu’un segfault).



Et c’est un amoureux du C++ qui te parle.



Je ne vais pas m’étendre sur le truc qui n’est qu’un troll des années 8090.

Il y a des millions de pages web sur le sujet, qui montrent au moins autant que 1) Java s’en plutôt très bien dans la plupart des situations à quelques % près de langages compilés, mieux dans quelques rares cas et beaucoup moins bien dans d’autres cas spécifiques et 2) vouloir mettre un chiffre global sur un comparatif de perf est juste idiot tellement d’un algo à l’autre les perfs relatives peuvent varier.









Attention, je ne dis pas que Java est une mauvaise technologie.

Je suis complètement d’accord sur les avantages de Java <img data-src=" />

Je dis juste qu’un code très bien pensé (et donc ayant peu d’optimisations possibles) ne peut que tourner plus vite de manière native.



En tant qu’utilisateur occasionnel de NetBeans et d’Eclipse, j’ai toujours trouvé ces programmes terriblement lourds. J’ignore si cela est lié à la technologie elle même, à la qualité du code, ou tout simplement à des traitements de fou … mais même avec une bête de course : ça rame.












brazomyna a écrit :



Faux: relis quelques articles sur le JIT. On parle de compilation à la volée qui compile le bytecode pendant l’exécution.







[Mode je cherche la petit bête ON]

Ok mais on a donc une étape supplémentaire

[Mode je cherche la petit bête OFF]



C’est dingue le nombre de personnes sous Windows qui savent même pas configurer une variable d’environnement! Des mec qui d/l un IDE en plus…











lordzeon a écrit :



Compilé oui … mais pour la VM.

Le code n’est pas natif pour le processeur.





Comme l’a précisé Brazonyma, la VM compile bel et bien le bytecode en code natif, à la volée (JIT = just in time).





C’est vrai … mais il faut avouer que les IDE en java ne sont pas vraiment rapide.



Et à côté de ça VS est écrit majoritairement en dotnet de nos jours (pas entièrement pour des raisons historiques et de compatibilité) et il est très véloce.







WilliamSauron a écrit :



Très vrai, et pourtant j’ai parfois dû “passer outre” le garbage collector. J’avais une application qui allouait beaucoup de petits objets à la durée de vie faible. Hé bien, en maintenant manuellement un petit pool d’objets “libérés” j’ai multiplié les performances par 3.





J’ai aussi eu une fois à faire ça pour éviter de faire bosser le GC et maintenir une fluidité impeccable. Mais la technique existe aussi dans le monde non-managé, pour des raisons un peu différentes. ;)







brazomyna a écrit :



C’est sûrement beaucoup lié à l’architecture: un IDE ultra généraliste, générique et extensible comme Eclipse ne peut pas se comporter de façon aussi optimisée qu’un IDE ultra spécialisé dans une techno précise.





VS n’est pas plus restreint qu’Eclipse, tu peux y ajouter le support de tous les langages que tu veux via des plugins, avec prise en charge de la coloration syntyaxique, du déboguage de ta propre gestion de projets, etc. C’est très extensible.







TheDidouille a écrit :



C’est dingue le nombre de personnes sous Windows qui savent même pas configurer une variable d’environnement! Des mec qui d/l un IDE en plus…





Parce que c’est devenu rare. Les applis de nos jours sous Windows utilisent plutôt des clés de registre. Je dois toucher aux variables d’environnement une fois par an et à chaque fois j’hésite un peu pour retrouver où ils ont foutu l’UI pour ça.









HarmattanBlow a écrit :



Comme l’a précisé Brazonyma, la VM compile bel et bien le bytecode en code natif, à la volée (JIT = just in time).





Et à côté de ça VS est écrit majoritairement en dotnet de nos jours (pas entièrement pour des raisons historiques et de compatibilité) et il est très véloce.





J’ai aussi eu une fois à faire ça pour éviter de faire bosser le GC et maintenir une fluidité impeccable. Mais la technique existe aussi dans le monde non-managé, pour des raisons un peu différentes. ;)





VS n’est pas plus restreint qu’Eclipse, tu peux y ajouter le support de tous les langages que tu veux via des plugins, avec prise en charge de la coloration syntyaxique, du déboguage de ta propre gestion de projets, etc. C’est très extensible.







tu connais vraiment pas eclipse, eclipse n’est pas qu’un environnement de développement, c’est aussi une plateforme pour faire des appli développer avec des équipes qui se connaissent pas, qui peuvent utiliser des versions différentes de lib, d’application qui peuvent s’étendre, portable, sans maintenance. Rien à voir avec ce que tu peux faire avec un IDE “natif”.









TheDidouille a écrit :



tu connais vraiment pas eclipse, eclipse n’est pas qu’un environnement de développement, c’est aussi une plateforme pour faire des appli développer avec des équipes qui se connaissent pas, qui peuvent utiliser des versions différentes de lib, d’application qui peuvent s’étendre, portable, sans maintenance. Rien à voir avec ce que tu peux faire avec un IDE “natif”.







Oui c’est vrai qu’on peut se servir d’un Eclipse pour héberger une application qui n’a rien à voir avec le développement, comme une gestion de chaîne robotisée de production. Stricto sensu, il existe aussi une version de Visual Studio (Visual Studio Shell si ma mémoire est bonne) qui ne contient en natif de support pour aucun langage de programmation et qui peut être utilisée comme hébergement d’une application quelconque via des plug-ins spécialisés.



Ca reste un usage de niche… (ouaf ouaf)









HarmattanBlow a écrit :



VS n’est pas plus restreint qu’Eclipse, tu peux y ajouter le support de tous les langages que tu veux via des plugins, avec prise en charge de la coloration syntyaxique, du déboguage de ta propre gestion de projets, etc. C’est très extensible.





Pas sûr que tu puisses développer l’équivalent d’un Lotus Notes au dessus de Visual Studio. Lotus Notes est pourtant basé sur Eclipse (version 8, je ne sais pas pour la 9).



Ce n’est également pas pour rien qu’on parle souvent de ‘distribution eclispe’, de la même façon qu’on parle de ‘distribution linux’ (dans le sens où le kernel linux n’est qu’une brique logicielle parmi d’autres ; ça correspond pas mal aux technos Eclipse).









TheDidouille a écrit :



tu connais vraiment pas eclipse





Connais-tu vraiment Visual Studio ?





c’est aussi une plateforme pour faire des appli développer avec des équipes qui se connaissent pas



Ils ont intégré un chat ? Plus sérieusement, à quelle fonctionnalité songes-tu ?





, qui peuvent utiliser des versions différentes de lib, d’application qui peuvent s’étendre, portable, sans maintenance.



Un IDE qui produit des applis sans maintenance et résoud tout seul le DLL hell ? A ce stade ce n’est plus un IDE, c’est Jésus.









brazomyna a écrit :



Ce n’est également pas pour rien qu’on parle souvent de ‘distribution eclispe’, de la même façon qu’on parle de ‘distribution linux’ (dans le sens où le kernel linux n’est qu’une brique logicielle parmi d’autres ; ça correspond pas mal aux technos Eclipse).





PS: un lien assez parlant: List of Eclipse-based software.

Genre dedans, tu trouves RSSOwl, un RSS reader ; uDig, un soft pour faire des carte géographiques, Lotus Notes dont je parlais avant, etc…












HarmattanBlow a écrit :



Parce que c’est devenu rare. Les applis de nos jours sous Windows utilisent plutôt des clés de registre. Je dois toucher aux variables d’environnement une fois par an et à chaque fois j’hésite un peu pour retrouver où ils ont foutu l’UI pour ça.







C’est même surtout parce que les variables d’environnement sont une solution globale à un problème local. Si j’ai trois JDK différents sur ma machine, il n’y a aucune raison d’utiliser une variable d’environnement globale pour dire quelle est la “bonne”. Chaque application a sa propre notion de quelle est la bonne version du JDK pour un problème donné, et donc chaque application doit venir avec sa technique pour mettre les variables d’environnement à la bonne valeur dans son processus avant de lancer l’appli proprement dite.









HarmattanBlow a écrit :



Un IDE qui produit des applis sans maintenance et résoud tout seul le DLL hell ? A ce stade ce n’est plus un IDE, c’est Jésus.





Improbable ; on a des preuves photographiques qui contredisent cette théorie ubuesque.










brazomyna a écrit :



PS: un lien assez parlant: List of Eclipse-based software.

Genre dedans, tu trouves RSSOwl, un RSS reader ; uDig, un soft pour faire des carte géographiques, Lotus Notes dont je parlais avant, etc…





Sauf qu’en fait ce n’est pas basé sur Eclipse mais sur un framework (RCP) développé pour Eclipse et qui est en somme un framework UI avec des mécanismes d’extensibilité. De telles choses existent aussi côté dotnet, même si la plupart ne sont pas utilisées par VS.







brazomyna a écrit :



Improbable ; on a des preuves photographiques qui contredisent cette théorie ubuesque.





<img data-src=" />







WilliamSauron a écrit :



C’est même surtout parce que les variables d’environnement sont une solution globale à un problème local.





Je ne suis pas d’accord. Le problème est : où est tel composant ? Quel que soit le mécanisme pour exposer cette info à toutes les applications, tu peux ou non distinguer les différents versions disponibles (différentes variables d’environnement par ex).



Testé sur deux plateformes, Linux et Mac OS X mais pas encore approuvé. C’est toujours autant la misère pour lancer une simulation. Le seul intérêt est effectivement l’installation simplifiée. Mais est ce qu’un IDE s’adresse à des gens qui cherchent la simplicité d’installation ? À suivre parce qu’Android manque cruellement d’un bon IDE si on le compare à ses concurrents.








HarmattanBlow a écrit :



Sauf qu’en fait ce n’est pas basé sur Eclipse mais sur un framework (RCP) développé pour Eclipse





Certes, mais ça reste une couche d’Eclipse qui a été faite volontairement générique pour pouvoir être réutilisée un peu partout et qui est effectivement utilisée par l’IDE lui-même.







poupoul2 a écrit :



À suivre





Voilà, c’est le mot: c’est une early preview ; il est normal que pour le moment ils reprennent l’existant tel quel avant de lancer les gros chantiers pour modifier ce qui doit l’être.



Un peu de patience, les choses vont s’affiner avec le temps.



Mouahahahahah sacré enclume pour enfoncer une vis … Surtout après avoir utilisé Qt SDK et Qt Creator pour porter une appli sur SailfishOS …



Eclipse … c’est le truc qui a fait que je n’ai jamais utilisé le sdk android ou bb10 …








lordzeon a écrit :



Est-ce que l’installation est plus simple qu’Eclipse et ses plugins ?

Si oui, c’est toujours ça de gagné.

Je développe occasionnellement pour Android et je ne garde pas forcément Eclipse sur ma machine en permanence. A chaque fois je rêve d’un setup qui me donnerait un environnement de travail opérationnel (ce qui n’est pas le cas avec Eclipse, cela à été décrit un peu plus haut).







C’est déjà le cas. Depuis quelques mois Google propose une archive avec tout déjà dedans et déjà configuré :)http://developer.android.com/sdk/index.html









HarmattanBlow a écrit :



Je ne suis pas d’accord. Le problème est : où est tel composant ? Quel que soit le mécanisme pour exposer cette info à toutes les applications, tu peux ou non distinguer les différents versions disponibles (différentes variables d’environnement par ex).







Oui bien sûr les variables d’environnement sont un moyen comme un autre de donner des informations sur l’environnement. Elles ont cependant le défaut d’être plutôt touffues, d’être recopiées dans chaque processus (et donc WinWord.exe se ramasse une copie d’une variable d’environnement qui lui dit où est le NDK d’Android et une autre est le repository GIT - ça lui fait une belle jambe…), et d’être… variables (un peu comme ces variables “fluides” que LISP a eu fort longtemps et dont ils ont fini par se débarrasser : un processus A invoque un processus B qui modifie une variable d’environnement avant d’invoquer un processus C, et vlan C ne marche plus car il dépendait de la valeur par défaut…



J’ai aussi un peu de mal avec le fait qu’une fois que le processus est lancé il a sa propre vision des variables d’environnement, et que si je les corrige à un endroit, elles ne sont pas exploitables directement dans une autre tâche… C’est pas intuitif.



Certes il y a des cas où c’est utile, mais la plupart du temps c’est un casse-tête et il faut bien faire attention à ne pas péter l’environnement. Qui n’a pas eu des frayeurs dans un batch qui soudain cesse de marcher car on a changé le répertoire par défaut sous la table, et qu’il faut tout patcher à grands coups de pushd/popd ?



Je trouve plus propre que chaque application aille chercher ses valeurs qui vont bien à un endroit où personne d’autre ne peut les foutre en l’air, et qu’invoquer une application avec des valeurs différentes soit une démarche expresse (p. ex. en mettant des paramètres sur la ligne de commande : javac –use-this-JDK=abc).
















ArchLord a écrit :



touche windows+r -&gt; cmd



ensuite



et enfin





par contre je sais pas si ca fonctionne avec une version x64 du jdk





Merci je vais essayer ca ce soir!!!









HarmattanBlow a écrit :



Connais-tu vraiment Visual Studio ?





Ils ont intégré un chat ? Plus sérieusement, à quelle fonctionnalité songes-tu ?





Un IDE qui produit des applis sans maintenance et résoud tout seul le DLL hell ? A ce stade ce n’est plus un IDE, c’est Jésus.







Tous les ERP, ESB, ETL, tous les GROS outils modernes sont développés avec Eclipse, tu n’as pas de “DLL Hell” (c’est ton prof de second techno qui te fait resortir ce terme?), tu utilises des composants indépendants, qui peuvent loader des version différentes d’un même jar avec chacun son espace mémoire (http://fr.wikipedia.org/wiki/OSGi ).



C’est pas un IDE de tapette pour faire du directX.









brazomyna a écrit :



Je ne vais pas m’étendre sur le truc qui n’est qu’un troll des années 8090.

Il y a des millions de pages web sur le sujet, qui montrent au moins autant que 1) Java s’en plutôt très bien dans la plupart des situations à quelques % près de langages compilés, mieux dans quelques rares cas et beaucoup moins bien dans d’autres cas spécifiques et 2) vouloir mettre un chiffre global sur un comparatif de perf est juste idiot tellement d’un algo à l’autre les perfs relatives peuvent varier.







OK, soit.

Je vais donc préciser, pour ne pas me faire accuser de troll :

Dans mon métier, inge en IA, j’implémente des souvent des algos. Même dans les plus simple (namedrioping des plus courants : Floyd-Warshall, A*), Java met en moyenne 10 fois plus de temps.



Pour un appel à la BDD, ou le lancement d’une fenêtre, je ne dis pas.

Java fait aussi bien que n’importe quel autre language.



Mais pour un algorithme d’IA quelquonque, je n’ai jamais vu Java faire des merveilles.

Je n’ai jamais mis les mains dans un IDE, mais je pense que ce genre d’algos dans les aides apportées au développement.



La propreté du code esst importante, je ne dis la le contraire, mais c’est aussi possible tailleur qu’en Java. Ce n’est pas un argument valable selon moi.



Encore une fois, je ne trolle pas Java : c’est mon language principal, et mon métier.

Mais je ne ferme pas les yeux sur ses nombreux défauts par pur fanatisme :

Je suis souvent confronté à ses limites, que ce soit en termes de conception ou de performances.









TheDidouille a écrit :



C’est pas un IDE de tapette pour faire du directX.





Justement c’est là le problème d’Eclips et le tien en passant <img data-src=" /> <img data-src=" />



Nous voulons faire une application Android





  • De façon plus ou moins WISIWIG qui fonctionne plus que mieux

  • que ce soit très réactif à la compilation et à l’exécution

  • qu’il ait des outils de test et de performance







    XCode répond à ce besoin d’application native iPhone/ iPad

    Visual répond aussi pour les Winforms



    Eclipse c’est de la bouse pour cela.

    Un truc qui m’a tué sur place: les logs de ton application Android siont dans les logs de “ton téléphone” et le filtre ne remonte pas les warning, les execptions et les erreurs <img data-src=" />



    Déjà que Google ne sait pas faire un SDK [pourquoi avoir mis autant de XML obligatoire et qui est buggué?]

    <img data-src=" /> <img data-src=" />



L’executable d’installation est detecté comme non sûr par Symantec, qui me deconseille de l’installer… <img data-src=" />








foetus a écrit :



Justement c’est là le problème d’Eclips et le tien en passant <img data-src=" /> <img data-src=" />



Nous voulons faire une application Android





  • De façon plus ou moins WISIWIG qui fonctionne plus que mieux

  • que ce soit très réactif à la compilation et à l’exécution

  • qu’il ait des outils de test et de performance







    XCode répond à ce besoin d’application native iPhone/ iPad

    Visual répond aussi pour les Winforms



    Eclipse c’est de la bouse pour cela.

    Un truc qui m’a tué sur place: les logs de ton application Android siont dans les logs de “ton téléphone” et le filtre ne remonte pas les warning, les execptions et les erreurs <img data-src=" />



    Déjà que Google ne sait pas faire un SDK [pourquoi avoir mis autant de XML obligatoire et qui est buggué?]

    <img data-src=" /> <img data-src=" />





    Mais gros +1 quand même! Quand on passe du dev QT, à du dev android, on pleure bien souvent! <img data-src=" />



    Et créer un truc graphique à l’aide de l’assistant c’est bien souvent un exploit. Donc parfois on fait la fenêtre complet en ui, parfois on rajoute à la main les composant pour que ça prenne la bonne place quelque soit la résolution. Supra pratique.



    On passera sur les cassures en fonction des versions, des trucs qui ne fonctionnent plus parce que google l’a décidé ou a déplacé la fonction… Super pratique pour maintenir quelque chose.





    Concrètement il manque un moyen simple de faire son design et de s’en servir.









Glubglub a écrit :



Dans mon métier, inge en IA, j’implémente des souvent des algos. Même dans les plus simple (namedrioping des plus courants : Floyd-Warshall, A*), Java met en moyenne 10 fois plus de temps.





Tu fais du très gros itératif sur des données en quantité avec une unité de petite taille en mémoire ; c’est un “edge case”.



Effectivement, les optimisations possible dans ce cas précis, notamment en collant au plus près du fonctionnement réel du CPU (genre comment j’organise mes arrays de données en mémoire pour qu’elles arrivent plus vite en cache CPU), sont pertinentes si effectivement t’es sur un facteur 10.



Là, nous on parlais d’un IDE.





Pour un appel à la BDD, ou le lancement d’une fenêtre, je ne dis pas.

Java fait aussi bien que n’importe quel autre language.



Pour faire un serveur qui gère 10 000 messages réseau seconde, quelques milliers de connectés et seulement 2% d’utilisation d’un CPU moyen de gamme, c’est possible aussi, j’en ai un à la maison.



Ne tombons pas dans la caricature du “Java c’est juste bon à faire de l’IHM”.







La propreté du code est importante, je ne dis la le contraire, mais c’est aussi possible tailleur qu’en Java. Ce n’est pas un argument valable selon moi.



Je ne parle pas de propreté, je parle d’efficience et de rapidité de codage. Et dans un monde fini, la rapidité de codage dégage autant de temps libre pour faire autre chose, typiquement optimiser les algos qu’on a écrit, renforcer la sécurité, la robustesse du code, etc…



Et ce d’autant plus que le temps d’exécution n’est souvent qu’un paramètre qui dépend d’autres facteurs. Si sur un projet de 200 homme.jour pour une moulinette interne à une entreprise:




  • je code 10% plus vite en Java qu’en C++.

  • je paie un développeur 350€ / jour.



    =&gt; j’ai économisé 7k€

    =&gt; 7k€, je peux les réinvestir dans un serveur 50% plus puissant

    =&gt; si Java est moins de 50% plus lent que l’équivalent en C++, je suis gagnant (et j’ai gagné un serveur supplémentaire qui pourra resservir à autre chose).



    Tu peux moduler les autres paramètres du projet à l’infini avec par exemple le prix moyen d’un développeur en Java vs. celui d’un développeur à compétences égales en C++, en du bassin d’emploi (genre exemple concret, trouve du développeur C++ en masse au Luxembourg au même prix que du dév. Java ; même question avec un développeur Cobol).





    Encore une fois, je ne trolle pas Java : c’est mon language principal, et mon métier.



    Justement, la question intéressante, pour quelle raison Java a été choisi là où tu bosses, et pas autre chose ?





    Mais je ne ferme pas les yeux sur ses nombreux défauts par pur fanatisme



    Moi non plus, et je navigue pour ça sans problème entre le C++/Java/PHP/Javascript pour différents besoins en fonction de ce qui est le plus approprié tout en respectant les contraintes de mes projets.





    Je suis souvent confronté à ses limites, que ce soit en termes de conception ou de performances.



    Dans la niche que représente ton type de développement, je peux parfaitement le concevoir.



Sinon comparer dot net à java ce n’est pas totalement comparable. Surtout sous windows, le comparatif est faussé.



Dot net est intégré jusqu’à la moelle dans windows par microsoft. Donc tout est fait pour que ça s’exécute rapidement là ou java s’installe en plus sans module forcément pré-chargé ou en plus etc.



j’avoue quand même, qu’en temps de lancement d’application java, ou d’affichage de fenêtre/module, je trouve ça toujours lent. (temps perçu par l’utilisateur)



En tant qu’utilisateur et dev, j’ai toujours moi aussi ce ressenti de réactivité en moins comparé à une application QT C++ par exemple. Sur les mêmes algos etc.





Après pour le débat temps de calcul, le fait est qu’une application en C++ compilée spécifiquement pour une archi peut-être plus rapide ça c’est un fait. Maintenant sorti de ce cas précis (qui est pourtant assez général dans le cadre de la recherche et des calculs scientifiques ), le temps réel de calcul doit être proche si la compilation est plus générale.



La seule grosse différence pour moi ce site au niveau du chargement des éléments graphiques (affichage d’une fênetre), de la précompilation du jit qui ralenti le lancement etc. Le ressenti reste toujours mauvais je trouve pour l’utilisateur.



Et on a tous le souvenir d’application codé en java qui se trainent…

Lotus note (c’est affreux franchement), openOffice etc. Il y a quand même bien une raison à ça au final.








davidbidji a écrit :



C’est une blague, hein ?

Tu codes pas vraiment, juste de temps en temps ?

Nan parce que les raccourcis de Visual, ça va deux minutes, hein…




  • Bonjour, je voudrais commenter trois lignes s’il vous plait

  • Pas de problème, mon bon monsieur, faites donc un CTRL+ALT+E puis C. Notez que pour décommenter, comme on est des p’tits marrants, c’est pas le même, c’est CTRL+ALT+E puis U. Mais c’est très utile cette différence de raccourci, comme ça vous pouvez commenter des lignes déjà commenté \o/

  • euh…





    Ctrl+K+C et Ctrl+K+U pour commenter et dé-commenter chez moi…

    Et oui c’est utile d’avoir 2 raccourcis.

    Si je commente un bloc qui contient code + commentaire, mon commentaire sera doublement en commentaire et le code commenté une fois. Si plus tard je le dé-commente, je me retrouve de nouveau avec du code + du commentaire et pas mon commentaire transformé en code.



    Lire ton message au dessus, ça donne envie de te retourner la question…









brazomyna a écrit :



Certes, mais ça reste une couche d’Eclipse qui a été faite volontairement générique pour pouvoir être réutilisée un peu partout et qui est effectivement utilisée par l’IDE lui-même.





Oui mais ça ne dit rien de l’extensibilité et de la réutilisabilité de l’IDE lui-même.







TheDidouille a écrit :



Tous les ERP, ESB, ETL, tous les GROS outils modernes sont développés avec Eclipse





Et toutes les autres applis pour Windows sont développées sous VS.





tu n’as pas de “DLL Hell”



Tu n’en n’as pas pour les applis java, parce que java a été conçu comme dotnet avec la perspective d’éviter ce pb, ce qui n’a rien à voir avec Eclipse en soi.





c’est ton prof de second techno qui te fait resortir ce terme?





C’est pas un IDE de tapette pour faire du directX.



Pathétique.









brazomyna a écrit :



Ne tombons pas dans la caricature du “Java c’est juste bon à faire de l’IHM”.





Vu les biblios disponibles ous Java, ne faudrait-il pas plutôt dire : Java est bon à tout sauf de l’IHM ?

<img data-src=" />







foetus a écrit :



Visual répond aussi pour les Winforms





Tu as malheureusement raison de préciser “pour Winform”. :(



@brazomyna : Merci de reconnaître que je peux critiquer Java sans être un troll.

Pour répondre à ta question, j’utilise java parce que le projet de ma boite est sur Android. Et on a parfois dû porter des morceaux sous le NDK d’Android (du C, grosso modo), justement à cause des limites de Java.



Java n’est pas à la ramasse partout, mais il l’est pour les algorithmes décisionnels.

Et je suis sûr qu,‘il y en a pas mal besoin dans un IDE, pour l’aide automatisée au dev.



L’absence d’héritage multiple est assez gênant, et peut compliquer la modé sur un lourd projet. et je pense aussi que c’est préjudiciable à un IDE.



Au final, j’ai quelques raisons de penser que ce n’est pas le meilleur choix pour développer un IDE.

Et quitte a voir Google changer de crèmerie, j’aurais préféré le voir partir sur un truc vraiment différent.



Là, on a juste du droit a un import d’une librairie déjà existante, dans un IDE pas si différent. Je grince donc un peu des dents quand je vois des developpeurs plutot occasionnels crier au génie.








rsegismont a écrit :



Bug : ne marche pas sous Windows 7 x64







Tu es en SP1 ?



Pour l’over





Guiguiolive a écrit :



L’executable d’installation est detecté comme non sûr par Symantec, qui me deconseille de l’installer… <img data-src=" />





Fous Symantec à la poubelle. <img data-src=" />









rsegismont a écrit :



Bug : ne marche pas sous Windows 7 x64





C’est encore tout plein de bugs, et l’installateur fait n’importe quoi.

Il faut que tu definisses une variable d’environnement JAVA_HOME sur le chemin de ton JDK… Et le programme se lancera…



En gros, a voir les forums, l’installateur ne fait que dezipper les fichiers, et tu dois te faire la config a la main…










Guiguiolive a écrit :



C’est encore tout plein de bugs, et l’installateur fait n’importe quoi.

Il faut que tu definisses une variable d’environnement JAVA_HOME sur le chemin de ton JDK… Et le programme se lancera…



En gros, a voir les forums, l’installateur ne fait que dezipper les fichiers, et tu dois te faire la config a la main…







Yep j’ai vu ca, j’ai finit péniblement par tout faire marcher et pour le moment… c’est juste un eclipse redisgné, toutes les fonctionnalités présentées hier étaient de toute façon déjà présente dans eclipse à peu de choses près…



Bref, j’attend la 1.0 avant de migrer ^^









PCl a écrit :



Ctrl+K+C et Ctrl+K+U pour commenter et dé-commenter chez moi…

Et oui c’est utile d’avoir 2 raccourcis.

Si je commente un bloc qui contient code + commentaire, mon commentaire sera doublement en commentaire et le code commenté une fois. Si plus tard je le dé-commente, je me retrouve de nouveau avec du code + du commentaire et pas mon commentaire transformé en code.



Lire ton message au dessus, ça donne envie de te retourner la question…







J’avoue avoir cité le raccourci de tête, vu que je bosse sous eclipse toute la journée, et je viens de vérifier, le ALT est une erreur de ma part, il n’y est pas, au temps pour moi

En revanche, je confirme que mon raccourci fonctionne (tout comme le tien, les deux sont valables) :

CTRL+K puis CTRL+C

CTRL+E puis C



Autre point : tous les IDE que j’ai utilisé jusque là ont toujours su se débrouiller quand je commentais/décommentais à la fois du code et des commentaires, donc je maintiens l’inutilité de la séparation des raccourcis;



Et dernière chose, pas très fair-play de ta part de me citer sans ajouter la nuance que j’ai indiqué en dessous : Eclipse a beaucoup de défauts, et son utilisation pour Android n’arrange rien, bien au contraire










monpci a écrit :



en espérant qu’il ne faille pas une demi journée pour tout installer comme sous eclipse …



C’est fini ça : tu télécharges les ADT (Android Developer Tools, c’est un Eclipse avec le plugin ADT déjà configuré et tout qui va bien) et roulez jeunesse ! <img data-src=" />

Après, ça n’installe que les derniers SDK pour Android 4.x donc, pour les vieux projets en 1.6 ou 2.3, faut installer soi-même les SDK idoines manquants mais c’est pas la mort…









Glubglub a écrit :



Je ne voit pas en quoi c’est trollesque : exécuter un programme dans une machine virtuelle est forcément plus lent qu’un programme compilé en assembleur.

10 fois plus lent, selont quelques profs de mon ancienne fac.







Et encore, ils étaient optimiste tes profs…

Assembleur VS Java, je dirais plutot dnas les 200x…



Dejà java VS C… j’ai fait un test tout con quand j’ai voulu me lancer en pregramation native sur android, le calcul d’une madelbrot en java et j’ai pris l’algo tel quel en C, resultat : 58x plus rapide pour la version native… et encore en C j’aurais pu optimiser en utilisant les fonctions NEON…



Mais bon, la difference n’est pas aussi significative quand le programme fait majoritairement appel à des API.



Le 16/05/2013 à 15h 32







jaretlafoudre a écrit :



Et encore, ils étaient optimiste tes profs…

Assembleur VS Java, je dirais plutot dnas les 200x…







Comparaison super intelligente









jaretlafoudre a écrit :



Dejà java VS C… j’ai fait un test tout con quand j’ai voulu me lancer en pregramation native sur android, le calcul d’une madelbrot en java et j’ai pris l’algo tel quel en C, resultat : 58x plus rapide pour la version native… et encore en C j’aurais pu optimiser en utilisant les fonctions NEON…





Si moi je code le même algo en C# il sera 5% plus lent et sans optimisation particulière. Et un codeur familier de Java en ferait autant.



J’ai testé un peu, pas mal du tout, tout s’installe facilement et l’import des projets a fonctionné nickel….par contre…l’annulation ne fonctionne pas en mode design via Ctrl+Z…obligé d’aller dans local history pour revenir en arrière lorsqu’on édite un fichier de layout <img data-src=" /> Ca la fout mal pour un IDE (même en preview)

Ca vous le fait aussi ? (j’utilise la version linux).








ArchLord a écrit :



touche windows+r -&gt; cmd



ensuite



et enfin





par contre je sais pas si ca fonctionne avec une version x64 du jdk





Ca marche impec <img data-src=" />



Le 17/05/2013 à 00h 54







monpci a écrit :



en espérant qu’il ne faille pas une demi journée pour tout installer comme sous eclipse …









DorianMonnier a écrit :



J’ai mis 15 secondes sous OSX hier (juste installation hein, j’ai pas regardé le paramétrage encore)







Pareil sous Linux… ^^



Pour ce qui concerne le paramétrage, il faut simplement lui indiquer où se trouve le SDK, sinon il l’installe de lui-même…



<img data-src=" />



Bonjour,



Je viens de faire l’installation sur Windows 8 64bits, ça fonctionne très bien.



Je suis parti de zéro, je n’avait pas de JDK, j’ai donc fait ça :





  • J’ai téléchargé “jdk-7u21-windows-x64.exe”

  • J’ai installé le JDK

  • J’ai téléchargé “android-studio-bundle”

  • J’ai lancé Android-Studio …



    Mais j’ai eu une erreur !!! le JDK était introuvable …



    J’ai déclaré la variable d’environnement :



  • Panneau de configuration

  • Icone Systeme

  • Sur la gauche - Paramètres système avancés

  • Dans la fenêtre “Propriétés système”, clicker sur Variables d’environnement …

  • Dans Variables utilisateur … clicker sur Nouvelle …

  • Nom de la variable : JAVA_HOME

  • Valeur de la variable : c:\program Files\Java\jdk1.7.0_21



    (Je pars du principe que Windows est installé sur le disque C:)





    Ensuite, lancer Android-Studio, et tout fonctionne.


C’est toujours une bonne chose de pouvoir se passer d’Eclipse.








jaretlafoudre a écrit :



Et encore, ils étaient optimiste tes profs…

Assembleur VS Java, je dirais plutot dnas les 200x…



Dejà java VS C… j’ai fait un test tout con quand j’ai voulu me lancer en pregramation native sur android, le calcul d’une madelbrot en java et j’ai pris l’algo tel quel en C, resultat : 58x plus rapide pour la version native… et encore en C j’aurais pu optimiser en utilisant les fonctions NEON…



Mais bon, la difference n’est pas aussi significative quand le programme fait majoritairement appel à des API.











HarmattanBlow a écrit :



Si moi je code le même algo en C# il sera 5% plus lent et sans optimisation particulière. Et un codeur familier de Java en ferait autant.





Sur android d’un S3 je parle, les machine virtuelle sur PC sont peut etre mieux mieux optimisé…

La seule difference entre le code C et java, c’est la facons de detecter le nombre de core pour savoir le nombre de thread a lancer, et la façon d’ecrire dans le buffer opengl (pointeur en C…)



Mais en tout cas sur mon S3 :




  • Sans options de compilation particuliere : version C 2.5x plus rapide que version java

  • option de compile fast : 58x plus rapide

    Et j’obtient encore un X4 en modifiant l’ago pour utiliser les instructions NEON (Ca, je ne sais pas comment faire directement en java, hormis en passant par le renderscript mais on sort du cadre java)









jaretlafoudre a écrit :



La seule difference entre le code C et java, c’est la facons de detecter le nombre de core pour savoir le nombre de thread a lancer, et la façon d’ecrire dans le buffer opengl (pointeur en C…)





Les primitives utilisées pour le parallélisme sont également différentes, les API utilisées pour communiquer avec le GPU également (wrapper autour d’OpenGL), il faudrait voir comment tu écris dans le buffer, et ensuite on ne fait de toute façon pas les choses de la même façon en C et en Java.



Le problème vient soit de la VM Android (mais même en s’y prenant comme un pied je ne vois pas comment atteindre de si mauvais résultats), soit du code, soit des API. Ca c’est pour le 2.5x. Je serais curieux de voir le code.



Quant au fait qu’en “compile fast” tu obtiennes un tel gain, soit des instructions particulières ont été utilisées, ce qui n’est pas possible dans les scénarios typiques, soit il y a une grosse anguille sous roche.