je voudrais savoir s'il y a un logiciel  
ou comment je pourrais faire pour transformer du code swing en awt

swing repose sur du AWT, donc il ne devrait pas y avoir de pb si ?

mon pb est que j'ai du code swing et je voudrais quil soit transformer en awt de façon facile comment je peux faire?

te faire la conversion à la main.

C'est une GROSSE galère, dans la mesure où plein de composants Swing n'ont aucun équivalent en AWT...Donc, soit tu fait autrement, avec d'autres composants, etc...., soit, tu crées les composants dont tu as besoin.
Mais pour faire des choses évoluées, c'est un peu lourdingue.

 
Pô d'acord, les contrôles swing sont entièrement implémentés et dessinés en java. Il n'y a rien de natif.
 
Les contôles awt reposent sur les contrôles présents avec l'os.
 
c'est pour ça qu'il ne faut jamais mettre du awt dans du swing.
 
Cependant, il est vrai que swing utilise des evènement, listeners, et classes utilitaires dans les packages de awt. Mais rien de natif.
 
La plupart des contrôles swing portent le nom du contrôle awt avec un 'J' devant :
 
List -> JList
Button -> JButton
CheckBox -> JCheckBox
etc.
 
Mais certains contrôles swing n'ont pas d'équivalent awt
ex : JTable, JTree

ah bon ?

 
yes  

oui, autant tout recoder

 
Faux.
 
javax.swing.JComponent est une sous classe de java.awt.Container, qui est elle même une sous classe de java.awt.Component
 
Et tous les composants Swing descendent de JComponent.
 
RTFJavadoc.
 
En Swing, il y A du natif, mais il du natif 'basique' : pas de composants, juste des conteneurs dans lequel des composants sont dessinés, avec des méthodes natives super basiques, ce qui fait que le look est le même sous différents os.
 
Donc, on *pourrait* mettre de l'AWT dans du Swing, et du Swing dans de l'AWT.
La raison pour laquelle il vaut mieux éviter, c'est la gestion des Threads : Swing est dit 'thread-safe', si je me souviens bien, alors qu'en AWT, n'importe quelle thread peut manipuler un élément graphique, avec tous les risques que cela implique.

Il me semble bien que Swing dans la majorité des composants n'est pas Thread-safe. (JTextField l'est par exemple)

Sur le point de la "thread safe....ness?? ..itude???", je me garderai bien d'être catégorique : j'ai pas fait de Swing depuis 1999 (bouhou)  
Par contre, j'ai fait plein d'AWT, mais comme j'étais en jdk 1.1.5 (applet oblige) j'utilisait des vecteurs (synchronisés) partout, ce qui évite plein de problèmes!

Juste pour replacer la disgression concernant Swing : on ne doit toucher un composant QUE depuis le thread de répartition des évènements swing, ce qui garantie qu'il n'est pas en train de peindre (vu que la peinture se fait depuis ce thread et qu'il peu pas être à la fois en train de peindre et de répartir un évènement).
 
Il existe UNE exception : on peut modifier un Dérivé de DefaultDocument depuis n'importe quel thread (et surement pas n'importe quoi dans un JTextBidule, ou n'importe quel Document).
 
Enfin, la compatibilité swing/awt est un bordel sans nom à cause de la distinction composants lourds/composants léger, je ne m'étendrais pas là-dessus, j'ai rien compris à l'explication.

vous pouvez jetez un oeil la:
http://faqjava.developpez.com/?pag [...] ange_SWING

 
Il me semble aussi qu'il ya des problèmes au niveau du rafraichissement, les contrôles awt étant déssinés dessus (dessous, je me rappelle plus) les composants swing, à cause de la méthode de dessin : appels natifs pour awt et implémentation en java pour swing.
 
Me trompe-je ??

 
non, tu te tromp-je pas!

si c pour avoir du AWT genre J2ME, passe ton chemin : y'a pas la moitié du bordel qui est implémenté...c vraiment la zone le J2ME

AWT cai le mal

des fois c tout ce que tu as..

..pis on peut faire des trucs machins vachement sympas, avec du temps et du jus de neurones, en AWT, voilà.