+1 à mon humble avis, cela n'a pas du entrainer de modification de la VM .Net, mais uniquement du front-end de mscEnvoyé par LLB
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Les interfaces graphiques en java standard sont bien loin d'être réputées, tant sur le plan du rendu esthétique que des performances (ce que compense SWT au prix d'autres désavantages).
S'il y a bien un point sur lequel la supériorité de .Net ne fait franchement aucun doute, c'est bien celui-ci.
Par ailleurs, sympa le lien, mais on peut faire la même chose en WPF et presque sans taper de lignes de code à la main. Ok c'est une histoire d'IDE mais cependant....
Le sujet de la "lenteur" mythique de swing a été abordé un bon nombre de fois dans ce sujet, il faudrait peut etre que tu retourne lire les messages avant de lancer une telle affirmation.
Systèmes d'Informations Géographiques
- Projets : Unlicense.science - Apache.SIS
Pour un monde sans BigBrother IxQuick ni censure RSF et Les moutons
Alors tu es pas d'accord avec moi quand je dis que les interfaces graphiques en java (en général) ont une mauvaises réputation?Le sujet de la "lenteur" mythique de swing a été abordé un bon nombre de fois dans ce sujet, il faudrait peut etre que tu retourne lire les messages avant de lancer une telle affirmation.
ta le code de ce programme Java2D
quand .net est sorti, on entendait que ça allait tout tuer... que java était voué à une mort...
or quelques années après, Java est toujours plus utilisé et le marché en est toujours plus friand
La réputation est elle toujours méritée ?Alors tu es pas d'accord avec moi quand je dis que les interfaces graphiques en java (en général) ont une mauvaises réputation?
Telle est la question.
Beaucoup de gens se basent sur des "on dit", ou des affirmations valables sur des versions anciennes de Java.
Les performances et les look and feel ont bien progressé et continuent de le faire à chaque nouvelle version.
Regarde les interfaces développées en Java pour te faire une idée.
le look and feel a fait d'énormes progrès depuis la jdk 1.5 (parce que faut avouer sous la jdk 1.4 c'était moche
ensuite côté perfs, disons qu'il y a eu la tentative SWT d'eclipse qui a une époque accélerer... mais que Sun a toujours souhaité couler
toujours sous jdk 1.5 (pas resté depuis), faut quand même avouer que les interfaces graphiques étaient certes peu rapides (mais dans 80% des cas, l'utilisateur est plus lent que la machine), mais surtout elle consommait énormement de mémoire... en comparaison des WinForms de .Net
Oui bon...Winforms ce n'est pas particulièrement économe niveau mémoire non plus...mais surtout elle consommait énormement de mémoire... en comparaison des WinForms de .Net
In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.
je n'ai pas dit le contraire... mais ça consommait moins sur les petites applis que je développais
<troll>
mais rien ne peut battre Gtk
</troll>
plus sérieusement, quelqu'un a comparé Swing / WinForms / Gtk# ?
Personnellement, j'ai toujours reproché le manque de réactivité des GUI développées en Java.
J'ai également un léger souci avec la JVM, en général, pour une raison obscure dès que je l'installe, mon PC se met à ramer. Ceci dit, je suis sous vista, ceci est peut-être un début d'explication... ?
Il y a tout de même deux choses dont on a pas parlé depuis un moment qui manquent à c# et pas à Java : la visibilité package et l'AOP.
Et je mets des pincettes concernant l'AOP, car finalement, on a des librairies qui le permettent (postshart, aspectsharp...) mais rien d'intégré directement à dotnet, c'est dommage.
Elles ont mauvaise reputation car certain persiste a le propager.
coté intégration, swing le fait tres bien :
(capture de mon bureau sous ubuntu64, premier plan l'exporateur natif, second plan, netbeans fait en swing)
http://img91.imageshack.us/img91/5998/capture1vj5.png
On ne voit pas de difference de style.
Et coté qualité on peut tres bien avoir de quoi bluffer :
https://aerith.dev.java.net/
Systèmes d'Informations Géographiques
- Projets : Unlicense.science - Apache.SIS
Pour un monde sans BigBrother IxQuick ni censure RSF et Les moutons
c'est joli, certes... mais quid de la réactivité et de la consommation mémoire ?
sinon, avec des simples images, je peux même essayer de faire croire que Gimp est un superbe outil pour faire des interfaces graphiques
l'AOP tu réponds toi-même, donc rien à dire, mais la visibilité package ?? TU peux développer ?
In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.
tu peux le tester, il y a un java web start : http://aerith.keybe.com/jnlp/index.jnlp
Systèmes d'Informations Géographiques
- Projets : Unlicense.science - Apache.SIS
Pour un monde sans BigBrother IxQuick ni censure RSF et Les moutons
passes pas au boulot... de quel port a-t-il besoin ?
parce que c'est assez fluide pour le mode (page d'accueil, login, et veuillez attendre que le tourniquet finisse), mais la JVM me pompe déjà prêt de 90Mo...
en comparaison, Visual Studio 2008 ne m'en prend que 48Mo alors que j'ai plein de fichiers ouverts, etc (mais les effets graphiques sont moindres)
Bah c'est le fléau de la JVM: elle est bonne en up-scaling, mais pas en down-scaling
parce que c'est assez fluide pour le mode (page d'accueil, login, et veuillez attendre que le tourniquet finisse), mais la JVM me pompe déjà prêt de 90Mo...
en comparaison, Visual Studio 2008 ne m'en prend que 48Mo alors que j'ai plein de fichiers ouverts, etc (mais les effets graphiques sont moindres
Les différentes visibilités dispo en c# : private, protected, internal, public.
En ce qui concerne private, protected et public, rien à dire, tout le monde connait (j'espère...).
En ce qui concerne internal, il s'agit de ce qui se rapproche le plus de la visibilité package de Java : tout ce qui est dans le même assembly que l'objet ayant une visibilité internal peut voir cet objet.
La visibilité package de Java, c'est "tout ce qui est dans le même package.....".
Si on avait une visibilité package en c#, on pourrait faire certaines choses plus proprement.
C'est un peu l'histoire du mot-clef friend qui manque aussi bien en Java qu'en C#, en fait. Ceci dit, friend n'était peut-être pas très orienté objet, selon certains...
Sauf erreur de ma part, un package est une unité logique en-dessous d'une assembly non ?
Vu qu'il n'y a pas de notion de package en .Net, ça serait quoi l'idée ? Mettre une visibilité au niveau d'un namespace ?
Pas certain que ce soit d'une utilité fondamentale...
Comme quoi ?
Friend existe en VB.Net et est l'équivalent d'internal...
In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.
Je parlais plus du friend du C++.
En ce qui concerne une visibilité package ou "namespace", non c'est pas forcément d'une utilité fondamentale, mais ça resterait intéressant dans certains cas.
Prend par exemple le cas d'un ORM qui soit assez ouvert pour permettre au développeurs l'utilisant de le compléter.
Par exemple, de base il s'agit d'un ORM qui ne mappe que sur SQL Server, mais il te laisse la possibilité d'implémenter le mapping sur d'autres choses, par exemple Oracle, MySQL ou même un service web ou autre... Bref, tout ce que tu veux.
De base, tu vas avoir une série de classes qui ne devraient être visibles que par l'ORM, et surtout pas par le programme métier utilisant cet ORM.
Mais si tu souhaites vraiment permettre d'étendre les possibilités de ton ORM, t'es un peu forcé de rendre visible certaines classes, visibilité publique, puisque c'est la seule visibilité disponible en c# qui te permettera de faire ça.
En Java, tu aurais eu la visibilité package (ou ton équivalent "namespace"), qui aurait mieux fait l'affaire.
Le modificateur internal ne permet-il pas de faire ce que tu décris, ou tout au moins quelque chose qui va dans ce sens?
C'est à dire protéger l'accès depuis un autre composant tout en exposant la méthode en interne?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager