Salut a tous,
 
Je cherche une URL pour un forum Java de haut niveau car apres plus de 1 an de pratique intensive, je bloque sur des problemes de plus en plus specifiques.
En general, ici c'est plus un forum bidoulle (sans vouloir vexer personne, j'adore la bidouille   mais pour le boulot c'est bof....) et le forum de Sun la c'est carrement n'importe quoi, y'en a meme un qui a osé poster un truc du style "Je cherche une solution au probleme XXXX mais je cherche du code pret a l'emploi, testé, et documenté en anglais et en francais" et puis quoi encore une petite p... aussi ???      
 
Bref, si vous avez des URL n'hesitez pas  
merci

et oui, on se rend vite compte de la limite de ce forum lorsqu'on fait des trucs vraiment specifiques ! toutefois, je dsi pas que les gens ici sont incompetents, au contraire.
 
Mais sinon, pour le Java, le meilleurs que j'ai trouvé est un newsgroup : fr.comp.lang.java ou qq chose dans le genre. Ici, que des pros du Java, des reponses serieuses, a condition bien entendu de respecter les regles etablies !
 
Tres bonne continuation avec le java

fykman a écrit a écrit : Salut a tous,   Je cherche une URL pour un forum Java de haut niveau car apres plus de 1 an de pratique intensive, je bloque sur des problemes de plus en plus specifiques. En general, ici c'est plus un forum bidoulle (sans vouloir vexer personne, j'adore la bidouille   mais pour le boulot c'est bof....) et le forum de Sun la c'est carrement n'importe quoi, y'en a meme un qui a osé poster un truc du style "Je cherche une solution au probleme XXXX mais je cherche du code pret a l'emploi, testé, et documenté en anglais et en francais" et puis quoi encore une petite p... aussi ???         Bref, si vous avez des URL n'hesitez pas   merci

 
Tu pourrais au moins poser tes questions !

 
Ok je te pose mes questions :
- Comment fait on pour gerer correctement la transparence en AWT entre 2 panels. En effet, j'arrive a creer des graphismes qui gerent l'alpha transparency dans un meme panel mais des que je rajoute un autre panel par dessus (en overlay), impossible de rendre le contenu de ce panel transparent pour faire ressortir ce qui est en dessous.  
- Peut-on rajouter des composants graphiques (genre boutton) par dessus (overlay) une video sur JMF. Jusqu'a maintenant la video prend toujours le dessus. D'apres ce que j'ai compris c'est une histoire de composant heavyweight (la video) qui prend toujours le dessus sur un composant lightweight (le boutton) meme si au depart il est en dessous.
- Dans quel cas vaut t'il mieux creer une classe totalement abstraite (qu'une autre classe va etendre) plutot qu'une interface (qu'une autre classe va implementer) ?
- Qu'elle est la vrai raison pour laquelle il n'y a pas d'heritage multiple en java ?
- Le mode just-in-time est t'il vraiment plus rapide que le mode d'execution standard ?
 
Voila et j'en ai d'autres dans ma poche mais bon, je voudrais quand meme pas vous soualer avec mes questions ....  

[edtdd]--Message édité par fykman--[/edtdd]

Non, le forum, c génial, c juste que ça marche pas pour tous les styles de problèmes. Seulement pour les trucs relativement simples, mais pas forcément SI simples que ça à trouver dans une doc. En fait, tous les gens du forum, on est comme une doc intelligente... même à nous tous, on en sais surement moins que que la MSDN, mais on est intelligentes, NOUS (ouais, même le petit au fond, t'es intelligente, c pas beau ça !? ). Parce que, si pour nos recherche, on compte sur l'IA de la MSDN, bah on rêve un peu ! En fait, ils devraient trop réfléchir sur ça chez Microsoft: le recherche est trop importante dans une doc.

Bon pour tes questions, pour le panel ya un attribut transparent je crois ? (m'enfin j'imagine qeu tu l'as deja essayé) ...
 
Sinon pourquoi pas d'heritage multiples ? tout simplement pour eviter tous les pb qu'a connu le c++ avec. C surtout a cause du cas d'heritage en diamant :
 
 
                   A
                  / \
                 B   C
                  \ /
                   D
 
Dans ce cas on  a B et c qui herite de A. Chacun d'eux redefinit et surcharge certaines methodes (par exemple la methode getTruc()).
Ensuite D herite de B et C.
D ne redefini pas getTruc()
Si on fait une instance de D et qu'on fait :
D d = new D();
d.getTruc();
 
he bin là ça chie, parce que l'appel dynamique ne sait pas si il doit se servir de la redefinition de B ou de C.
 
Voila !
 
 
Sinon salut El_Gringo, alors comment va §? quoi de neuf ?

[edtdd]--Message édité par petoulachi--[/edtdd]

 
il me semble que tu peux specifier une couleur de fond
genre setbackground avec une couleur et un alpha transparent.
Sinon le remplissage doit etre effectue par une des methodes d'une des classes parente au panel. Si tu te charges de tracer toi meme ton composant (composant non standard), tu peux redefinir paint() en ne specifiant pas de super.paint() qui, lui, aurait trace un fond colore. Attention, s'il derive d'un container, il faut egalement repeindre les instances filles de ton container.
Ce sont de vieux souvenirs mais tu devrais fouiller dans cette direction.
 

 
Je dirai qu'effectivement ca depend de la maniere dont est
rendue ta video. Si c'est un composant externe a java et aux
composants standard, il risque de ne pas tenir compte
des contraintes que tu voudrais lui imposer.
Note qu'avec JMF tu peux inserer un filtre dans le pipeline d'affichage des videos (infos dans le guide JMF) et donc tu peux ajouter a la main des elements dans ta videos. Il y a quelques temps de cela j'avais cree des effets de loupe sur des videos affichees sous JMF: tu recuperes un buffer graphique et tu peux travailler dessus.
 

 
Aucun. Mon humble avis.
 

 
Des raisons philosophiques.
Sinon en pratique quand tu as de l'heritage multiple
il faut que tu penses a tous les cas ou il y a des  
collisions de nom de methodes (apparemment en C++, il faut faire reference explicitement a la classe heritee qui correspond ex: a::function() ou b::function() ). Les createurs de Java ont pense
que les problemes que ca creait justifiait la suppression d'une feature dont on pouvait se passer.
 

 
Ca depend. Il est plus rapide a l'execution  
par contre le temps d'initialisation est incontestablement plus long. Pour un programme qui fait deux trois trucs puis quitte
c'est souvent beaucoup pour pas grand chose.
 

fykman a écrit a écrit :  Voila et j'en ai d'autres dans ma poche mais bon, je voudrais quand meme pas vous soualer avec mes questions ....

 
A+
LEGREG

[edtdd]--Message édité par legreg--[/edtdd]

Merci les gars, finalement j'avais tort, ya aussi des experts sur ce forum !!    
 
OK pour l'heritage multiple c'est plus clair maintenant, merci
 

 
Ca me semble etre une bonne idée, par contre pour rajouter des interactions dessus ca va etre chaud (exemple: un boutton sur la video , l'appui sur ce bouton declenche l'ouverture d'une fenetre...). Mais je devrais pouvoir m'en sortir en utilisant des mouseListener/ mouseEvent de maniere adequate....  
 

 
Deja essayé, marche pas..... visiblement Java s'en balance....    
 

 
 
Il me semble que pour eviter que le fond soit peint (ou effacé) il vaut mieux redefinir la methode update() du panel. Si je ne redefini seulement paint() ca n'empechera pas le fond d'etre mi a jour quand je ferais un repaint().
 

 
Comment tu fais pour repeindre les instances filles du container sans appeller super.paint() ?

   
 
Oui c'est ainsi que tu peux faire des videos interactives
avec des zones cliquables a certains moments.
Desole j'avais fait des trucs comme ca a l'ecole
mais j'ai carrement tout oublie depuis .
(et j'ai encore moins les sources)
 

     
 
Oui, je n'avais pas teste. Il est probable que l'information alpha ne soit pas utilisee pour le fond.
 

 
Par defaut, pour un component, update ne fait qu'appeler paint.  
Donc dans ton cas, c'est plutot paint qu'il faut redefinir.
(et si tu as deja un update customise, il faut
modifier les deux en consequences)
 

 
paintcomponents()
 
LEGREG

 
Je commence par la 2ème :
En fait Java supporte une notion de l'héritage multiple qui est l'héritage multiple d'interface. L'avantage c'est que tu es obligé d'implémenter toutes les méthodes dans la classe (ou sous classe) qui va implémenter ton interface pour éviter l'héritage en diamant (cf reponse petoulachi). L'implémentation de tes méthodes sera donc cohérente avec la définition de ta classe.
 
Par exemple :
 
public interface Mouvement  
{
   public void avancer();
   public void reculer();
}
 
Les 2 classes Voiture et Chien peuvent très bien implémenter cette interface mais bien évidement l'implémentation des méthodes ne sera pas la même.  
Cependant tu peux avoir un conflit de méthodes dans les interfaces quand par exemple tu utilises deux interfaces qui ont des méthodes identiques.
 
 
Pour la 1ère :
Si tu définis une classe abstraite Vehicule qui reprends les mêmes méthodes abstraites avancer() et reculer(). Voiture pourra hériter de cette classe Vehicule mais tu ne pourras pas faire hériter Chien de Vehicule. Alors que si tu reprends l'interface Mouvement, l'intérêt c'est qu'elle peut servire à implémenter les 2 classes Voiture et Chien. Dans ce cas tu peux même faire 2 classes abstraites Vehicule et Animal qui vont implémenter l'interface Mouvement. Puis sous classer Vehicule et Animal avec Voiture et Chien en lors laissant l'implémentation des méthodes avancer() et reculer(). Créer une classe totalement abstraite est donc moins intéressant.
 
 
 
 

 
Oui en général et tu n'as même pas besoin de faire de bench pour t'en rendre compte. La compilation JIT traduit le byte-code Java exécuté pour la première fois en langage machine. Par la suite c'est le code binaire natif qui sera exécuté directement. Mais cette méthode a des inconvénients :
- très gourmande niveau mémoire
- pas efficace pour le code qui est rarement exécuté ou quand ton code met plus de temps à être compilé qu'à s'exécuter directement.  
Mais ce qu'il faut savoir c'est que la dernière JVM (Hotspot) permet de résoudre certains de ces problèmes notamment par une compilation dynamique adaptative assez balaise du code qui est trop long à exécuter en byte-code Java.
 
Pour les autres questions désolé mais j'ai jamais eu à utiliser l'alpha transparency  

un autre moyen de contourner le fait qu'il n'y a pas d'héritage multiple, ce sont les inner-class

Au niveau propreté du code, évite les inner classes, c'est vraiment dégueulasse ...
Sinon l'interface a un réeel avantage par rapport à une classe totalement abstraite ... enfin si tu penses objet et donc réutilisabilité.
 
Si tu as une classe abstraite, tu impose à l'utilisateur de ton objet d'hériter de celle-ci. Une simple implémentation aurait permis de ne pas à créer outre mesure des classes dans un programme utilisateur. L'utilisation d'interface, et pour ne pas vexer les personnes disant qu'il n'y a pas de différences, est la réelle voie d'implémentation pour la réutilisabilité ;o)
 
Il est vrai que l'interface une alternative à l'héritage multiple tout en en supprimant les inconvénient !

Un exemple d'utilisation pratique des inner class
et pas trop crade (moins que les autres solutions s'il
n'y avait pas d'inner class) est l'utilisation
des classes anonymes pour les callbacks.
Evidemment il faut restreindre leur utilisation
aux cas ultra simples.

Ou vois-tu que quelqu'un a dit qu'il n'y avait pas de difference?
j'ai beau relire les messages en long en travers, je ne vois pas.

Tu ne vois pas d'inconveniant a ce qu'il n'y ait pas d'heritage
multiple? et imagine que tu disposes d'une librairie dont tu n'as pas les sources et cependant tu voudrais faire deriver une de tes classes de plusieurs classes existantes dans cette librairie. Tu n'as pas le droit de definir d'interface parce que la partie qui utilises ton objet a ete definie anterieurement.
Donc l'interface ne resout pas tous les problemes. Dans ce cas par contre la encore l'inner class peut etre d'une certaine aide (jamais la seule solution evidemment)..
 
A+
LEGREG

[edtdd]--Message édité par legreg--[/edtdd]

Désolé de de décevoir mais il semble que ce soit toi qui ais répondu cela :  
 
fykman a écrit :
----------------------------------------------------------------
 - Dans quel cas vaut t'il mieux creer une classe totalement abstraite (qu'une autre classe va etendre) plutot qu'une interface (qu'une autre classe va implementer) ?
----------------------------------------------------------------
 
Aucun. Mon humble avis.
 
 
[fin de citation]
 
Ou alors tu ne vois pas la différence pour un implémentation mais tu la vois pour l'interface / classe abstraite ?? Cela me semble étonnant !!
 
Il est vrai que la puissance de l'héritage multiple peut manquer à certains. Malheureusement il n'existe pas en Java et cela permet entre autre de spécifier réellement les objets. Le cas que tu cite n'est pas une raison valable expliquant le manque du langage quant à l'héritage multiple ... tu essais de faire une classe qui fait tout et n'importe quoi, la solution n'est autre que la délégation en demandant à une classe BIEN DETERMINEE de faire le travail pour lequel elle est concue. Donc, je persiste en disant que jusqu'à maintenant je ne vois pas en quoi l'héritage multiple est un manque en JAVA ... bien que je travaille avec ce langage depuis 4 ans pour mon job ;o)

 
Tu ne me decois pas (enfin si un peu), je crois surtout que tu ne sais pas lire  
la question posee c'est: "dans quel cas.."
et ma reponse est : "aucun".
 
Arf..
 
LEGREG

sinon pour répondre à la question principale, http://forum.java.sun.com est pas mal. Mais ca dépend des forums. Pour JMF il y a une ML (voir sur la homepage)
 
A+  

Ah ok ok ok, d'accord ... autant pour moi, je retourne aux fraises !!