Reprise du message précédent :
Merci  

 
bon alors c'est trop balaise pour vous ou quoi ?  
 

/**
     * Fix a freezing issue when trying to display folder containing zip files on Windows.
     * 
     * @see javax.swing.JFileChooser#updateUI()
     */
    @Override
    public void updateUI() {
        putClientProperty("FileChooser.useShellFolder", Boolean.FALSE); //$NON-NLS-1$
        super.updateUI();
    }

et pourquoi hériter ?

ça le fait pas ?
la prop est resettée tout le temps ou quoi ?

Entre les deux, j'ai fait :
 

final JFileChooser directoryChooser = new JFileChooser() {
                    @Override
                    public void updateUI() {
                        this.putClientProperty("FileChooser.useShellFolder", Boolean.FALSE);
                        super.updateUI();
                    }
                };

ah oui merde, j'ai oublié cette histoire

+1 il faut que je teste, mais normalement c'est comme ça qu'on fait. Et l'UI fait gaffe à pas écraser les customs normalement.  

Si je me rappelle bien (mais je peux me tromper), cela dépend de quand on demande de choisir un L&F. Il me semble que suivant le fait que celui-ci soit initialisé avant ou après le JFC avait son importance.

http://bugs.sun.com/bugdatabase/vi [...] id=6759788
le seul intérêt de modifier ce truc en Java 6 était de pouvoir récupérer l'objet pour décider si on accepte le drag ou non

'tain mais les mecs qui ont fait TransfertHandler c'est des guignols ou quoi ?
 
avec le bug d'au-dessus, si un mec drag un fichier au-dessus de ma fenêtre, je peux pas mater l'extension du fichier pour dire si je l'accepte ou pas.
 
D'autre part, y'a aucune méthode pour dire "j'ai pas d'éléments sélectionnés dans mon composant (genre y'a pas de lettres sélectionnés dans un champ texte), donc pas la peine d'appeler exportToClipboard()". Je vois pas comment je peux raisonnablement griser le "cut" dans le menu "Edit" sans un suivi comme ça.

<nraynaud-porn>
http://code.google.com/p/guava-libraries/
</nraynaud-porn>

hé les élites,
 
ça fait quelques années que je lurk le topic, posant une ou deux questions à la cons de temps en temps, et je vous ai jamais vu parler de JavaRebel.
 
Je viens de tester, et je trouve ça pas mal. On semble gagner un temps dingue sur le dev. Mais je verrai à l'usage.
 
Pas d'avis sur la question ici ?

avec l'expérience (no troll), est-ce que c'est pas suffisamment casse-bonbon à débugguer du JEE quand ça part en vrille, il faut en plus ajouter des couches qui font des trucs de sioux dans le dos ? paske si ça aide quand ça va bien, c'est cool mais si ça ajoute une couche d'incertitude à chaque fois que tu compiles, on n'est pas rendu

mais sur la forme, si ça marche bien, ça peut être cool et je vais le tester un peu pour voir (avec le bocal de Sun)

edit> moi aussi j'ai une question: je cherche un générateur Swing à partir d'une config genre XML (un peu à la XUL); est-ce que qq'un a de bonnes adresses à partager ?

J'avais essayé aussi JavaRebel mais en inconvénient majeur je trouve c'est la lenteur ajoutée par la couche supplémentaire. Surtout en debug.
De plus je l'avais pas trouvé très au point sur le rechargement de beans Spring à la volée.

 
 
je teste en dev depuis ce matin, Spring reload sans soucis pour l'instant.
 
J'ai pas eu de flaw pour l'instant, c'est que du bonheur

 
Tu lurk pas assez, ca a déjà été abordé par nraynaud et lorill. Au final, ca semblait pas super fiable.

Vu que je ne sais même pas de quoi il s'agit, ca devait être quelqu'un d'autre

vu qu'une recherche sur java rebel dans le topic donnait rien, j'ai supposé que ça n'avait pas encore été abordé.

0x90. mais c'était surement sur blabla@prog

J'ai un répertoire /home/igarimasho/java_test/ qui contient un fichier Application.java:

 
ainsi que le fichier postgresql.jar
 
Je tente une compilation avec la commande suivante:

Et forçément le compilateur me crache à la figure:

   
 
Où est le problème?

le type d'erreur et sa localisation

l'erreur exacte et sa traduction

la representation graphique de l'endroit ou l'erreur est située dans ton code.

Accessoirement, c'est pas le bon topic.

J'ai créé un topic dédié

et les 5 lignes au dessus, c'était trop long pour ton capital concentration ?

Ha en fait c'est le topic où les débutants se font casser par les anciens    
 
J'ai compris où est l'erreur, forçément avec 2 lignes de codes effectives... Maintenant pourquoi ce con de javac ne trouve pas postgresql    Le classpath, m'a l'air bon à moins qu'il y ait une faute de frappe que je n'arrive pas à distinguer.

non mais justement t'as pas compris l'erreur du tout, visiblement.
 
au hasard, va lire la javadoc des methodes que tu utilises, ptet ?

Pour moi, il ne trouve pas org.postgresl.Driver.
 
Si j'ajoute ce code:

 
Ca compile et au runtime:

ta première erreur était qu'il te manquait le try/catch
la seconde visiblement vient du fait que soit le driver n'est pas dans le classpath soit que le nom complet du driver que tu veux est incorrect.
 
-> http://jdbc.postgresql.org/doc.html
 
mais comme --, c'est un souci de base ça

J'ai besoin d'un petit moteur de template, qui gère juste la base : remplacement, conditions, boucles. Ca va être utilisé par un webmaster qui ne programme pas.
 
Velocity c'est moche. Jet ca a l'air sympa, mais je trouve pas de doc pour l'utiliser par code, sans eclipse. D'autres idées ?

FreeMarker?

ouais, ca a l'air correct. Merci.

moinsmoins qui se fait griller sur ça

 
Pas besoin de "try/catch" dans une méthode "main", suffit de rajouter "throws Exception" à la déclaration

Toi, tu vas prendre cher

ben tiens...

t'as vu l'heure ?

 
Évidemment, c'est principalement valable dans une classe de 2 lignes comme la sienne, hein, pas dans une vraie appli

mouais

'tain mais c'est à chier par terre la hiérarchie de type qu'on trouve quand on fait getGenericType() sur un Field
http://www.j2ee.me/j2se/1.5.0/docs [...] /Type.html
y'a rien, tout ce qu'on peut faire c'est instanceOf

tu peux caster, et suivant les cas, récuperer les bornes du type, par example

ouais, je sais, mais c'est la merde et y'a aucun helper style isAssignableFrom() par exemple.
ça veut dire qu'il faut re-développer l'algo du compilateur pour faire ça.

ben getClass().isAssignableFrom() nan ?
enfin bref, oui, c'est pas tres cool y'a surement une api de chez google pour remplacer ça