Gracias por responder, Alex.

No lo había comentado antes, pero en el mismo párrafo de Sun dice:
A well-constructed application should not depend upon any particular order.
Lo cual es completamente verdad. Pero el hecho es que, si no se controlan perfectamente todos y cada uno de los jar de los que depende la ejecución de tu clase, te puede pasar que tengas una misma clase repetida en dos o más jars (mismos paquetes/misma clase), por provenir de diferentes implementaciones, diferentes versiones de un mismo producto, etc. Y ahí es cuando puedes empezar a sufrir lo peor de java, el famoso Jar Hell.

Lo del cacheo de clases no creo que esté afectando. Lo haría si estuviéramos hablando de un servidor de aplicaciones como Websphere, pero supongo que la ejecución de una clase javamain, que arranca una JVM en exclusiva para ella, no tendrá problemas con el cacheo de clases, aunque no pongo la mano en el fuego.

Lo de implementar nuestro propio classloader es algo que queremos evitar a toda costa. Ya hemos hecho algunas pruebas con classloaders customizados y con inversión del cargador de clases (parent first/parent last...), pero al final hemos optado siempre por resolver los problemas "jar hell" de otra forma y dejando que el cargador de clases funcione por defecto. Cambiar esas cosas al final hace que te surjan problemas en otras partes y, lo peor de todo, donde y cuando menos te lo esperas!

Un saludo,
Potele


El 15/11/2016 9:08, Alex Martínez escribió:
Hola

Buena pregunta y me gustaría tener una respuesta mejor pero lo poco que te puedo aportar es que la JVM lleva un cache de las clases ya cargadas, ¿será por este motivo que pueda parecer aleatorio?

No he encontrado nada por el momento referente al orden de carga de clases de los archivos jar de una carpeta aunque siempre estas a tiempo de implementar tu propio classloader ;-)


Seguiremos investigando....


El 14 de noviembre de 2016, 14:12, Potele <[email protected]> escribió:
Buenos días foreros,

Aquí va una pregunta para los expertos en java del foro.

En un mandato JAVA como el siguiente:

JAVA CLASS('paquete.Clase') +                    
     CLASSPATH('/WEBSITE/jmpru/bin/Clase.jar:/WEBSITE/jmpru/lib/*') +                     
     OPTION(*VERBOSE) OUTPUT(*PRINT)            

...en el que Clase.jar contiene una clase javamain a ejecutar y la carpeta
/WEBSITE/jmpru/lib contiene una serie de jars necesarios para ejecutar la clase (dependencias), ¿en qué orden investiga la JVM la carpeta /WEBSITE/jmpru/lib en busca de las clases que necesita? Es que haciendo pruebas no he visto que dependa de algo concreto (podría ser la fecha de creación de los jars, la fecha de modificación...) sino que parece bastante aleatorio.

En la documentación de Sun al respecto se dice al hablar de los wildcards en el classpath que:
The order in which the JAR files in a directory are enumerated in the expanded class path is not specified and may vary from platform to platform and even from moment to moment on the same machine.
¿Qué orden usa la JVM del iSeries? Es que me resisto a creer que sea completamente aleatorio!!

Gracias por adelantado y un saludo,
Potele


Logotipo Ayuntamiento Vitoria-Gasteiz

José de la Herran Núñez
Kordinazio Teknikoko Burua
Jefe del Área de Coordinación Técnica

Informazioaren Teknologien Saila
Departamento de Tecnologías de la Información

Tel: 945161614 | Fax 945161600
[email protected] | www.vitoria-gasteiz.org

Logotipo Green Capital

KONFIDENTZIALTASUNA

Komunikazio honen edukia eta honi erantsitako dokumentazio osoarena konfidentziala da eta adierazitako jasotzaileari beste inori ez dagokio.
Zeu jasotzaile ez bazina, jakinaraz iezaguzu, mesedez, eta eskatu nahi dizugu edukiaren berri inori ez esan eta mezua ezaba dezazula.

CONFIDENCIALIDAD

El contenido de esta comunicación, así como el de toda la documentación anexa, es confidencial y va dirigido únicamente al destinatario del mismo.
En el supuesto de que usted no fuera el destinatario, le solicitamos que nos lo indique y no comunique su contenido a terceros, procediendo a su destrucción.

CONFIDENCIALITY

The content of this communication and any attached information is confidential and exclusively for the use of the addressee.
If you are not the addressee, we ask you to notify to the sender and do not pass its content to another person, and please be sure you destroy it.



____________________________________________________
Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd )
Forum.Help400 © Publicaciones Help400, S.L.


____________________________________________________ Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) Forum.Help400 © Publicaciones Help400, S.L.


Logotipo Ayuntamiento Vitoria-Gasteiz

José de la Herran Núñez
Kordinazio Teknikoko Burua
Jefe del Área de Coordinación Técnica

Informazioaren Teknologien Saila
Departamento de Tecnologías de la Información

Tel: 945161614 | Fax 945161600
| www.vitoria-gasteiz.org

Logotipo Green Capital

KONFIDENTZIALTASUNA

Komunikazio honen edukia eta honi erantsitako dokumentazio osoarena konfidentziala da eta adierazitako jasotzaileari beste inori ez dagokio.
Zeu jasotzaile ez bazina, jakinaraz iezaguzu, mesedez, eta eskatu nahi dizugu edukiaren berri inori ez esan eta mezua ezaba dezazula.

CONFIDENCIALIDAD

El contenido de esta comunicación, así como el de toda la documentación anexa, es confidencial y va dirigido únicamente al destinatario del mismo.
En el supuesto de que usted no fuera el destinatario, le solicitamos que nos lo indique y no comunique su contenido a terceros, procediendo a su destrucción.

CONFIDENCIALITY

The content of this communication and any attached information is confidential and exclusively for the use of the addressee.
If you are not the addressee, we ask you to notify to the sender and do not pass its content to another person, and please be sure you destroy it.


____________________________________________________
Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd )
Forum.Help400 © Publicaciones Help400, S.L.

Responder a