Eclipse 2.1 incluye numerosas mejoras de rendimiento, algunas de ellas en el área de la carga de clases. Como ayuda, se ha añadido código al archivo de manifiesto del conector, y este archivo describe su utilización.
-noPackagePrefixes
al ejecutable de Eclipse.
La declaración de los prefijos de paquete en el archivo de manifiesto del conector se indica mediante un elemento packages
para cada biblioteca que se declara en el archivo. El elemento packages
tiene un atributo prefixes
que lista los prefijos de paquete de esa biblioteca.
Es bastante habitual que los archivos jar contengan código que reside en varios paquetes.
Por ejemplo, el conector org.eclipse.core.runtime
contiene código en los siguientes paquetes:
org.eclipse.core.runtime
.
org.eclipse.core.internal.runtime,
org.eclipse.core.internal.plugins
org.eclipse.core.runtime.model
En este caso, el archivo plugin.xml
especifica:
<runtime>
<library name="runtime.jar">
<export name="*"/>
<packages
prefixes="org.eclipse.core"/>
</library>
</runtime>
Observe que org.eclipse.core
es el prefijo común de todos los paquetes del conector. La alternativa consiste en declarar los 4 prefijos del archivo como una lista separada por comas. En este caso, el usuario debe sopesar la posible ventaja que pueda representar la utilización del número de comprobaciones necesarias en varias entradas sobre la utilización de un prefijo que pueda incluir falsas coincidencias. Dependiendo de la forma en que esté estructurado el código, puede que sea mejor listar un máximo de 5-10 prefijos de paquete en lugar de especificar un prefijo más general. Por ejemplo, si todo el código procedente de varios conectores contiene el mismo prefijo (por ejemplo, com.mycompany
), el usuario no sacará provecho de todas las ventajas si lista sólo el prefijo único "com.mycompany" en el archivo.
Si un conector contiene varias declaraciones de biblioteca, cada una de ellas debe contabilizar los prefijos de paquete desde su archivo jar.
Si elige no incluir ningún elemento packages
en el manifiesto del conector, el código seguirá funcionando, pero no obtendrá ninguna ventaja de la optimización de la carga de clases. Tenga en cuenta que la lista de prefijos de paquete debe estar completa para todos los paquetes de todas las bibliotecas del conector. Si esta lista no está completa, el código no funcionará.
En Eclipse 2.0.2 y en las construcciones anteriores de Eclipse 2.1 Integration, se añadió una característica que permitía al usuario especificar un archivo de propiedades de cargador de clases que contuviera los prefijos de paquete para habilitar las mejoras de cargador de clases. La utilización de este archivo se especifica aquí.
Eclipse 2.1 es plenamente compatible con dicho archivo de propiedades de cargador de clases y, de hecho, puede utilizarse junto con las declaraciones de prefijo de paquete del manifiesto del conector. Esta sección describe el comportamiento de la interacción entre estos dos mecanismos.
Comportamiento por omisión: (sin argumentos de línea de mandatos) Los prefijos de paquete se leerán del archivo plugin.xml
y se aplicarán a la estrategia de carga de clases. No se accede al archivo classloader.properties
no se tiene en cuenta.
Utilizando -classloaderProperties: Los prefijos de paquete se leen del archivo
plugin.xml
y, a continuación, se lee el archivo
classloader.properties
. Si en el archivo de propiedades de cargador de clases existe una entrada para un conector que tenía prefijos definidos en el archivo de manifiesto, la entrada del archivo de propiedades tendrá preferencia (los resultados NO se fusionan). Si
la entrada del archivo de propiedades no contiene ningún valor (por ejemplo,
org.eclipse.core.runtime=
), los prefijos declarados en el archivo de manifiesto se eliminarán y, por omisión, la estrategia de carga de clases no utilizará las mejoras.
Utilizando -noPackagePrefixes: Los prefijos de paquete declarados en el archivo de manifiesto del conector se pasan por alto y tampoco se tiene en cuenta el archivo de propiedades de cargador de clases. Por omisión, la estrategia de carga de clases no utiliza las mejoras de prefijo.
Utilizando -classloaderProperties y -noPackagePrefixes: Las declaraciones de paquete del archivo de manifiesto del conector se pasan por alto. Se lee el archivo de propiedades de cargador de clases y las declaraciones definidas en él se tienen en cuenta durante la carga de clases.
Si recibe una excepción de tipo java.lang.ClassNotFoundException
, significa que puede existir un problema en las entradas del manifiesto o de los archivos de propiedades. Intente ejecutar Eclipse con el argumento de línea de mandatos
-noPackagePrefixes
y NO utilice el argumento -classloaderProperties
. Con ello inhabilitará todas las mejoras de carga de clases con respecto a los prefijos de paquete.
Si, una vez realizada esta operación, el código se ejecuta correctamente, puede que la sintaxis de los archivos sea correcta, pero que falten algunas entradas en los prefijos de paquete de la lista separada por comas. Para comprobar si este es el problema, comente las líneas adecuadas del archivo. Utilice un signo de número (#) para comentar la línea del
conector que falla en el archivo de propiedades o utilice los caracteres de comentario HTML
(<!-- ... -->) para comentar la declaración de los paquetes en el archivo
plugin.xml
que falla.
NoClassDefFoundError
. Esto
puede resolverse utilizando el argumento de línea de mandatos -noPackagePrefixes
para desactivar las mejoras de cargador de clases o añadiendo las entradas de prefijo de paquete adecuadas al conector y a todos sus fragmentos.