Hay un componente dentro de la aplicación que usa com.sun.java.swing.SwingUtilities2 Ahora entiendo que esta clase no se debe usar, pero es un componente dentro del sistema que la usa.Java 6 y SwingUtilities2
Por lo tanto, como ya no está disponible en Java 6, obtengo un NoClassDefFoundError. ¿Cómo puedo solucionar este problema sin tener que actualizar el componente ya que aún no sé si esa es una opción?
Si no tiene absolutamente ninguna otra opción, entonces debe averiguar exactamente qué era lo que la clase está utilizando desde SwingUtilities2, y luego hacer proxys para esa funcionalidad en sus propias SwingUtilities2. Luego puede pegarlo en su propio paquete com.sun.java.swing, que se superpondrá con el original, y si el mismo cargador de clases que carga su componente también conoce SwingUtilities2, entonces uno verá el otro y su la aplicación funcionará
Dependiendo de lo que sea el componente y de lo que use de SwingUtilities2, esto podría ser mucho más difícil que actualizarlo o incluso reescribirlo.
Estoy de acuerdo. ¿Tienes alguna idea de si la fuente está disponible en cualquier lugar? Entiendo que no es de código abierto, pero alguien debe haber creado algún tipo de clase para reemplazarlo ... –
Aparte de descompilarlo. –
http://www.google.com/search?q=SwingUtilities2.java –
Da-dum! ¡Esta es precisamente la razón por la que debes prestar atención a esas molestas advertencias que te advierten que no confíes en los aspectos internos de la JVM!
¿Pero tienes una solución? –
@Rob, asume que @Stephane hizo el problema que tiene que soportar. ¿Cómo resuelves el problema si tienes que solucionar el problema? – reccles
En realidad, se trata de un componente que se compró para incluir en el software. El componente, dado que es propietario, está ofuscado. Tampoco tenía idea (ni cómo podrías siquiera saber) que estaba usando esta clase. –
Sin embargo, no sé si esto funcionaría.
Pruebe sacando la clase SwingUtilities2 y colóquela en un contenedor de parches, incluya este tarro en su classpath. Espero que esto funcione hasta que puedas cambiar la fuente.
Lamentablemente no funciona, hay una línea ((Boolean) c .getClientProperty (AA_TEXT_PROPERTY_KEY)); que siempre devuelve null y, por lo tanto, arroja un nullpointerexception. –
Edite las referencias dentro de la clase copiada para hacer una referencia local. Creo que el NP es porque está utilizando la variab real 6 les. Aunque sería mejor hacer que el vendedor vuelva a generar un 6. Algunas compañías hacen esto para soluciones rápidas – reccles
La única forma correcta (sin hackear) es pedirle al proveedor que arregle y reconstruya este componente en Java 6. La forma posible de hacerlo es copiar sun.swing.SU2 a com.sun ... SU2 y empacarlo en jar por separado (por ejemplo, java6fix.jar) e intentar ejecutar su aplicación. Estará bien si agrega este parche de parche en jvm bootclasspath. El mejor parche debe ser crear su propio com.sun..SU2 y delegar todas las llamadas a sun.swing.SU2. Y eche un vistazo a la versión diferente del componente que admite Java6 también puede ser de otro proveedor. Además, si el problema está solo en la línea mencionada ((Boolean)c.getClientProperty(AA_TEXT_PROPERTY_KEY));, entonces puede poner su propia propiedad de cliente para este componente para evitar el NPE. Cuando tome este camino, simplemente puede crear su propio com.sun ... SU2.AA_TEXT_PROPERTY_KEY y llamar a c.setClientProperty (AA_TEXT_PROPERTY_KEY, true) en este componente. También intente desactivar el control anti aliasing en el componente si es posible.
Aunque es agradable decir que me temo que esta es una ruta costosa. El componente fue creado en el error JDK 5, por lo que no puedo culparlos por no admitir JDK 6. –
De lo contrario, tome otra ruta de mis sugerencias. –
¿Vas a nombrar y avergonzar al proveedor del componente? –
¿Es esto para una corrección de puntos? ¿Es posible hacer que el proveedor haga una reconstrucción para 6? – reccles
@Tom: Desde entonces lo arreglaron, simplemente no queremos absorber el tiempo y los costos monetarios. Por ejemplo, han mejorado su API, pero no necesitamos ninguna de las mejoras (aparte de esta solución). Además, no sabemos si nuestro código necesitará una mejora para coincidir con la nueva API (más costos de tiempo). Y, por supuesto, está el costo de "actualización" para el componente. –