Discussion :

[Lorantus]

Le titre dit tout. Mais je vais ajouter quelques éléments.

Tous les objets Java sont dérivés de la classe Object. Cette classe implémente des méthodes par défaut (toString(), equals(), etc).

Est-il possible de créer une classe Object personnel, à laquelle je peut définir les attributs, et qui remplace Object ? Ainsi, tous les objets que je crée seront dérivés de cette nouvelle classe Object. Bien-sûre, je souhaiterai ne pas utiliser "extends" et obtenir ainsi l'héritage obligatoire de ma classe Object.

La raison n'a pas de réponse, c'est juste une question de connaissance personnelle.

Merci de vos réponses.

[herve91]

Non, ce n'est pas possible : le langage a ses règles !

[Tommy31]

C'est possible en définissant ta propre implémentation d'Object à condition qu'il se situe dans le même package (java.lang) et qu'il dispose des mêmes méthodes. L'idéal est de partir du code source d'origine et de l'enrichir.

Il suffit ensuite de jouer avec le boot classpath pour qu'il masque la déclaration d'origine.

[adiGuba]

Salut,

Il suffit ensuite de jouer avec le boot classpath pour qu'il masque la déclaration d'origine.

Mais dans ce cas ce n'est plus vraiment du Java, et cela peut provoquer un grand nombre d'incompatibilité...


a++

[bouye]

et cela peut provoquer un grand nombre d'incompatibilité...

Ainsi qu'un grand nombre de proces...

[Lorantus]

Je vous remercie de vos réponses.

La solution de ré-écrire la classe Object semble être la seule solution.

Mais alors, quitte à faire une 'propre' implementation de cette classe, pourquoi ne pas faire une classe dérviée de Object, mais qui soit l'office la super classe de toute les classes -comme le fait Object.

Et d'ailleurs, pourquoi ne pas pouvoir faire cela, Object j'en pas dans la JVM ?

Je tiens à rappler à tous...
Je souhaiterai plus d'ouverture dans vos réponses car :
- la question est posée à des fin de connaisance
- la question n'engage que moi
- la question ne porte que sur une réflexion sur la classe Object
- la question n'a pas pour but de générer un conflit sur celui qui en sera le plus et mieux que l'autre
- les réponses sont libres et ouvertes -du moment qu'elle ne pose pas de doute au lecteur du futur

Par avance, merci.

[Tommy31]

Si tu souhaites simplement enrichir le comportement d'objet, une autre solution est de recourir à un tissage d'aspect visant toutes les instances.

[Tommy31]

Salut,
Mais dans ce cas ce n'est plus vraiment du Java, et cela peut provoquer un grand nombre d'incompatibilité...
a++

C'est toujours du java, mais plus vraiment du j2se

[Lorantus]

Si tu souhaites simplement enrichir le comportement d'objet, une autre solution est de recourir à un tissage d'aspect visant toutes les instances.

[Tommy31]

http://ewawszczyk.developpez.com/tut...va/spring/aop/

[adiGuba]

Salut,

Mais alors, quitte à faire une 'propre' implementation de cette classe, pourquoi ne pas faire une classe dérviée de Object, mais qui soit l'office la super classe de toute les classes -comme le fait Object.

Parce que cela impacterait le code de toutes les classes Java, qui pourraient se baser sur l'implémentation standard de la classe Object.

Enfin je ne vois pas vraiment l'intérêt de faire cela


a++

[Lorantus]

Salut,



Parce que cela impacterait le code de toutes les classes Java, qui pourraient se baser sur l'implémentation standard de la classe Object.

Enfin je ne vois pas vraiment l'intérêt de faire cela


a++

Je suis ! Ajouter une méthode à Object ne va pas forcement rompre le contrat. En enlever, oui.... mais...

Enfin je ne vois pas vraiment l'intérêt de faire cela

Il y a des fois, faut pas cherché à savoir... Il faut se poser la question, et laisser les reflexions menner à un ensemble de réponses. Par exemple, cette question m'a menné à une étude de AOP... -interessante, merci Tommy31.

[adiGuba]

Je suis !

Pas la peine de s'énerver !
Une solution (en modifiant le bootclasspath) t'as déjà été donné... je ne fait que te prévenir sur les risques que cela implique !

Ajouter une méthode à Object ne va pas forcement rompre le contrat. En enlever, oui.... mais...

Il y a énormément de manière de "tout casser".
Il y a deux type de compatibilité en Java :

• La compatibilité "binaire", qui assure que du bytecode compilé puisse s'exécuter avec une nouvelle version. C'est le niveau de compatibilité le plus important qui est rarement remis en cause. Les cas où la compatibilité binaire a été cassé sont très rare...
• La compatibilité "source", qui assure qu'un code source qui compilait sur une version antérieur puisse compiler tel quel sur une nouvelle version.
  Là c'est déjà plus fréquent car le moindre impact peut poser problème, mais c'est nettement moins grave (on peut toujours compilé avec un vieux JDK et utiliser le programme sur une JVM récente grace à la compatibilité binaire).

Mais voyons voir de plus près les impacts que pourrait poser la modification de la classe Object :

• Si on enlève une méthode, l'impact est évident pour tout le monde il me semble cela génère à la fois une incompatibilité "binaire" (MethodNotFoundException en cas d'appel de la méthode supprimé) et "source" (erreur de compilation "method not found").
  
  
• Si on ajoute un méthode, on peut avoir un impact de type "source". Par exemple si on ajoute une méthode getId() permettant d'obtenir l'identifiant d'un objet :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  	public int getID() {
  		return System.identityHashCode(this);
  	}

  On peut avoir un problème sur les classes contenant une méthode getId() avec une signature légèrement différente. Ainsi la classe suivante ne compilera plus tout simplement car sa méthode getId() retourne une String et non pas un int :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  class MaClasse {
   
  	private final String id;
   
  	public MaClasse(String id) {
  		this.id = id;
  	}
   
  	public String getID() {
  		return this.id;
  	}
   
  }

  Donc cela peut générer une incompatibilité de "source" sur toutes les classes contenant une méthode du même nom.
  
  
  Et il peut y avoir le même problème si la différence survient sur les paramètres de la méthode, dans le cas par exemple où on utiliserait deux interfaces qui pourrait être implémenté par un même objet : le compilateur ne saurait plus quelles méthodes appelées...
  
  Enfin si ton code se base sur ces nouvelles méthodes, il ne sera plus compatible avec les JVM standard, et donc on ne peut plus vraiment parler de Java (Java SE si vous voulez )
  
  
• Enfin la modification des méthodes existantes peut également poser des problèmes, mais au niveau "binaire". En effet il doit y avoir un paquet de classe qui se base sur les méthodes de bases de Object, et les modifier pourrait avoir des effets inattendus sur ces classes.
  
  A titre de comparaison, il y a quelques temps il y avait eu une demande pour modifier la classe Object[], qui est parente de tous les tableaux, et qui ne redéfini pas les méthode equals(), hashCode() ni toString(), ce qui fait qu'un tableau n'est identique qu'avec lui même (le contenu n'est pas vérifié), et que son affichage affiche un truc du genre "[Ljava.lang.Object;@1f0ad786".
  Beaucoup souhaitaient que ces méthodes soient redéfinies pour prendre en compte le contenu des tableaux, mais cela posait un gros problème :
  
  • Les méthodes allaient passer d'une implémentation basique très rapide à une implémentation plus lourde consistant à parcourir tout le tableau, ce qui pourrait donner des résultats catastrophique dans des classes les utilisant massivement
  
  Bref une modification apparemment basique aurait eu un impact si important que cela a été abandonné et remplacé par des méthodes static dans la classe Arrays.
  
  Avec Object ce serait la même chose : imagine que tu ré-implémentes equals() pour comparer tout les attributs de la classe par réflection : cela peut fausser toutes les classes qui se baserait sur l'implémentation par défaut et poser pas mal de problème...

Il y a des fois, faut pas cherché à savoir... Il faut se poser la question, et laisser les reflexions menner à un ensemble de réponses. Par exemple, cette question m'a menné à une étude de AOP... -interessante, merci Tommy31.

Justement : en se posant la question on voit que cela pose de nombreux problème, qui implique une incompatibilité avec le Java standard...


Perso je ne serais pas contre une modification de la classe Object (je déplacerait bien les méthode notify() et wait() qui n'ont rien à y faire à mon avis), mais cela devrait se faire dans une version qui casserait la compatibilité de Java, ce qui n'est pas si anodin !


a++