Blog de christopheJ

27
août
2007

Un article de christopheJ Comments

Une seule entrée de blog car le temps manque pour les multiplier…
Je vais donc parler du consumer JRE, le runtime allégé pour utilisateurs, et des nouveautés de Java 7.

J’ai déjà parlé plusieurs fois du consumer JRE (ici et la). Ce JRE est attendu par beaucoup car il permettrait de résoudre ce que certains considèrent comme un gros handicap de Java face aux technologies comme Flash : la taille de téléchargement et le temps de démarrage. Parmi les prérequis pour ce consumer JRE, il y avait donc la création du Java Kernel, un coeur allégé ne contenant que les classes les plus couramment utilisées. Il semble que ce Java Kernel soit dans le prochain update de Java SE 6 update 4, selon le blog de Rémi Forax.
Nous avons donc ici, un premier pas vers le consumer JRE, et celui ci ne semble pas être le plus simple, ce qui est encourageant.

Le deuxième point est Java 7 et toutes les discussions autour de ce qu’il doit contenir. Parmi les grands favoris, on trouve, entre autres, les closures et les properties. On trouve aussi tout un tas de propositions comme l’héritage multiple, la surcharge d’opérateurs,le support SQL au niveau du langage, ou votre fonctionnalité préférée d’un autre langage. L’argument

DotNet (et notamment C#) offre la fonctionnalité depuis la version 3, Java prend du retard

revient aussi régulièrement.

Chet Haase en a profité pour faire ses propositions sur le ton de l’humour, et ses lecteurs s’en donnent à coeur joie.
Pour un aperçu complet des discussions autour de Java 7, vous pouvez consulter l’excellent travail de recensement que fait Alex Miller sur son blog.

Plus sérieusement, un sondage montre que quand même plus d’un quart des développeurs ne veulent pas de changement. Là aussi les commentaires sont intéressants, ce qui a valu au sondage d’être deux fois de suite dans le blog journalier de l’éditeur de java.net (ici et là). Personnellement je ne suis pas contre le support des String dans les switch et un meilleur support du xml. Par contre certaines propositions comme l’héritage multiple ou la surcharge des opérateurs m’inquiètent un peu plus. Quand je vois certaines horreurs dans des codes, je me dis qu’on donnerai alors des outils bien dangereux aux développeurs pour un apport quand même minime.

Avant de me faire agresser, je vais tenter de m’expliquer…
Pour l’héritage multiple, j’ai du mal à comprendre le concept. L’héritage est souvent décrit comme une spécialisation d’une classe. Alors pourquoi spécialiser deux classes d’un coup en les réunissant dans une seule? Si elles sont suffisamment semblables pour cela, il y a, à mon avis un problème de conception, elle devrait avoir un lien…. Si vous avez un exemple clair, n’hésitez pas à laisser un commentaire….
Concernant la surcharge des opérateurs, cela me semble justifié pour les classes représentant des numériques ou pour des classes représentant des matrices. Mais pour les autres, la majorité des classes, cela me semble inutile. Si j’ajoute deux classes représentant des voitures, je n’obtiens pas une sorte de voiture à 10 places et 8 roues mais plutôt deux voitures que je mets dans un tableau ou une Collection, pas besoin de surcharge des opérateurs pour ces choses là.

Le succès de Java est du à sa simplicité. Je trouve que certaines de ces évolutions vont complexifier le langage et la lecture du code ou ne seront utiliser que par une « certaine élite » des développeurs. Avez vous déjà lu et compris du code avec des closures? Nous somme sans doute nombreux à utiliser les Generics pour typer nos Collections. Mais qui utilise ou même comprend cette syntaxe tirée de la page 18 du tutoriel de Sun sur les Générics?

interface Sink<T>{
flush(T,t);
}

public static <T> T writeAll(Collection<T> coll, Sink<? super T> snk){….}

Il serait sans doute plus intéressant de corriger les bugs les plus demandés ou d’implémenter les améliorations les plus demandées. Si SUN veut vraiment le retour de Java sur le Desktop, il ne faudra pas qu’un JRE plus léger et rapide, mais aussi un meilleur support du multimédia et de la connectivité de la machine (série, USB, FireWire…).

4 Commentaires + Ajouter un commentaire

christopheJ 10 juillet 2008 à 14 h 56 min

Le soucis pour l’héritage multiple est le suivant :

abstract class Mammifere{
public void marcherSurTerre(){
//marcher a quatre pattes….
}
}

abstract class Oiseau{
public void marcherSurTerre(){
//sautiller sur deux pattes…
}
}

class Chimere extends Mammifere, Oiseau{
//….plein de choses que font mes chimères.
}

si je fais :

Chimere c = new Chimere();
c.marcherSurTerre();

Qu’est ce qu’il se passe?
Laquelle est appelé? Je suis obliger de reprendre la méthode dans ma classe pour lever Chimere pour lever l’ambiguité.

Connectez-vous pour répondre
fabien29200 10 juillet 2008 à 14 h 38 min

L’héritage multiple peut être intéressant pour implémenter des fonctionnalités dans classes abstraites distinctes et pour rassembler des fonctionnalités à certains objets.

Exemple concret :

abstract class EnginTerrestre {

public void avancerSurTerre() {…}

}

abstract class EnginMaritime {

public void avancerSurMer() {…}

}

class EnginAmphibie extends EnginTerrestre, EnginMaritime {

// fonctions mutualisées
}

Voilà, pour l’instant en Java, tu dois faire des interfaces et dupliquer du code.

Connectez-vous pour répondre
adiguba 28 août 2007 à 10 h 56 min
100% d’accord avec toi en ce qui concerne l’héritage multiple et la surcharge des opérateurs.
L’héritage multiple en Java pourrait faire très mal du fait que les méthodes sont virtuelles par défaut (à l’inverse du C++ par exemple).
Quand aux surcharges d’opérateurs il ne faut pas laisser cela dans les mains de tous les programmeurs c’est bien trop dangereux :aie: Surtout lorsqu’on voit les effets indésirables de la seule surcharge de Java (je parle bien sûr de l’opérateur + entre objet dans une boucle).

C’est vrai que la syntaxe des Generics peut sembler assez obscure et très verbeuse, mais cela apporte également beaucoup d’information sur les relations entres les paramètres et cela devient bien pratique à l’utilisation lorsqu’on a pris le coup…

Je prendrais comme exemple la méthode Collections.sort()

Sans Generics :

Collections.sort(list, new Comparator() {
public int compare(Object o1, Object o2) {
return ((String)o1).compareToIgnoreCase((String)o2);
}
});

Avec Generics :

Collections.sort(list, new Comparator() {
public int compare(String s1, String s2) {
return s1.compareToIgnoreCase(s2);
}
});

Et avec les Closures cela pourrait devenir quelque chose du style :

for Collections.sort(String s1, String s2 : list) {
s1.compareToIgnoreCase(s2)
};

Sans parler de l’exemple du with() de la proposition officiel (http://www.javac.info/closures-v05.html) qui permet de fermer les ressources proprement (sans bloc try/finally dans tous les sens :D):

with(FileReader in : makeReader()) with(FileWriter out : makeWriter()) {
// code using in and out
}

Quand aux propriétés des beans, je pense que ce serait une bonne chose même si j’ai un peu de mal avec toutes les propositions que j’ai vu. Mais il s’agit d’un concept fondamental de Java et il n’est malheureusement que « théorique » : il n’y a aucun support au niveau du langage…

Sinon, pour ce qui est officiellement annoncé pour Java 7), j’adore le principe des « super-package » (JSR 294) qui permettra enfin d’organiser proprement ses librairie au lieu d’avoir des packages énormes qui abusent de la visibilité « package-only », et la généralisation des annotations sur tous les types (JSR 308). Quand aux nouvelles API cela a l’air prometteur (NIO2, Units, Date & Time, Swing App Framework, Beans Binding).

J’ai vu également d’autres propositions (plus ou moins officielle) assez intéressante :
- Les meta-interfaces qui obligeraient les classes à implémenter une méthode static (plus d’info : http://jroller.com/jadda/entry/meta_interfaces_for_contracting_classes ) : pratique pour les Factory.
- Les literals qui permettrait d’initialiser des List et Map plus simplement ( http://jroller.com/scolebourne/entry/java_7_list_and_map ).
- L’appel en cascade des méthodes retournant void comme si elles retournaient this ( http://mernst.org/blog/rss.xml#AModestLanguageProposal ).
>> pour le multimedia, je pense que c’est en route, cause javaFX.

Il y a aussi « Java Media Components » ! Même s’il n’a pas fait beaucoup parler de lui…

Enfin perso j’attends les premiers builds intégrant ces nouveautés avec impatience

a++
Connectez-vous pour répondre
lunatix 28 août 2007 à 9 h 54 min

effectivement, je suis d’accord avec toi. Java 7 pour le moment y’a pas grand chose qui m’intéresse. le support des String dans les switch, c’est anecdotique.
La seule vraie évolution qui me plaise, c’est le support des bigdecimal, parce que je fais pas mal d’informatique de gestion, et que c’est une horreur.

le consumer JRE me semble beaucoup plus important, surtout d’ailleurs son système de préchargement en cache de l’OS plus que la taille du download qui ne m’a jamais paru un gros probleme.

pour le multimedia, je pense que c’est en route, cause javaFX.

sinon, je suis a fond pour les numeros de lignes obligatoires dans les sources aussi !

Connectez-vous pour répondre