Utilizar las mejoras de cargador de clases

Última actualización: 9 de diciembre de 2002

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.

Activación

Las mejoras de rendimiento de cargador de clases se habilitan automáticamente por omisión. Si el usuario desea alterar temporalmente este comportamiento e inhabilitarlas, puede pasar el argumento de línea de mandatos -noPackagePrefixes al ejecutable de Eclipse.

Formato

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á.

Utilizar con el archivo de propiedades de cargador de clases

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.

Resolución de problemas

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.

Problemas conocidos

Si un archivo de manifiesto de conector declara la lista de prefijos de paquete, todos los fragmentos que efectúen contribuciones al mismo también deben listar sus prefijos de paquete. Si no lo hacen, se producirá un problema de tipo 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.

Copyright IBM Corporation y otros 2000, 2003.