2008-11-20 22 views

Respuesta

2

Me he encontrado con esto y las actualizaciones no han sido de ayuda. Por extraño que parezca, la eliminación de todos los archivos zip (especialmente los grandes) de mi escritorio (ubicación predeterminada de JFileChooser) resolvió el problema.

+0

No tengo ningún archivo zip en mi escritorio ni en la ubicación de inicio del selector de archivos – dkp

+0

Disculpe que no sirvió de nada. Como un FYI, aquí el enlace a la discusión sobre JFileChooser y archivos zip grandes en el escritorio http://forums.sun.com/thread.jspa?threadID=5207221&messageID=9901574 –

+0

Oh hombre, esto seguro me ayudó. No entiendo cómo Java se pone así de ridículo ahora. Lo he estado usando en la universidad/hobby y en mi trabajo por 9 años y realmente me está poniendo molesto. – Zombies

4

Hay un error en el que si una unidad de red asignada en el escritorio, a veces puede colgar en el JFileChooser. Eso o podría ser un acceso directo a una unidad en red. Algo así ...

+0

Una segunda unidad de disquete (¿las recuerda?) También podría ser un problema, creo. –

0

Se supone que la actualización .10 arregla el archivo zipfile relacionado.

0

Sí, era un error, pero creo que las versiones recientes de Java ya no lo tienen.
Hay algunas soluciones (aunque son todos los cortes sucios):

  1. uso de un hilo que esperar hasta que se ha inicializado
  2. reutilizar el mismo JFileChooser (almacenarlo en una variable) en lugar de crear nuevos unos. Si es posible, con pereza inicializarlas:

public static JFileChooser chooser = null; 

public static void doSomething(){ 
    if(chooser==null) 
     chooser = new JFileChooser(); 
    //use JFileChooser 
} 

De esta manera los usuarios tienen que esperar menos ... pero todavía tendrán que esperar. La única forma de arreglar esto realmente es actualizar tu JRE.