Acceder methode protected

Bonjour a tous,

j'utilise pour mon boulot un jar ou j'appelle certaines methode public.
Hors, en changeant de version, certaines methode public du jar que j'appelais sont passée en protected :(
Donc impossible de compiler vu que je ne suis pas dans son package. Et impossible de passer par un chemin detourné

On m'a dit qu'il etait possible de bidouiller un fichier policy pour faire croire a la classe qu'elle a le droit d'appeler cette methode protected.
Je sais que c'est pas top, mais mon chef prefere ca a recopier les classes du jar.

Vous auriez un peu plus d'informations dessus ?

merci
mike

on t'as raconté des cracks ;)

le fichier policy permet de déterminer ce que peux faire une application, pas de changer les regles de base du language. Par exemple, tu pourra, dans le fichier policy, autoriser ou non ton application a accéder aux méthodes protected par reflection, via l'appel à setAccessible(true) sur l'objet Method obtenu.
Si les api publiques sont devenues protégée, il faudra soit réécrire du code, soit ne pas faire d'upgrade du jar.

erf..
merci de ta reponse :)

tu entends par quoi avec "par reflection" ?
une methode qui doit etre dans le jar ?

http://java.developpez.com/faq/java/...eflectionhowto

Merci pour les infos !

je suis en train d'essayer de passer par la reflexivité et avec le setAccessible(true) et ca a l'air de fonctionner !

Merci ! :)

si tu dois faire ca partout, t'es pas sorti de l'auberge. La reflexivité c'est bon quand tu veux y aller à l'aveugle. Je connais pas ton code, mais dans ton cas tu devrais peut etre plutot envisager d'étendre la classe concernée pour faire repasser ses méthodes en public. N'oublie pas que les fils d'une classe on accès aux méthodes protégées, pas seulement le package.

en fait, j'ai 2 methodes static qui sont passé sans portée (pas private ni protected ni public), et un construteur passé protected
tout ca dans 2 classes differentes.

J'avais deja pensé a heriter des classes, mais ce n'est malheureusement pas possible, elles sont final :(

Donc soit je le fais 3 fois, soit je reecrit 3 classes en copier/coller car certaines classes ont besoin d'autres classes qui ont des methodes protected.

mon chef apparemment prefere que je le fasse 3 fois :P

soit tu crée un classe dans le bon package avec 3 méthodes static public qui permettent d'appeler le constructeur voulu et les deux méthodes statiques voulues :p

c'est vrai que j'y avais vaguement pensé ...

tu penses que ca serait plus "propre" ?

oui je pesne, car l'accès par reflexion, c'est plus compliqué si tu fait tourner ton code en présence d'un sécurity manager, tu pourrais te voir refuser l'appel à setAccessible(), dans le contexte d'une applet par exemple ou de certains conteneurs J2EE. Puis au moins, la validité du code est testée à la compilation donc si ils changent dans le futur le nom des méthodes tu le verra ;)

oui, c'est vrai, car comme ca on le verrai pas...
mais c'est un peu comme violer le package en y introduisant ma classe qui va servir a appeler ce que je n'avais pas le droit :P

j'pense plus que je ferai comme ca, car c'est vrai que si quand on va le deployer, on nous refuse le setAccessible(), ca va un peu gueuler :aie:

C'est bizarrement fait ce jar quand même. :?

Non parce que passé des méthodes en protected comme ça, les concepteurs ils pensent pas trop à la compatibilité ascendante.

C'est une API? Est-elle documentée?

Si oui, n'indique t'elle pas quelle méthodes il faut utiliser désormais en remplacement de celles que tu ne peux plus appeler ?

Parce que bon, jouer sur la déclaration du package ça fait un peu bidouille tout de même. :p

ca arrive aussi occasionellement sur des api grand public, quand un developpeur, dans une version, a "oublie" que ca devait pas être public ;)

c'est le jar de spring-aop. Et dans toutes mes recherches, j'ai pas reussi a trouver d'autres methodes pour passer outre le protected.

le constructeur qui me pose probleme, c'est celui de la classe "ReflectiveMethodInvocation" passée en protected lors de la version 2.5 (oui, ca date un peu ^^ )
j'ai repris un code existant ou la classe jdkDynamicAopProxy avait été reecrite car pas possible d'en heriter (et donc les appels au constructeur ReflectiveMethodInvocation gardés ) et en changeant de version, ba ces appels ne passent plus

j'ai trouvé des personnes qui ont le meme probleme, mais qui n'ont pas la solution :P