Reprise du message précédent :

tu écris le détecteur toî-même alors.

 
d'ou wartning à la khon, on est d'accord

mais ça sert à rien le serialversiontruc, vous avez fumé ou quoi

 
 
de mémoire Eclipse 3.1 te fait chier avec ca dès que tu crée une classe, même si elle n'implémente / n'hérite de rien...et Object implemente pas Serialize
 
au pire tu vas dans la conf et tu vires le warning...
 
c une connerie à rajouter à la liste des trucs nazes de la 3.1, comme par ex la génération de constructeur et de get/set avec des noms de variables pourris...durant la beta ca créait des bugs, maintenant ils ont fait un sys à la con avec un compteur donc ca buggue plus, mais je vois pas l'intéret non plus...
 
ex :  
 

 
si tu génères, durant la beta il tronquait pour ne garder que la dernière partie, afin de faire le nom de la variable...Ce qui fait qu'on se retrouvait avec 2 " name", et que donc ca plantait...là il ont fait un truc genre name1, name2 ...
 
c pourtant pas compliqué de réutiliser les noms de variable tels quels (qui sont donc déjà forcément uniques au sein de la classe), et de préfixer les membres par this...ca lève totalement toutes les ambiguités, et ca fait du code propre et lisible...et ct le fonctionnement de la 2.x et de la 3.0.x
 

Salut !
je voudrai coder un prog. en java qui piloterai des players comme foobar, mediaplayer mais je n'ai aucune idée par où commencer, vous avez des conseils ?

J'avais jamais utilisé la fonction de génération de constructeurs selon les attributs de la classe.
C'est vrai que c'est nul ce systeme de numerotation.
Sinon j'aime bien le principe de rajouter le mot "new" devant l'argument comme le fait jdeveloper. ainsi

T'entend quoi par "piloter", vu que les players que t'as cités fournissent une IHM?
 

Error: could not find class javax.activation.DataHandler from file activation.jar
 
activation.jar est pas dans Tomcat par defaut

ce que je trouve louche c'est le "from file activation.jar" ...

tiens il est dans tomcat4 mais pas dans le 5

c'est un test, j'imagine que axis verifie la presence de la classe et precise le fichier.

bon, j'ai fais le goret, j'ai piqué le activation.jar de mon tomcat4 et je l'ai copié dans le common/lib de mon tomcat 5
 
 ca fonctionne

tu peux aussi le foutre dans le WEB-INF/lib de ton appli, s'tout de meme plus propre

ouais aussi, mais non
 
 je viens de verifier sur le serveur de prod, le activation.jar est dans le common/lib, je pense que l'admin du tomcat a du faire pareil

ben oué, sans doute qu'il a voulu deployer sur tc5 une appli qu'avait été faite pour tc4 sinon c'est pas une bonne idée, ce truc se retrouve dans le classpath de toutes tes webapps, donc stu veux utiliser une autre version dans une autre webapp, t'es de la baise

 
je préfère l'ancien système, d'ailleurs full compliant avec les conventions de code java :  
 

oui axis

Chacun fait ce qu'il veut mais je trouve cela un peu "error prone" dès qu'une méthode commence à avoir pas mal de lignes de code.

nan c faux ...
 
si t'utilise un IDE, si tu tapes this. il te sort en complétion tous les membres...par ailleurs si tu prend l'habitude de strictement préfixer tt les membres à l'utilisation, tout ce qui n'est pas préfixé par this. est forcément soit un paramètre, soit une variable locale, ce qu'un mouse over sur la variable te précise instantanément...
 
c d'ailleurs faire en java ce que bcp font dans d'autres langages en faisant m_ ou p_...mais en étant java compliant et en utilisant ton IDE pour tout ce qu'il peut t'offrir

Le code que tu ponds ne doit pas dépendre des capacités de ton IDE.
Sinon j'ai remarqué que souvent les developpeurs n'utilise le this que pour lever les ambiguités.
Tout n'est pas forcément bon à prendre chez sun.

il en dépend pas : il les sublime, nuanace...si t'a un IDE ca marche et t'a des fonctions avancées, si t'a pas d'ide, ca rend ton code lisible...
 
et bcp de dev java n'ont pas commencé avec le java, et on gardé leur habitudes de code d'avant...lis les conventions de code java, tu verras...
 
comme dit nraynaud, et je suis très d'accord : tu t'es déjà fait chier à trouver un nom valable pour ta variable, c laid de devoir te faire chier à en trouver un autre...

T'inquiète pas pour moi je les ai lu bien avant que tu apprennes ce langage.    
Comme je l'ai dit precedemment, chacun fait ce qu'il veut. A condition de respecter les normes de l'entreprise/ du projet.
Dans le cas des paramètres des constructeurs, ma propre expérience m'a montré que cela pouvait entrainer des erreurs. D'autant plus que plus d'une fois cela m'est arrivé de devoir corriger un bug en vitesse directement sur une machine  du code que je n'avait pas pondu  sans pouvoir recourir à un ide. Et parfois même sans editeur avec coloration syntaxique( Merci Vi).

c'est malin t'es a mis partout  

 
c'est a ce moment qu'on enchaine sur les tailles de bites non ?
 
putain super...

comment as-tu assuré la qualité de ce code exactement ?

Malheureusement chez certain clients ce n'est pas toujours la qualité qui prime mais corriger l'appli en prod le plus rapidement possible.
Donc on est hélas obligé de faire avec les moyens qu'on nous donnent.
Si concernant la taille des bites. Jubi est peut être meilleur développeur que moi car je n'ai pas la prétention d'être un grand dev.. mais c'est à priori vrai que j'ai lu les conventions de code java bien avant qu'il vienne poster sur ce forum ses premières questions.
Désolé de m'etre emporté j'aurais du garder cette remarque pour moi.

meilleur dev j'en sais rien, mais disons que je préfère bosser avec des outils valables...
 
sur du code si tu fais une modif à l'arrache en mode texte tu peux casser des trucs sans t'en rendre compte...si t'a un IDE, si tu casses une signature il te le dit, et puis surtout si t'a fais des tests tu les relances et hop tu garantis que ce que tu as changé répond tjs à tes normes
 
si l'urgence de la correction du bug fait que tu peux meme pas utiliser un IDE y'a comme un soucis je pense...

Hé oui.
En plus avant eclipse il n y avait pas beaucoup d'IDE java serieux gratuit et qui ne consommait pas toute les faibles ressources du PC que le client mettait à ta dispositions .
Ce sont peut être des habitudes de "vieux". Mais quand j'ai débuté c'était très fréquent de coder sans outillage adapté. Dans le meilleurs des cas on avait un rad avec coloration syntaxique et compilation par raccourci claviers.

tu parles d'un temps que les jeunes de 20 ans ne peuvent pas connaître ...
 
(je confirme : jusqu'à y a pas si longtemps, c'était largement le cas dans ma boite. Et le coup du vi vite fait bien fait est pas si rare ...)

si j'ai appris java comme ca : avec the programer's notepad, dans lequel on configurait javac pour le lancer par raccourci...non sans avoir fait 2 séances avec notepad pur et la ligne de commande...
 
c formatteur...mais bon autant bosser proprement...en tout cas dans la boite où je bosse si y'a une modif à faire c les dev qui la font (bon appli web aussi, en client lourd c surement plus chiant)...et du coup CVS > checkout > correction > tests > commit

Nous on patche le bytecode à coup d'ASM

 
le truc ce serai un process serveur sur le PC qui enverrai des signaux (au sens d'appels systemes), en fonction de ce qu'il recoit sur un port tcp/ip
le but etant apres d'attaquer ça par un programme de telecommande qui utiliserai le wifi de ma console de jeux videos. Comme sur la DS y a un ecran tactil au final ca pourrai etre un chouette truc

et vous recalculez le CRC du .class à la main ensuite

 
maven, je t'aime

Je sais que c'est "excitant" de programmer ses propres solutions.
Mais je crois qu'on vend des télécommande bon marché qui te permettent de piloter pas mal de logiciels liés au multimédia. Et je ne parle pas même pas des solutions Media Center.
Pourquoi réinventer la roue ?

bof, un mac, itunes, et un telephone bluetooth

 
justement faudrai que je fasse juste le pont entre ma DS et ses solutions,
genre faire un plugin pour girder par exemple.

 
C'est quoi ce truc ?
 
On peut coller du XSL en prime ?

je suis tout en emoi, je viens d'utiliser mes premières annotations