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
Ca a mon avis c'est le problème de l'équilibre entre fonctionnalité et ressources. les IDE Java font souvent énormément de choses (aussi parce que le langage du fait qu'il est assez strict le facilite) et ca a malheureusement un cout non négligeableEnvoyé par super_navide
Note que le probleme est valable pour tout, pas uniquement la bibliotheque. Si on cherche a etablir un standard trop vite, on se trouve devant le dilemne, etre bloque dans les voies d'evolution, ou ne pas rester compatible. On peut d'ailleurs s'imposer de rester compatible avec quelque chose de preexistant. Une partie des caracteristiques du C++ s'explique par le desir de rester compatible avec le C (et cette compatibilite a fait beaucoup pour son succes). Un langage comme scala s'est contraint a entrer dans le modele objet de la JVM et de .NET.
Ce que je crains d'ailleurs -- et on sort encore plus du debat -- c'est que de plus en plus le desir d'avoir une bibliotheque importante a faible cout conduise a faire ce meme choix.
Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.
Ne le prend pas malmerci je retiens...
Ce que je veux dire par là c'est qu'avec Swing les antipatterns sont plus fréquent et donc cela se ressent sur la qualité finale. Le "gray-rect bug", ou le bug du rectangle gris est le plus représentative de cela. En bloquant le thread d'affichage on empêche la GUI de se mettre à jour. Or ce n'est pas un bug de Swing ou de la JVM mais bien un bug du developpeur... mais il est tellement courant (car l'origine exact du problème n'est pas forcément évidente) qu'un "moyen de contournement" a été mis en place dans Java 6...
SWT adopte une autre approche plus restrictive il me semble (en levant une exception permettant de mieux cibler le problème et donc de le corriger), et du coup il est plus simple de faire une GUI, alors qu'avec Swing cela neccessite de mieux comprendre tous les principes sous-jacents (bien que cela pourrait changer avec le Swing Application Framework).
Quand aux performances elles peuvent varier selon le type d'application (il me semble que pour des list ou tableau de taille importante, Swing prend le dessus, alors que c'est l'inverse pour des interfaces plus simple), mais je ne pense pas qu'on puisse dire qu'une est vraiment supérieur à l'autre...
a++
PS : je parle bien sûr pour les JVM actuelles... Swing aillant été nettement amélioré à chaque version depuis le JDK 1.3...
En fait je pense pas que ca soit le fait d'établir un standard trop tot ou trop tard.
De toute facon quelque soit le moment ou on établit le standard, les choses évoluent donc même si on a pris son temps avant de proposer une api, elle pourra etre améliorée, remplacée. On a cité 2 api pour les IO, 2 apis pour les GUI, mais en allant plus en profondeur il y a aussi 2 api pour la gestion du focus dans Swing, et certainement d'autres bouts de l'api sont dans ce cas je pense. Mais réellement ca ne me parrait pas si genant. Ca augmente le volume de code de l'api, mais ca ne dérange pas les développeurs. Les anciens projets fonctionnent, les nouveaux aussi, tout le monde est content non ?
VC++ notamment le 6 ça prend que dalle en mémoire....
Si tu prends des environnements sous Linux c'est pareil voire moindre.
Par contre c'est vrai que BCB est un peu lourd
Le 1er Avril c'est passé . Sinon on va mettre cela dans le bêtisier de la taverne...
j'aurais tout vu dans ma vie ....un processeur orienté objet...
le dll Hell c'est le problème de Microsoft et notamment de cet outil totalement infame qui s'appelle Visual Basic ( avant .NET )...T'as pas encore été confronté au DLL Hell. Ca reserve de mauvaises surprises quand on ne fait pas attention.
Ok c'est un peu la même chose avec VC++ et MFC si on les lie en dynamique mais on peut les lier en statique...
Et avec Delphi et autres y'a pas ce problème..
Et Microsoft avec .NET est bien parti pour nous refaire le coup des dll Hell..
*modifier code d'une méthode pendant l'execution
,appeler une méthode dont le nom est connu que pendant l'execution du programme,génération de classe à la volé
OK pas possible c'est vrai à moins de bidouiller
*serialization générique
*thread built-in
*portabilité
*api de debug
*bibliothéque gestion collection String etc... standard le
*gestion des sockets
C'est pas possible tout ça en C++ ?
1/ c'est sur que ca ne repond pas a tous les besoins mais c'est pas mal quand meme, et Java ne le propose pas
2/ ... qui vivra verra, c'est encore loin l'avenir
Effectivement c'est vrai que c'est pas homogène et un peu dispersif contrairement à la JVM ou le "framework" .NET
MAIS les sockets c'est du ressort de l'OS ,la gestion des IO c'est du ressort de l'OS donc tu accèdes directement à ces fonctionnalités là pas besoin de passer par des tas de couches logicielles inutiles
En Java ce sera la même chose d'une manière ou d'une autre puisque le code Java d'une manière ou d'une autre c'est la même chose que le C++ du code assembleur compris par la machine..
je m'explique : tu veux faire des requetes SQL en Java donc obligé forcément de passer par ODBC et moteur de bdd ce qui revient en définitif au même que C++.
Sauf qu'avec Java c'est plus transparent..
Ca fait un moment que Java se passe d'ODBC :
http://java.developpez.com/faq/jdbc/...s#typesDrivers
Pour générer des classes à la volée, c'est envisageable si on génère un code correct et que l'on dispose d'un compilo -- c'est bien le SDK et pas juste le JDK qu'il vous faut pour cela, non? De là on produit une bibliothèque dynamique que l'on charge à la volée. Par contre, il faut clairement définir les interfaces.
a- boost
a- serialization générique
b- thread built-in
c- portabilité
d- api de debug
e- bibliothéque gestion collection String etc... standard le
f- gestion des sockets
C'est pas possible tout ça en C++ ?
b- boost, ACE, POSIX, framework graphique, C++09
c- Mouais. Ce n'est pas comme si des programmes Java ne tournaient pas sur la version suivante du couple SDK/JVM du même fournisseur (sun), suite à l'introduction d'un bug, et refonctionnaient sur les versions d'après.
La portabilité, c'est la même chose pour tous : il faut connaitre le sous-ensemble portable relatif aux besoins et s'y tenir.
d- Clairement propriétaire, cela est vrai.
e- Ce n'est pas comme si on avait une SL qui est d'ailleurs spécifiée en terme de complexité des diverses opérations -- Je ne sais plus qui parlait de compléxité il y a quelques pages de cela. De nouveaux containers en C++09
f- boost, ACE, POSIX
Les solutions existent, elles sont connues, et franchement, on n'a guèe plus à tergiverser que vous quand vous décider d'utiliser telle ou telle bibliothèque Apache.
Il n'y a que deux familles de containers en Java ? Les Generics n'ont introduit que la seconde ?
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
en java on peut jouer avec le bytecode , via bcel ( api d'apache bas niveau ) ou javassist ( la c'est très sexy peut faire des trucs tres .. dangereux ^^; compiler une chaine de caractere et l'insérer dans le code d'une méthode au runtime .. vive le débuggage par contre )
sinon .. ce débat est lassant. lol j'ai pas pu m'en empecher.
a+
Il existe des API externes (comme BCEL déjà cité), mais depuis Java 6 il existe une API en standard : Java Compiler API (package javax.tools entre autre).
Concernant les librairies, je pense qu'on retrouve a peu près les mêmes fonctionnalités que ce soit en C++ qu'en Java...
Il faut quand même reconnaitre que c'est plus facile à mettre en place en Java...
Tout à fait d'accord.
La philosophie d'une API standard super complète a des avantages (base commune utilisé par tous) mais également des défauts : son évolution est plus lente et mesurer afin d'éviter toute incompatibilité ! Avec une API externe ce problème ne se pose pas, puisqu'il est possible de choisir la version que l'on utilisera sans trop impacter sur le reste des librairies...
En fait il n'y en a "qu'une et demi"...
Je m'explique : à l'origine il n'y avait pas vraiment d'API de collections mais 3 pauvres classes qui se battaient en "duel" : Vector, Hashtable et Stack.
Avec Java 1.2 est apparu une API de Collection bien plus évolué qui séparait bien les interfaces (Collection, List, Set et Map principalement) des implémentations (ArrayList, LinkedList, HashSet, HashMap, etc.) et ces trois classes d'origines ont été adaptées afin de respecter cette nouvelle API...
Au cours des versions cette API s'est étendus avec de nouvelles interfaces et implémentations, mais contrairement à .NET avec les Templates, il n'y a pas eu de seconde API avec l'intégration des Generics car ces dernières permettent de conserver une compatibilité source et binaire...
a++
Je veux bien qu'on me contredise mais ou bien je suis bête ou bien y'a quelque chose qui ne va pas : JDBC et ODBC c'est la même chose à une lettre près sauf que pour Java , comme je l'ai écris y'a une couche supplémentaire pour que la JVM puisse piloter un sGBD...
donc Java NE se passe pas d'ODBC comme tu l'écris d'ailleurs c'est écrit noir sur blanc dans le lien que tu as donné;
Pour faire des requêtes SQL ou piloter un SGBD on est obligatoirement obligé de passer par ODBC et ses gestionnaires c'est le standard de fait je ne connais pas d'autres standards ( sauf appels natifs ...)
Je m'empresse de te contredire, oui il y a une lettre de différence, c'est un J (pour Java tu l'avais deviné). C'est donc une couche d'abstraction pour faire du sql en Java, et effectivement il faut donc un driver derrière.
Mais ce driver est un driver lui même écrit en Java, et on se passe donc bien de ODBC
d'accord on ne va pas polémiquer là dessus mais même si le gestionnaire est écrit en Java je pense qu'il utilise au final les mêmes composantes ODBC...
Euh là faudrait que tu développes parce que je vois pas vraiment que tu entends par là.
Si tu veux dire que ca utilise au final une librairie native appelée a partir de Java, tu te trompes
Il ya plusieurs types de drivers JDBC. Certain utilisent des biblio natives, d'autre sont 100% ecrit en Java.
Les drivers natifs Java sont dits de type 4. Un exemple parmi d'autres, le driver JDBC de PostgreSQL.
FAQ XML
------------
« Le moyen le plus sûr de cacher aux autres les limites de son savoir est de ne jamais les dépasser »
Giacomo Leopardi
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